Избирательный подход мерзавца и целостность модели данных
Учитывая, что два ответвления отличались, и определенная фиксация от одного ответвления (и не все) должна быть представлена другому, избирательный подход мерзавца достигает точно этого.
Через какое-то время существует потребность полностью объединить два ответвления. Как мерзавец будет знать, что это уже имеет фиксацию, которая избирательно подошлась к выбору в прошлом так, чтобы это не повторно вводило его?
2 ответа
Вы можете прочитать
Git Cherry-pick против рабочего процесса слияния для хорошего сравнения слияния и выбора вишни, особенно этой вишни. -pick не хранит родительский идентификатор, и, следовательно, не знает, что у него уже есть фиксация, выбранная в прошлом, чтобы не вводить ее повторно.
и
http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commit/ о том, как избежать дублирования коммитов в этом случае с помощью перебазировать .
В статье « предотвращение дублирования фиксации », упомянутой в ответе Тонио , говорится :
Представьте, что у нас есть ветка master и ветка 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 добавляет в комментарий:
Но все же кажется, что я не совсем понимаю, как работает перебазирование .. Я имею в виду, что даже после перебазирования не должны ли все еще появляться коммиты, выбранные вишенкой?
Нет. На странице руководства git commit явно упоминается:
Если ветвь восходящего потока уже содержит внесенное вами изменение (например, из-за того, что вы отправили по почте патч, который был применен в восходящем направлении), , то эта фиксация будет пропущена .
Например, запуск git rebase master для следующей истории (в которой A 'и A вводят один и тот же набор изменений, но имеют разную информацию о коммиттере):
A---B---C topic
/
D---E---A'---F master
приведет к:
B'---C' topic
/
D---E---A'---F master
Вы можете определить, присутствует ли уже фиксация на главном сервере, с помощью git cherry master (если вы находитесь в ветке тема ).