Слежение за слиянием для Git cherry picking?

Question

Например, у меня есть ветка dev и ветка stable.

В случае, если у меня есть вишня, сделайте выбор с dev по номеру stable.

Есть ли способ, чтобы Git знал о выбранных вишневых коммитах и ​​избегал двойного слияния, если я позже слияю, переустанавливаю или вишневую подборку наложенного диапазона, от dev до stable? (Для которых является основным слияния функция слежения в SVN)

Answer 1

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

Для каждой напечатанной фиксации знак «+» означает, что вы можете объединить его, знак «-» означает, что вы уже вишнево выбираете, что совершить.

Выход не очень красивый.

Для тех, кто пришел из SVN и используются для svnmerge.py, я сделал «svnmerge -l безрезультатно» эквивалентный Баш скрипт для мерзавец, что я назвал gitavail:

#!/bin/bash 

# get current branch 
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) 

# get tracked branch (1st argument), if no arg or arguments are only options, assume master 
if test -z $1 || grep -q '^-' <<< $1; 
then TRACKED_BRANCH=master 
else TRACKED_BRANCH=$1; shift 
fi 

# Log commits available for merge from tracked branch 
LOG_OPTIONS=$* 
for i in $(git cherry $CURRENT_BRANCH $TRACKED_BRANCH | egrep '^\+' | awk '{print $2}'); do git --no-pager log -n1 $i ${LOG_OPTIONS}; echo; done 

Предполагая, что вы на ветке, и вы хотите перечислить, что имеет право на слияние с главной ветви, просто запустите:

gitavail --name-status 

и вы будете иметь выход очень похожий на «svnmerge помогло -l».

Я полагаю, что изменения вишни не должны быть изменены вручную (как насчет конфликтов?), Если изменения patch id, git cherry не поймет, что фиксация уже выбрана вишней.

Answer 2

git cherry-pick смешной случай git rebase, а не git merge, так что на самом деле перезаписывает фиксации вы вишней поэтому он будет применять те же изменения в верхней части ветви ты вишневый. Поскольку идентификаторы фиксации git основаны на содержимом коммита, новый коммит имеет другой идентификатор и поэтому считается совершенно другой фиксацией git.

git merge, с другой стороны, создает фиксацию слияния; это средство, с помощью которого git реализует отслеживание слияния. Комбинация слияния отмечает точку, в которой сходятся две (или более) расходящиеся истории. Допустимо вызывать git merge [commit-id] вместо git cherry-pick [commit-id], чтобы явно создать фиксацию слияния, но это приводит не только к эффектам одиночной фиксации вишни, но и ко всему набору изменений в расходящейся истории этой ветви.

При всем том, что «двойное слияние» обычно не является проблемой в git. Если вы попытаетесь объединиться с историей, содержащей набор изменений, который уже присутствует, он просто станет no-op, когда истории склеиваются; git действительно заботится только о состоянии дерева в каждой фиксации, а не об изменениях, которые попали в это состояние.

Answer 3

Также примечательно, что флаг -x для cherry-pick добавляет SHA первоначальной фиксации в конец сообщения фиксации.

Я хотел бы добавить сокращенную SHA в конец сводки фиксации, чтобы упростить сопоставление собранного вишни с оригиналом при просмотре журнала. Также может указывать, кто сделал вишневый подборщик, с флагом подписания -s.

Пример:

> git cherry-pick -sex 27d4985

#333: fixes all the things (27d4985) 

- how it fixes all the things 

(cherry picked from commit 27d49855238364d0184ad344884a366b5b16e) 

Signed-off-by: Chuck Norris <chuck@example.com>