В отличие от @richardolsson, я бы не советовал объединять master в свои ветки тем, если под merge мы подразумеваем git merge master.
Это определенно хорошая идея, чтобы они брали обновления, которые произошли на master, и обновляли свои ветки тем, чтобы отразить эти изменения, чтобы избежать ужасного разрушения, но git предоставляет немного лучший инструмент для этого конкретного использования. кейс, git rebase.
Концептуально они очень похожи, и результат с точки зрения кодовой базы часто идентичен, однако использование rebase может сделать историю проекта намного более понятной для того, кто просматривает журналы, и поможет избежать гигантской истории. График, чтобы просмотреть, хотя они могут выглядеть довольно мило.
Когда вы merge, git получает статус двух (или более) объединяемых ветвей, пытается соединить их соответствующим образом и делает коммит, отражающий, что слияние произошло, если только заголовок целевой ветви не является прямой потомок объединяемой ветви, и в этом случае ему не нужно делать какие-либо изменения / патчи, а просто воспроизводить коммиты друг над другом (git вызывает эту быструю пересылку).
Когда вы rebase, git (концептуально) берет целевую ветвь, возвращается к последнему коммиту, который имеет общее с веткой, на которую он перебазирован, делает коммиты из этой ветки, а затем делает коммиты из целевая ветка. Пример может быть в порядке:
У вас есть две ветви, master, с коммитами A, B, C и D и topic, которые были разветвлены на B и имеют коммиты A, B, E и F. Если вы используете topic и git merge master, вы можете получить историю фиксации, которая будет выглядеть как A B E F G, где G - это фиксация, сделанная путем слияния. Если вы перебазируете, git сначала берет topic и делает свою историю фиксации такой же, как master, а затем делает коммиты в topic, так что вы получаете историю фиксации, которая выглядит как A B C D E F.
Одним из основных преимуществ этого, помимо ясности в истории журналов, является то, что до тех пор, пока в master не было изменений с тех пор, как вы выполнили ребазинг, git checkout master && git merge topic или подобное всегда будет ускоренной перемоткой вперед, так как вся история master содержится в topic. Большое предостережение заключается в not перебазировании веток, которые предназначены для общего доступа, потому что SHA-1 коммитов необходимо переписать, что в основном означает кучу бессмысленных конфликтов.
Мне понадобилось какое-то время, чтобы это вошло в мою голову. С тех пор я обнаружил, что (по крайней мере для меня и до сих пор ...) "лучший" рабочий процесс заключается в следующем:
- перебазировать ветки тем
- отслеживание слияния веток
Что-то вроде:
git checkout topic
git rebase master
# fix any conflicts, run tests, etc
git checkout master
git merge topic
Это дает очень ясную историю и в значительной степени гарантирует, что если произойдет поломка, это произойдет в ветке темы. Это также делает некоторые инструменты, такие как git bisect, немного проще в использовании, когда вам нужно их использовать.
Во всяком случае, надеюсь, что вы нашли этот слишком длинный ответ полезным.