Что делать, если твои коллеги(и ты сам) только что освоили git, и каммитят все подряд?

Question

[krll-k]

Дело в том, что история как бы должна отображать полезную информацию, -естественно это изменение с кратким описанием по определенной задаче. То что есть сейчас, это -большое количество мелких задач по исправлениям, мало задач больших на разработку, и всего три программиста. Меня это все не устраивает, в репозитории полный хаос. История ничего не отображает, коллеги на все забили.. Работаем так, т.к. никуда не деться, проект нужно закончить

Первоначально, что вы думаете глядя нашу историю? Предложите выход из сложившийся ситуации, не удивлюсь если вы когда то были в похожей ситуации.. Интересует: Что каммитеть, когда каммитеть, и с каким кратким описанием?

Comments

[Евгений Петров]

Судя по количеству правок вопроса, вы сами только что освоили форум:)

[krll-k]

@Petroveg, тссссс ;)

[StrangeAttractor]

"Как правильно писать комментарии к каммитам?" - на английском желательно.

[krll-k]

@StrangeAttractor почему?

[StrangeAttractor]

@krll-k Чтобы не ограничивать возможности будущего развития проекта программистами одной национальности. В один прекрасный день может появиться желание/нужда поработать с каким-то иностранным специалистом, а может и отдать часть проекта на аутсорс в Индию.

[krll-k]

@StrangeAttractor хаха, вы такой предусмотрительный :)) то есть вы хотите сказать мне нужно подтянуть свой английский, прекрасный предлог для этого :-)

Answer 1

[exvion]

Предпочитаю писать коммиты на английском языке. Для себя принял за правило начинать коммиты с глагола Add, Fix, Update, Remove, Move, Clean. Иногда в начало можно добавить название модуля, к которому относится коммит.

- RenderModule: Add support new feature (добавили новую фичу)
- Fix bug (исправили баг)
- Fix typo (исправили опечатку)
- Update script (оптимизировали алгоритм, ускорили работу функции)
- Move function to another class (рефакторинг)
- Remove (удалили неиспользуемую часть кода)
- Cosmetic changes (навели красоту в коде)

Можете придумать русские аналоги.

На Хабре появилась статья, дающая исчерпывающий ответ на этот вопрос.
Как следует писать комментарии к коммитам

Answer 2

[Артур Смирнов]

По большому счету, коммит - это завершенная семантически, минимальная операция. К примеру, "Убрал кнопку", "Исправил опечатку", "Добавил новое поле", "Исправил ошибку такую-то". Ведь есть такая штука, как blame, которая позволяет увидеть в любом файле построчно, кто и что менял. Кто меня - понятно, а вот "что менял" как раз и берется из сообщения коммита. То есть, коммиты должны быть маленькими, семантически законченными, сообщение должно отражать суть изменения. Тогда историю можно будет удобно использовать.
Для отдельных задач всегда делается отдельная ветка, пусть даже в ней будет один коммит. Потом эта ветка мержится в основную после code review.

Вообще, есть отличная методология работы с git - git-flow. Вот хорошая статья на хабре об этом: Почему вы до сих пор не используете git-flow?

Answer 3

[Андрей Федоров]

Мое мнение такое: коммит должен описывать коротко и ясно проделанную задачу в нем.
То есть если нельзя описать емко все изменения в задаче - то надо разбивать на коммиты заранее.
К примеру:

# git status -s
M README.txt
M main.h
# git add main.h && git commit -m "Thread support"
# git add README.txt && git commit -m "Readme information"

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

Comments

[Алексей]

Какие-то странные у вас примеры. Все приведенные "проблемы" решаются вспомогательными инструментами, а то и вообще без них. Если просматривать не только сообщения к коммитам, а и измененные в них файлы (например, тот же TortoiseGit так умеет отображать историю) - уже понятно, где именно были изменения, и сообщение "забыл картинку" обретает смысл.
Для того чтобы узнать, где производились изменения в том, или ином механизме - можно смотреть историю изменений конкретных файлов/папок, а не пытаться играть в Шерлока Холмса.
Так что я бы, как минимум, слово "необходимо" заменил бы на что-то менее строгое.

Answer 4

