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

43aa44eb1839402991f5ae8128442239.png

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

Первоначально, что вы думаете глядя нашу историю? Предложите выход из сложившийся ситуации, не удивлюсь если вы когда то были в похожей ситуации.. Интересует: Что каммитеть, когда каммитеть, и с каким кратким описанием?
  • Вопрос задан
  • 5817 просмотров
Решения вопроса 4
@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 (навели красоту в коде)

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

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

Вообще, есть отличная методология работы с git - git-flow. Вот хорошая статья на хабре об этом: Почему вы до сих пор не используете git-flow?
Ответ написан
Мое мнение такое: коммит должен описывать коротко и ясно проделанную задачу в нем.
То есть если нельзя описать емко все изменения в задаче - то надо разбивать на коммиты заранее.
К примеру:
# 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"

А у вас же что не красиво, непонятно из текста совершенно что же в комите.
Кто намержил опять эти файл? - какие файлы? Что случилось?
Забыл добавить картинку. - Что за картинку, где?
Необходимо что бы можно было читать коммиты и было понятно что произошло. К примеру вы возьметесь искать где произошел баг с окном авторизации, и как быстро отыскать коммиты причастные к нему? По веткам в первую очередь - к примеру видно что ветка называется "клиентские отчеты" - ясно что там не затрагивали авторизацию. Откатываетесь до другой ветке - баг есть? Ага, локализовали инфу, и смотрите по коммитам, "Изменили текст в авторизации, исправили опечатки" - ага, не то итд итп.
Ответ написан
ixSci
@ixSci
Как раз недавно написал заметку на эту тему. Прочтите,- может что-то вынесете для себя.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
opium
@opium
Просто люблю качественно работать
в целом достаточно понятные и разнообразные коммиты, не очень понятно чем они вам не нравятся?
большие задачи оформлять в один коммит , но вижу что у вас все маленькие и объединять их нет смысла
Ответ написан
evnuh
@evnuh
Поиск Гугл помог мне, впусти и ты его в свой дом
Неверные ответы вам дают и вы тоже неверно мыслите.
Гит как раз и создан был для сохранения состояния, то есть каждый коммит - это снапшот кода. Некий аналог ctrl+s, если хотите. Коммиты не должны быть привязаны ни к задачам, ни к фичам, ни к багам, ни к чему остальному. Можно хоть каждые 5 секунд коммитить по букве, и ладно. Для управления фичами/багами/etc. есть ветки (не даром они очень легкие). Одна фича - одна ветка. Внутри ветки хоть 500 коммитов, но как только работа завершена - делается pull request и фича мерджится.
На историю коммитов никто не смотрит, смотрите на дерево коммитов.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Правило одно: Каждый каммит не должен ломать работоспособность ПО, и быть законченным целым одной небольшой задачи (этапа и т.п).

Другой вопрос, что не всегда такое имеет место быть. Поэтому не беспокойтесь об этом. Чем меньше каммит, тем лучше.
Ответ написан
deemytch
@deemytch
linux root, ruby/perl programmer, sql, backend.
Как вариант: заводится трекер задач (redmine например), в нём описывается всё подробно, а коммиты и ветки ссылаются на номера задач, ключевые точки и версии.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы