Pull to refresh

Comments 34

Используйте повелительное наклонение в заголовке

Для комментариев на русском языке (в приведенном примере комментарий именно на нем, родимом) смотрится крайне неестественно.
Повелительное наклонение все-таки предназначено для постановки задач, в то время как описание коммита про уже сделанное.
Логичнее бы смотрелось существительное, описывающее процесс, или прошедшее время.

Естественно в оригинале комментарии приведены на английском языке. Мы перевели их для того, чтобы было понятно о чем идет речь. Но, возможно Вы правы и имеет смысл оставить их без перевода.
Лично для меня, повелительное наклонение в заголовке смотрится одинаково неестественно и на английском, и на русском. Но, похоже, это общепринятая практика. Предполагаю, что это делают для упрощения синхронизации с баг-трекером, JIRA и т.п. Появилась у вас задача «FOW-1327. Add error message when user has no access to review», вы ее выполнили, и имя задачи превратилось в имя коммита.

Нашей конторе это не поможет… Тестировщики то и дело присылают задачи с заголовком "Ошибка программы". И когда таких задач несколько к ряду — утомительно заглядывать в каждую и определять, в какой области, хотя бы, проблема.

Сочувствую. Разработчики тоже всякие бывают. У нас один особо одаренный вообще не заморачивался с наименованием коммитов, а тупо писал «Реализация». Буквально, одно слово, без пояснений. Смотришь ветку — а там 20 штук «реализаций» подряд :) И ведь не врет, там и правда фичи реализуются, все чОтко.
Даже номер задачи, получается, не указывал?
Повелительное наклонение все-таки предназначено для постановки задач, в то время как описание коммита про уже сделанное.
Можно посмотреть на это с другой стороны. Описание коммита говорит от том что будет сделано если вы «чери-пикнете» его или сделаете слияние ветки с этим коммитом.

Обычно в каждой компании свой стиль коммитов. И это довольно неудобно...


Используйте повелительное наклонение в заголовке

Это применимо к английскому языку, в котором повелительное наклонение образуется как слово в инфинитиве без "to". В статье по ссылке примеры типа "if applied, this commit will fix bug #100500" В русском языке обычное повелительное наклонение будет звучать в заголовке очень странно ("исправь(те) баг №100500"), а форма повелительного наклонения, совпадающая с инфинитивом ("исправить баг №100500"), будет выглядеть чуть менее странно. Наверно, для русского языка нужно использовать инфинитив, а не "обычное" повелительное наклонение, если применять такую логику.

Интересная статья, спасибо. Переводить комментарии комитов не обязательно, ведь они и так всегда пишутся на английском.


Я так понимаю к категории "feat" относятся не только новые функции но и изменения в существующих? Куда в таком случае отнести оптимизацию?

Переводить комментарии комитов не обязательно, ведь они и так всегда пишутся на английском.

всегда пишутся на английском

Но почему? Не все работают на забугорье. Почему в чисто русскоязычной команде документация (коммиты) должна быть на английском? Некоторые изучали немецкий, и не владеют английским в достаточной мере. да и немецким тоже

Да никто никому ничего не должен, это лишь рекомендации, но ведь так проще: не надо переводить на русский термины из предметной области, имена классов и функций. Когда всё на одном языке, как-то проще работается, избегаются проблемы неточного перевода, да и потом, когда команда разрастется или изменится, поддержку продукта передадут в другую, не русскоязычную команду или даже компанию, будут проблемы. Но если с английским совсем уж туго, то пожалуйста. Процессы должны помогать, а не наоборот. Если это создаёт больше проблем, чем решает, то игнорируйте данный совет. Это лишь набор рекомендаций.

Как вариант:
Add: Подсветка синтаксиса в редакторе (some_edit_form.php)
Del: Устаревший код и неактуальные комментарии в mycode.php
Fix: В форме «some_edit_form.php» поменял «Обновить» на «Сохранить»

Сразу видно, что сделано в данном коммите.

Подробное описание того, что сделано в коммите — часто бесполезная информация, это и так видно из самого коммита. Лучше писать почему это сделано именно так, а не иначе, какие были причины и мотивы, как принималось решение. Через год-два это будет намного интереснее.

Подобное описание часто помогает быстро найти коммит в котором «всё сломали».
Или просто, при просмотре истории сразу видно — кто когда и что делал. Не надо смотреть конкретные коммиты или историю конкретных файлов — всё уже на виду.

Ну а про «Историю принимаемых решений» — иногда ведут багтрекер (не на гите) и обсуждения ведутся там, а в историю гита помещается ссылка на соответствующее обсуждение. Или на запись в форуме/чате/вики…

