Я всегда считал, что в процессе разработки проекта стоит осуществлять один
commit для одного задания. Этот процесс приблизительно выглядит вот так:
- Для нового задания создаем новую ветку на основе нашей тематической ветки
git checkout -b new_issue.
- Осуществляем все
commit в эту ветку.
- Когда разработка закончена, можно применить
squash для этих commit, сжать их в один и сделать rebase в нашу тематическую ветку.
- Если что-то пошло не так, мы можем откатить этот
commit и все станет по прежнему. Найти баг, исправить его и накатить сверху исправление. (Историю удаленного репозитория мы не изменяем).
Но возможен и такой подход:
- Для нового задания создаем новую ветку на основе нашей тематической ветки
git checkout -b new_issue.
- Осуществляем все
commit в эту ветку.
- Потом
merge этой ветки в тематическую ветку с флагом--no-ff, в этом случае у нас будет commit-слияние, который, если что-то пошло не так, мы тоже можем откатить, исправить и снова совершить commit.
- Но тут у нас есть один плюс, мы можем использовать команду
git bisect для того, чтобы найти какой именно commit поломал все.
Используя подход 1, мы будем иметь хорошую историю в git,
commit будет атомарной единицей, но при нахождении ошибки нам иногда придется пересмотреть кучу файлов.
В подходе 2, мы будем иметь страшную историю, она будет длинной и запутанной, состоять из кучи commit-слияний. Но в этом случае мы сможем использовать магию
git bisect, что позволит найти баг быстрее. (Возможно этот способ стоит использовать при исправлении legacy кода или рефакторинге).
Я понимаю, что возможно, это вопрос больше о персональных предпочтениях, но хотелось бы узнать, какую практику предпочитаете вы? Какие ещё могут быть проблемы при таких подходах? Возможно вы можете предложит что-то другое?
UPD: Друзья, предпочитающие делать много коммитов. Вам действительно легче находить баги в таком случае или это только плацебо для вас? Как вам это помогает? Пользуется ли кто-то реально
git bisect?