[ixSci]

Как раз недавно написал заметку на эту тему. Прочтите,- может что-то вынесете для себя.

Answer 5

[Пума Тайланд]

в целом достаточно понятные и разнообразные коммиты, не очень понятно чем они вам не нравятся?
большие задачи оформлять в один коммит , но вижу что у вас все маленькие и объединять их нет смысла

Comments

[krll-k]

@opium, скорее всего нам нужен один главарь банды(тимлид), который будет бить по шапке всех неродивых. Делов в том что меня такая картина(на скрине) неустраеват. Что посоветуешь?

[Пума Тайланд]

расскажите чем она вас не устраивает? сложно что то советовать если вы не говорите ваших условий.

[krll-k]

@opium, хочется чтобы случилась красата в истории. Хочется узнать, что есть хорошо, а что есть плохо. Допустим, то что на скрине по моему мнению плохо(явно что не хорошо). Можешь сказать что есть хорошо?

[Пума Тайланд]

на мой взгляд достаточно хорошо, неплохо бы конечно ещё иметь таск трекер и привязку коммитов к таскам, у вас похоже разработка только началась и ведется довольно хаотично, но это явно не проблема использования гита, будут более крупные задачи будут и реже коммиты и наверно у вас наступит счастье.

[krll-k]

@opium, а можно делать каммиты без комментариев? Что указывать в том случаи если сделал небольшую правку, и вовсе бы не стоило делать коммит? Есть возможность перебрать коммиты, то есть почитстить через объеденение? Понимаете о чем я говорю?

[Пума Тайланд]

можно конечно, сразу после этого надо отрубить пальцы этому разработчику топором, другие разработчики это увидят и больше так делать не будут.
любая правка это коммит, нет ничего плохого в этом , то что это плохо вы придумали себе сами, если конечно маленькая правка не кусок какой то более цельной задачи из таск трекера, то логично такие вещи делать в отдельном бранче и вливать в главную ветку как отдельный коммит один
есть git rebase и git stash и многие другие штуки для изменения истории гита.
сказать честно до конца не понимаю

[krll-k]

@opium, спасибо за разяснение, я понял. в любом случаи нужно будет копать инфу, и договариваться с командой

Answer 6

[evnuh]

Неверные ответы вам дают и вы тоже неверно мыслите.
Гит как раз и создан был для сохранения состояния, то есть каждый коммит - это снапшот кода. Некий аналог ctrl+s, если хотите. Коммиты не должны быть привязаны ни к задачам, ни к фичам, ни к багам, ни к чему остальному. Можно хоть каждые 5 секунд коммитить по букве, и ладно. Для управления фичами/багами/etc. есть ветки (не даром они очень легкие). Одна фича - одна ветка. Внутри ветки хоть 500 коммитов, но как только работа завершена - делается pull request и фича мерджится.
На историю коммитов никто не смотрит, смотрите на дерево коммитов.

Comments

[sim3x]

если нет привязки к таскам, то как трекать потраченное время?

[Opaspap]

@sim3x писать номер таски в коменте типа так #48

Answer 7

[Сергей]

Правило одно: Каждый каммит не должен ломать работоспособность ПО, и быть законченным целым одной небольшой задачи (этапа и т.п).

Другой вопрос, что не всегда такое имеет место быть. Поэтому не беспокойтесь об этом. Чем меньше каммит, тем лучше.

Comments

[zed_0xff]

кОммит

[Андрей Федоров]

Как же не должен ломать? А если костяк реализован, а в сложных методах которые еще не реализованы выбрасываются исключения "Not implemented yet"? Это же тоже по идее не рабочий код, но коммит имеет смысл делать. К примеру делается дальше две ветки и каждый из сложных методов отдается другим разработчикам.

[klirichek]

Наверное, имеет смысл уточнить: каждый коммит в мастер

Answer 8

[Дмитрий]

Как вариант: заводится трекер задач (redmine например), в нём описывается всё подробно, а коммиты и ветки ссылаются на номера задач, ключевые точки и версии.

Answer 9

[Павел]

Gerrit Вам поможет.
https://code.google.com/p/gerrit/

Answer 10

[safinaskar]

Коммитят, а не каммитят