Учитывая, что две ветки расходятся, и конкретная фиксация из одной ветки (и не все) должна быть введена другой, git выбор вишни достигает именно этого.
Через некоторое время возникает необходимость полностью объединить две ветки. Как git знает, что у него уже есть фиксация, которая была выбрана в прошлом, так, чтобы она не возвращала ее?
Возможно, вы захотите прочитать
Git Cherry-pick vs Merge Workflow для хорошего сравнения между слиянием и вишней, особенно, что вишня-pick не хранит родительский идентификатор и, следовательно, будет не знать, что у него уже есть фиксация, выбранная в прошлом, чтобы она не возвращала ее.
и
http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/ о том, как избежать дублирования коммитов в этом случае, используя rebase.
" избегать дублирования фиксации", упомянутая в tonio answer говорит:
Предположим, что у нас есть главная ветвь и ветка b:
o---X <-- master
\
b1---b2---b3---b4 <-- b
Теперь нам срочно нужны коммиты b1 и b3 в master, но не остальные коммиты в b. Итак, что мы делаем, это проверка, что главная ветвь и вишневый захват совершают b1 и b3:
$ git checkout master
$ git cherry-pick "b1’s SHA"
$ git cherry-pick "b3’s SHA"
Результат:
o---X---b1'---b3' <-- master
\
b1---b2---b3---b4 <-- b
Предположим, что мы делаем еще одну фиксацию на master, и получаем:
o---X---b1'---b3'---Y <-- master
\
b1---b2---b3---b4 <-- b
Если бы мы теперь объединили ветвь b в master:
$ git merge b
Мы получили бы следующее:
o---X---b1'---b3'---Y--- M <-- master
\ /
b1----b2----b3----b4 <-- b
Это означает, что изменения, введенные b1 и b3, появятся дважды в истории. Чтобы избежать этого, мы можем переустановить вместо слияния:
$ git rebase master b
Что даст:
o---X---b1'---b3'---Y <-- master
\
b2---b4 <-- b
Наконец:
$ git checkout master
$ git merge b
дает нам:
o---X---b1'---b3'---Y---b2---b4 <-- master, b
(после этот поток)
OP добавляет в комментарий:
Но все же кажется, что я не совсем понимаю, как работает rebase. Я имею в виду, что даже после перезагрузки не должны появляться вишневые коммиты?
Нет. git commit man-страница явно упоминает:
Если ветка восходящего потока уже содержит изменение, которое вы сделали (например, поскольку вы отправили по почте патч, который был применен вверх по течению), , то это сообщение будет пропущено. < ш > Например, запустите git мастер переадресации в следующей истории (в которой A и A вводят один и тот же набор изменений, но имеют различную информацию о коммиттерах):
A---B---C topic
/
D---E---A'---F master
приведет к:
B'---C' topic
/
D---E---A'---F master
Вы можете обнаружить, что фиксация уже присутствует на master с помощью git cherry master (если вы находитесь в ветке topic).