Почему я должен удалять ветки функций при объединении с мастером

Ответ 1

Что-то важное для понимания - ветки Git - это не что иное, как ярлык, указывающий на фиксацию. Ветвление в Git буквально разветвляется. Вот как выглядит репозиторий, если feature разветвлено master, когда master было фиксацией B.

A - B - C - F - H [master]
     \
      D - E - G - I[feature]

См? Фактическая ветвь. Когда вы git merge feature в мастер, вы получите это.

A - B - C - F - H - J [master]
     \             /
      D - E - G - I  [feature]

И как только вы git branch -d feature история ветвей остается!

A - B - C - F - H - J [master]
     \             /
      D - E - G - I

J имеет родителей H и I. J не может существовать без них, он запекается в том, как работает Git. Я не могу существовать без G. G не может существовать без E. И так далее. Филиал должен оставаться

J - это фиксация слияния, которая, как правило, содержит имя объединенной ветки. Это похоже на любой другой фиксатор, поэтому вы можете добавить к нему дополнительную информацию, например ссылку на ваш трекер.

git merge --no-ff используется для предотвращения Git выполнения "быстрой перемотки вперед" и потери истории ветвлений. Это происходит, если не было сделано никаких работ на master, так как была создана ветка. Быстрая перемотка выглядит так.

A - B[master]- D - E - G - I [feature]

git checkout master
git merge feature

A - B - D - E - G - I [feature] [master]

Так как master является прямым предком feature, никакого слияния не требуется. Git может просто перемещать метку master. История вашего ветки потеряна, похоже, что D, E, G и я все были сделаны как отдельные фиксации на хозяине. git merge --no-ff сообщает Git, чтобы никогда не делать этого, чтобы всегда выполнять слияние.

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

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

Во-вторых, и что более важно, это не позволяет вам повторно использовать ветку. Ветвление и слияние сложны. Однопользовательские, недолговечные ветки функций упрощают процесс, гарантируя, что вы когда-либо объединяете ветвь обратно в мастер. Это устраняет многие технические проблемы и проблемы управления. Когда вы объединяете ветку, это делается. Если вам нужно исправить проблему, появившуюся в этой ветке, просто рассматривайте ее как ошибку в главном и создайте новую ветвь, чтобы ее исправить.

К сожалению, git log принадлежит пользователю и представляет линейное представление истории, которое не является линейным. Чтобы исправить это, используйте git log --graph --decorate. Это будет рисовать строки, как в моих примерах выше, и показывать вам любые ветки и теги для каждой фиксации. Вы получите более точное представление о репозитории.

Если вы находитесь на Mac, GitX отобразит репозиторий для вас. gitk является общей версией.

Ответ 2

Поскольку история ветвей myfeature представляет все промежуточные фиксации, выполненные для реализации myfeature.

Эта стратегия сохраняет только одну фиксацию в master и забывает о промежуточных шагах, что имеет смысл для долгоживущих ветвей, как я объяснил в "Почему git ускоренное слияние по умолчанию?".

Сообщение о фиксации сделанного (объединенного) фиксации в master должно очистить его для реализации "myfeature".

Если это необходимо устранить, имя ветки можно повторно использовать (поскольку оно было удалено раньше).