Такой вариант тоже возможен, да. У меня просто, как правило, бывает цепочка такая: наткнулся в коде на странное место, запустил git blame, перешел на эту строчку, взял id коммита, а дальше git show . Оно сразу и коммент покажет, и автора, и время, и целиком то, что поменялось в этом коммите, всё на виду. Про багтрекеры и вики — полезно, да, и всё прекрасно, правда до тех пор пока они не грохнулись или не случится переезд с одной системы на другую, помню, долго мигрировали с ClearQuest в Jira, а перед этим в ещё из какой-то системы в ClearQuest… В идеале, конечно, происходит миграция старых тикетов в новую систему, но не всегда это проходит гладко, что-то теряется, ссылки и id становятся неактуальными, искать только полнотекстовым поиском по дескрипшену или комментам в тикету и надеяться что при миграции старый id корректно записался в комменты, и так далее..

Зачем далеко ходить, когда краткое саммари обсуждения, если такое было, можно прописать в коммит? Жалко одного-двух предложений?

Или даже так:


[+] Подсветка синтаксиса в редакторе (some_edit_form.php)
[-] Устаревший код и неактуальные комментарии в mycode.php
[*] В форме «some_edit_form.php» поменял «Обновить» на «Сохранить»

и так далее

Мы применяем нечто подобное, но без скобок [].

Чаще всего делаю комиты когда заканчиваю работать на одной машине чтобы потом продолжить работу на другой. Какой там нужно делать коментарий?

Если при этом принципиально именно сделать коммит и запушить его, то сделать отдельную ветку под эту задачу, закоммитить с комментарием "WIP", а потом, на другой машине, когда доведёте до логического конца, сделать commit --amend, написать новый комментарий, и запушить с --force обратно. Либо, что проще, не делать коммит вообще, а просто что-то вроде git diff > my_patch.diff && scp my_patch.diff remotehost:~/, а там уже git apply ~/my_patch.diff — продолжаете работать.

WIP (..., ++, etc) это понятное решение. Ветка это вообще не обсуждается, как само сабой разумеющиеся. Но вот откуда, я не понимаю, это желание сделать много лишних телодвижений (типа аменда или дифа) только для того, чтобы такие комментарии не попадали в систему контроля версий? Что в них плохого?
Того, что коммит не является фиксацией законченной части решения задачи.

Если вы работаете с этим репозиторием один, то ничего плохого, дело ваше. Но надо уважать своих коллег, я считаю, иначе как потом анализировать историю изменений среди всего этого мусора? Коммит должен быть атомарным, то есть состояние системы должно быть законченное в какой-то степени. И не должен содержать побочных изменений, только что-то неразрывно связанное между собой. Это делается в том числе для того, чтобы можно было легко что-то откатить в случае необходимости, не затрагивая лишнее, и чтобы при этом система осталось рабочей.

Просто в применении dif'а вместо git'а я вижу первый шаг к тому, чтобы предложить создать zip-архив с git репозиторием и тащить его домой на флешке. И всё ради красоты в твоей личной ветке репозитория.
Атомарность коммита это очень хорошо, но работает только когда программист сидит за рабочим местом круглые сутки и никогда не переключается от своей задачи к другой. А что делать, если при реализации какой-то фичи в коде тебе вдруг приходят и говорят срочно исправить баг в другой твоей фиче? Неужто клонировать проект в другое место? Если работник уезжает в отпуск, не доделав фичу? Если офис переезжает? Если проходит плановый апгрейд рабочего места?
Просто в применении dif'а вместо git'а я вижу первый шаг к тому, чтобы предложить создать zip-архив с git репозиторием и тащить его домой на флешке. И всё ради красоты в твоей личной ветке репозитория.

Это не так. Во-первых, не вместо git'а, а с его же помощью, это часть его функционала. Во-вторых, вариант с diff-ом я предложил как ещё один альтернативный вариант (не основной) применительно к одной конкретной ситуации — когда вам нужно быстро переключиться с одной машины на другую с минимумом телодвижений и без необходимости делать временные коммиты, добавлять файлы в них и придумывать для этих временных коммитов комментарии типа WIP. Такой ведь был изначально вопрос? Применять это для чего-то ещё я смыла не вижу. Каким боком это ведет к zip-архиву на флешке, я тоже не понимаю.


Атомарность коммита это очень хорошо, но работает только когда программист сидит за рабочим местом круглые сутки и никогда не переключается от своей задачи к другой. А что делать, если при реализации какой-то фичи в коде тебе вдруг приходят и говорят срочно исправить баг в другой твоей фиче? Неужто клонировать проект в другое место? Если работник уезжает в отпуск, не доделав фичу? Если офис переезжает? Если проходит плановый апгрейд рабочего места?

