Отслеживание слияний для сбора Git cherry? - PullRequest
Новая
       4

Отслеживание слияний для сбора Git cherry?

27 голосов
/ 21 сентября 2010

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

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

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

Ответы [ 3 ]

14 голосов
/ 23 мая 2012

Также примечательно, что флаг -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>
11 голосов
/ 21 сентября 2010

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

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

Учитывая все сказанное, "двойное слияние" обычно не является проблемой в git. Если вы попытаетесь объединиться с историей, которая содержит набор изменений, который уже присутствует, он просто станет недоступным, когда истории будут склеены; git действительно заботится только о состоянии дерева в каждом коммите, а не об изменениях, которые привели его в это состояние.

5 голосов
/ 11 сентября 2013

На самом деле есть команда с именем git cherry , которая печатает каждый коммит, который не объединен между двумя ветвями.

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

Вывод далеко не красивый.

Для тех, кто пришел из SVN и привык к svnmerge.py , я создал эквивалентный bash-скрипт для sit svnmerge poss -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 vend -l».

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

...