Имеется следующая ситуация. В ветке, при замене одного компонента на другой, один из разработчиков реализовал выпил старого и запил нового в одном коммите. На мои возражения, что такие изменения лучше делать в отдельных коммитах (причём, промежуточные коммиты не ломают сборку), он отказался от разбивки коммита на два до слияния его в основную ветвь. Хорошо, пускай, мне и для процесса разработки это не принципиально, и тратить время на споры я совсем не хочу. Я приверженец следующего подхода:
* Merged feature-2
|\
| * (any intermediate work if necessary)
| * Added the new component
| * (any intermediate work if necessary)
| * Removed the old component
| * (any intermediate work if necessary)
|/
* Merged feature-1
|\
| * Bla-bla-blah
Он предпочитает:
* Merged feature-2
|\
| * Replaced the component
|/
* Merged feature-1
|\
| * Bla-bla-blah
Хотя, очевидно, были разговоры и о таком раскладе:
* Replaced the component
* Bla-bla-blah
Я в этом не вижу большого смысла в git, потому что:
Отдельные коммиты позволяют проще отслеживать изменения, их логическую разбивку, а также ход разработки вообще.
Я могу грубо оценить временную шкалу изменений на ветке + ретроспектива.
Если коммиты разделены, я практически в любое время могу откатить любой коммит с помощью git revert, что весьма проблематично в случае больших squash-нутых коммитов.
Я в любой момент могу увидеть по сути такой же лог с помощью git log --merges --oneline --graph.
Кроме того, git diff между ветками также позволяет увидеть, что появилось и пропало на ветке.
И вообще, сам git предлагает отличный набор инструментов, чтобы просматривать историю как заблагорассудится. Больше преимуществ со своей стороны пока назвать не могу. Из минусов моего подхода, с которыми я согласен:
git rebase поверх основной ветки иногда может усложняться, но, с другой стороны, при маленьких коммитах справляться с конфликтами проще ввиду их меньших размеров.
Кривая настройка (или отсутствие поддержки) со стороны всяких там BitBucket и т.д. засоряет слияния неинформативными сообщениями типа Merge pull request #PULL_REQUEST_ID in REPOSITORY from BRANCH_NAME to BRANCH_NAME. Конечно, такие сообщения -- мусор.
Какие ещё преимущества предлагают и недостатки тянут за собой мой и его подход?