Не понимаю, в чем проблема-то? Значит делаете коммит в том состоянии, как есть сейчас, и переключаетесь на другую задачу. Если нужно ехать в отпуск или кто-то другой будет это допиливать — пушите этот коммит в отдельную ветку на сервере. Локально / на неофициальных ветках можно творить что угодно. Но перед мержем в мастер / релиз хорошим тоном считается всё причесать, хотя бы из чувства уважения перед коллегами, которым придётся через год в этом копаться.

А что делать, если при реализации какой-то фичи в коде тебе вдруг приходят и говорят срочно исправить баг в другой твоей фиче? Неужто клонировать проект в другое место?

Можно использовать git worktree.

Либо, что проще, не делать коммит вообще, а просто что-то вроде git diff > my_patch.diff && scp my_patch.diff remotehost:~/, а там уже git apply ~/my_patch.diff — продолжаете работать.

Имхо, это сомнительное "развлечение". Git как раз и предназначен для автоматического выполнения этих действий. С Git'ом это быстрее, надёжнее, удобнее. Я отношусь к системе Git как к инструменту, а не как к идеальной летописи, и поэтому допускаю в таких случаях неатомарные коммиты на неосновных ветках. При желании можно делать rebase --interactive и исправлять историю. Можно даже создавать отдельную ветвь на каждый неатомарный коммит, а потом объединять такие коммиты, как надо. Но, имхо, в этом немного смысла.
Так-то, я видел даже бэкапы git-репозиториев в zip архивах, и даже слышал про скрипты создания подобных архивов с возможностями оставить комментарий и применить патч. Но зачем это всё, когда информация в git автоматически реплицируется на несколько компьютеров, патчи применяются автоматически, комментарии и так предусмотрены, ещё и удобные gui инструменты для этого есть?

Да я просто накидываю разные варианты что делать, когда лень придумывать коммент для коммита :)


Я отношусь к системе Git как к инструменту, а не как к идеальной летописи, и поэтому допускаю в таких случаях неатомарные коммиты на неосновных ветках. При желании можно делать rebase --interactive и исправлять историю. Можно даже создавать отдельную ветвь на каждый неатомарный коммит, а потом объединять такие коммиты, как надо.

Так я то же самое и написал в первую очередь, как основной вариант.


Но, имхо, в этом немного смысла.

Смысл лишь в поддержании порядка и удобстве потом, когда надо change log собрать или что-то откатить. Откатывать атомарные коммиты куда проще.


Насчёт второго варианта, быстрее и удобнее — не всегда, бывает наоборот, сравните:


git status
git add file1 file2 file3 fileN
git commit 
git push

и


git diff > patch
scp patch ...

Использовать commit -a чтобы автоматически все файлы добавить не всегда прокатывает, потому что бывает что есть левые изменения, которые не нужны в коммите, и тогда либо добавлять все нужные файлы руками, либо commit -a и их потом придётся выковыривать с помощью всяких там ресетов и интерактивных ребейзов. Поэтому что "быстрее, надёжнее, удобнее" зависит от ситуации.


Применяйте то, что знаете, и то, что вам удобнее.

git diff > patch
scp patch ...

Если вместо "..." набирать реальные имя сервера, опции, логин, порт, пароль (опционально), имя каталога на сервере, то эти команды подлиннее будут. А значит, это сложнее (нужно всё данные вспоминать), есть возможность ошибиться и потерять данные.
Строка git add -A . && git commit -m "WIP" && git push менее подвержена ошибкам. В git уже есть конфигурация параметров ssh.
С копированием патча на флешку суть примерно такая же.


git status
git add file1 file2 file3 fileN
git commit
git push

В git extensions (правда, он под виндой) эти действия (в варианте -a) выполняются примерно в 4 нажатия кнопки мыши. Если нужно фиксировать не все файлы или не все изменения в файле, в gitextensions опять же есть такая возможность в GUI.

Да ради бога, как удобнее в вашей ситуации, так и делайте. Логин скорее всего не нужен так как совпадает с текущим обычно, порт как правило дефолтный, пароль либо запрашивается либо не нужен если по ключам авторизация идёт, каталог может быть ~/ или /tmp, имя сервера копируется из соседней вкладки консоли, ведь вам и так надо залогиниться туда чтобы продолжить работу и вы его так и так знаете… Так что в моём типичном случае всё ограничивается "scp patch server2:~/".


Если в вашем случае это получается сложнее, то спокойно не используйте, как будто вас кто-то заставляет делать именно так и никак иначе. Если в какой-то ситуации этот прием пригодится — хорошо. Не пригодится — тоже хорошо. Удобнее тыкать мышкой — да пожалуйста. Нужно пользоваться тем, что привычно и удобно.

Не знаю почему, но многие знакомые и я ставим три точки в таком случае

WIP (work in progress) ...

Only those users with full accounts are able to leave comments. Log in, please.