Если вы сделаете git log
, ветки «feature» не будут отображаться, чего мы и хотим. Тем не менее, каждый коммит, который сделал разработчик, теперь отображается в ветке devel.
git log
по умолчанию показывает линейную версию истории, которая является простой и ложной. История Git не линейна. Ветви действительно ветвятся.
Вместо этого ...
A - B - C - D - E - F - G - H [devel]
Ваша история действительно выглядит так.
A ---------- E ----- H [devel]
\ / \ /
B - C - D F - G
Это можно увидеть с помощью git log --graph
или инструмента визуализации Git, например Gitup .
Каждый из этих «пузырей функций» - это коммиты из каждой ветви. Используя реальную историю, вы можете увидеть, какие коммиты были разработаны как часть одной функции. Хотя это может показаться «грязным», это важно для понимания кода. Это особенно полезно вместе с git blame
.
Есть ли какой-нибудь способ избежать "запутывания" истории и игнорировать историю локальной ветви при слиянии? Или это просто бои с мерзавцем?
Мой совет - привыкнуть к нему и научиться ориентироваться в нем. Например, git log --merges
будет отображать только коммиты слияния. Хороший инструмент визуализации Git очень поможет.
Другой способ - побудить разработчиков очистить свои ветки перед их фиксацией. Если у вас есть много коммитов, которые "исправляют опечатку" и "упс" и "не прошли тесты", они не будут иметь большого значения в будущем. Они могут использовать git commit --amend
для изменения предыдущего коммита и git rebase -i
«fixup» для объединения существующих коммитов вместе . Это гарантирует, что все коммиты имеют какое-то значение.
Если вы действительно хотите, вы можете сделать «слияние в сквош», git merge --squash
. Вместо сохранения полной истории коммитов все изменения и все сообщения коммитов в ветке разбиваются в один коммит.
Хотя это создает «чистую» историю, он теряет много детальной информации о том, как был разработан код. Например, если в ветви 30 коммитов, и вы делаете git blame
, чтобы понять какой-то код, вы получите сообщения о коммите для всех 30 коммитов без возможности узнать, какой из них применяется к коду.
То, что вы видите как "грязный", является ценным пониманием , почему код был написан таким, какой он есть. Это золото для всех, кто работает с кодом в дальнейшем. Разобравшись, его никогда не восстановить.