Комментарии 17
НЛО прилетело и опубликовало эту надпись здесь
> Во-первых, git commit -m «Commit message» может быть полезен для wip патчей
> (work in progress), но вреден для реальных патчей в публичные бранчи, так как
> большинство утилит для работы с Git подразумевает следующий формат commit
> message
Это просто соглашение, и даже в нём подробное описание коммита строго опционально. Если коммит описывается одной строкой, он должен описываться одной строкой, и никакой нужды запускать редактор чтобы её ввести нет. В чём вред -m не показано. Деление на какие-то wip и не wip коммиты тоже новость.
> Во-вторых, многие команды командной строки Git имеют опцию --abort. Применять
> в таком случае git reset --hard, хотя результат и правильный, — равносильно
> стрельбе по воробьям. Из пушки.
Не показано в чём именно заключается стрельба по воробьям и чем всё-таки reset хуже --abort.
Что хотели сказать во 2 и 3 частях, вообще не понятно.
> (work in progress), но вреден для реальных патчей в публичные бранчи, так как
> большинство утилит для работы с Git подразумевает следующий формат commit
> message
Это просто соглашение, и даже в нём подробное описание коммита строго опционально. Если коммит описывается одной строкой, он должен описываться одной строкой, и никакой нужды запускать редактор чтобы её ввести нет. В чём вред -m не показано. Деление на какие-то wip и не wip коммиты тоже новость.
> Во-вторых, многие команды командной строки Git имеют опцию --abort. Применять
> в таком случае git reset --hard, хотя результат и правильный, — равносильно
> стрельбе по воробьям. Из пушки.
Не показано в чём именно заключается стрельба по воробьям и чем всё-таки reset хуже --abort.
Что хотели сказать во 2 и 3 частях, вообще не понятно.
Спасибо за реально полезный комментарий.
Поправил текст со ссылками на книгу. Там описывается обычная структура сообщения.
Про wip: комит, который не готов и может быть далее либо сведён с другим, либо быть fixup'ом, либо быть удалённым. Как вы сами говорите, такое соглашение.
Раскрыл подробнее тему второго случая.
Третий же по-моему очевиден, портить историю в публичных проектах — моветон. Портить историю у себя внутри, себе же хуже, концов не найдёшь кто, что и когда менял. Тем не менее дописал пару фраз.
Поправил текст со ссылками на книгу. Там описывается обычная структура сообщения.
Про wip: комит, который не готов и может быть далее либо сведён с другим, либо быть fixup'ом, либо быть удалённым. Как вы сами говорите, такое соглашение.
Раскрыл подробнее тему второго случая.
Третий же по-моему очевиден, портить историю в публичных проектах — моветон. Портить историю у себя внутри, себе же хуже, концов не найдёшь кто, что и когда менял. Тем не менее дописал пару фраз.
> Поправил текст со ссылками на книгу. Там описывается обычная структура сообщения.
Всё равно написано не то. Мысль которую вы хотели донести звучит так: «Первая строка сообщения не должна содержать более 50-60 символов: если необходимо более развёрнутое описание, добавьте его пропустив одну строку после краткого однострочного. Так только по первой строке сообщения (а во многих случаях пользователю видна именно только первая строка, как-то git log --oneline) можно понять суть коммита». А -m тут совершенно не при чём.
И «стиля subversion» никакого нет: это соглашение используется под любыми VCS по число практическим и интуитивным причинам.
К слову, subversion воспринимает ^M (\r) как перевод строки, поэтому в отличие от git позволяет писать из коммандной строки многострочные сообщения (^M вводится через Ctrl+V, Enter).
> git merge --abort поступает проще, так как ему известно что менялось, где менялось и куда надо возвратится.
Да, теперь согласен.
> Раскрыл подробнее тему второго случая.
Как я понял, тут два примера позволяющих избежать ненужных операций: в первом вместо git checkout && git pull делаем fetch и rebase сразу на origin/master, во втором вместо обновления локальной ветки сразу делаем push в remote master. Ну, во-первых, нет смысла мешать их в одном примере потому что так смысл ускользает, во-вторых, если с первым случаем я согласен, во втором всё равно надо будет обновлять локальную ветку после этого. Хуже того, легко забыть что локальный master не обновлён, начать коммитить в него и в результате делать ещё один rebase.
> Третий же по-моему очевиден
Это бесспорно до той степени что я не увидел смысла в этом пункте поскольку не думал что squash кто-то использует вместо отправки серии коммитов. Но, конечно, если использует, то весьма зря, в качестве аргументов надо привести потерю информации о законченных этапах изменения, и как следствие невозможность нормального bisect.
Всё равно написано не то. Мысль которую вы хотели донести звучит так: «Первая строка сообщения не должна содержать более 50-60 символов: если необходимо более развёрнутое описание, добавьте его пропустив одну строку после краткого однострочного. Так только по первой строке сообщения (а во многих случаях пользователю видна именно только первая строка, как-то git log --oneline) можно понять суть коммита». А -m тут совершенно не при чём.
И «стиля subversion» никакого нет: это соглашение используется под любыми VCS по число практическим и интуитивным причинам.
К слову, subversion воспринимает ^M (\r) как перевод строки, поэтому в отличие от git позволяет писать из коммандной строки многострочные сообщения (^M вводится через Ctrl+V, Enter).
> git merge --abort поступает проще, так как ему известно что менялось, где менялось и куда надо возвратится.
Да, теперь согласен.
> Раскрыл подробнее тему второго случая.
Как я понял, тут два примера позволяющих избежать ненужных операций: в первом вместо git checkout && git pull делаем fetch и rebase сразу на origin/master, во втором вместо обновления локальной ветки сразу делаем push в remote master. Ну, во-первых, нет смысла мешать их в одном примере потому что так смысл ускользает, во-вторых, если с первым случаем я согласен, во втором всё равно надо будет обновлять локальную ветку после этого. Хуже того, легко забыть что локальный master не обновлён, начать коммитить в него и в результате делать ещё один rebase.
> Третий же по-моему очевиден
Это бесспорно до той степени что я не увидел смысла в этом пункте поскольку не думал что squash кто-то использует вместо отправки серии коммитов. Но, конечно, если использует, то весьма зря, в качестве аргументов надо привести потерю информации о законченных этапах изменения, и как следствие невозможность нормального bisect.
К слову, subversion воспринимает ^M (\r) как перевод строки, поэтому в отличие от git позволяет писать из коммандной строки многострочные сообщения (^M вводится через Ctrl+V, Enter).А shell (любой, кроме совсем отмороженных вроде tcsh, которому нужно получить обратную косую черту перед вводом
<Enter>) позволяет набирать многострочные сообщения, просто не закрыв кавычку. Zsh, bash и ksh ещё позволяют использовать git commit -m $'Summary\n\nExtended description'.Поправил ещё раз с учётом вашей формулировки. Спасибо. -m как раз причём, так как пользователям часто лень экранировать или нажимать Enter посреди сообщения в вызове
Во втором случае как раз мы говорим о фиче-бранче, то есть залили в мастер и забыли. Можно удалять, переформатировать в тег, всё что угодно. Поэтому продолжение последовательности скорее такое
Третий пункт, таки да, если я правильно понял участника той беседы.
git commit -m … или они вообще забывают о такой возможности, и таким образом провоцирует запихнуть всё в одну строку. Почему я назвал стиль subversion? Потому как там это усилинно навязывалось (вот не помню такого в CVS), а ещё git svn при конвертировании из / в просто шедевры обрезания делает. Но окей, я заменил. Во втором случае как раз мы говорим о фиче-бранче, то есть залили в мастер и забыли. Можно удалять, переформатировать в тег, всё что угодно. Поэтому продолжение последовательности скорее такое
git push myFeature:master; git branch -m myNewFeature.Третий пункт, таки да, если я правильно понял участника той беседы.
НЛО прилетело и опубликовало эту надпись здесь
Думаю 80% программистов не понимают git, но боятся показать это, чтобы не выглядеть непрофессионалами.
Судя по реакции, я бы сказал, что даже больше. И самое печальное — не хотят понимать.
Проблема в том, что git слишком сложен и неадекватен. Так же как и его инструкции. Особенно на русском языке.
"git remote — работа с удаленными репозиториями." Это случаем не с теми которые уже удалили?
Вот еще из инструкции:
"Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url]"
Я вот например, честно думал, что git remote add прямо создает репозиторий на remote сервере.
Смешно, да?
Когда мне потребовалось влить submodule в главный проект с сохранением истории мне не смог помочь никто из мною опрошенных. На stackoverflow целая дискуссия была и 10 неработающих советов. Вот так.
"git remote — работа с удаленными репозиториями." Это случаем не с теми которые уже удалили?
Вот еще из инструкции:
"Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url]"
Я вот например, честно думал, что git remote add прямо создает репозиторий на remote сервере.
Смешно, да?
Когда мне потребовалось влить submodule в главный проект с сохранением истории мне не смог помочь никто из мною опрошенных. На stackoverflow целая дискуссия была и 10 неработающих советов. Вот так.
Вы выбрали какие‐то плохие примеры. Слово «удалённый» является весьма известным термином, не ограниченным git документацией и означает, в общем случае, «находящийся в удалении», а в IT — «в общем случае находящийся на другой машине» (часто частным случаем удалённого сервера или места может служить виртуальная машина здесь же или другой каталог). Кстати, в английской версии
Вторая часть притянута за уши: написано же «добавить», а не «создать». Ну и английская версия, как всегда, яснее.
Вот ужас, творящийся в
git help remote написано несколько другое: «git-remote — Manage set of tracked repositories».Вторая часть притянута за уши: написано же «добавить», а не «создать». Ну и английская версия, как всегда, яснее.
Вот ужас, творящийся в
git help rebase гораздо хуже: вместо того, чтобы использовать именованные параметры в стиле git rebase --source=topicB --target=master --from=topicA==git rebase -StopicB -Tmaster -FtopicA пишется ужас git rebase --onto master topicA topicB и всё это подробно поясняется в первой секции документации. В документации git pull который год написано «Options meant for git pull itself and the underlying git merge must be given before the options meant for git fetch» — и это вместо того, чтобы использовать getopt и разрешить пользователю вводить опции в любом порядке. Ну и, конечно, git pull и git push ну никак не могут использовать именованные параметры либо для аргумента >repository>, либо для <refspec>, вынуждая пользователя всегда вводить репозиторий, когда он хочет ввести только refspec.
А некоторые не боятся и пишут статьи.
Сквош (в том числе и через git rebase -i) хорош в случае пулл-реквестов перед их мержем — когда в процессе обсуждения фиксятся тесты, какие-то мелочи в рамках одной атомарной задачи. Т.е. тогда, когда история мелких диффов попросту не нужна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О Git, начинающих и статьях о Git для начинающих