我有以下存储库布局:
主分支(生产)集成工作
我想实现的是从工作分支中挑选一系列提交,并将其合并到集成分支中。我对git很陌生,我无法弄清楚如何在不破坏存储库的情况下准确地做到这一点(在一次操作中挑选提交范围,而不是合并)。对此有什么建议或想法吗?谢谢
我有以下存储库布局:
主分支(生产)集成工作
我想实现的是从工作分支中挑选一系列提交,并将其合并到集成分支中。我对git很陌生,我无法弄清楚如何在不破坏存储库的情况下准确地做到这一点(在一次操作中挑选提交范围,而不是合并)。对此有什么建议或想法吗?谢谢
当前回答
如果你只有两次提交,并且想挑选,你可以
git cherry-pick <commit> -n
然后将它们转换为新的提交。
-n不会自动创建提交,而只是阶段性地进行更改,因此您可以继续对提交中的文件进行cherry pick或更改。
其他回答
假设您有2个分支,
“branchA”:包括要复制的提交(从“commitA”到“commitB”
“branchB”:要从“branchA”转移提交的分支
1)
git checkout <branchA>
2) 获取“commitA”和“commitB”的ID
3)
git checkout <branchB>
4)
git cherry-pick <commitA>^..<commitB>
5) 如果您有冲突,请解决并键入
git cherry-pick --continue
继续樱桃采摘过程。
以上所有选项都将提示您解决合并冲突。如果您正在合并为团队提交的更改,那么很难从开发人员那里解决合并冲突并继续。然而,“gitmerge”将一次性完成合并,但不能将一系列修改作为参数传递。我们必须使用“gitdiff”和“gitapply”命令来执行revs的合并范围。我观察到,如果补丁文件对太多文件有差异,“git-apply”将失败,因此我们必须为每个文件创建一个补丁,然后应用。请注意,脚本将无法删除在源分支中删除的文件。这是一种罕见的情况,您可以从目标分支手动删除此类文件。如果无法应用修补程序,“git-apply”的退出状态不为零,但是如果使用-3way选项,它将返回到3路合并,您不必担心此失败。
以下是脚本。
enter code here
#!/bin/bash
# This script will merge the diff between two git revisions to checked out branch
# Make sure to cd to git source area and checkout the target branch
# Make sure that checked out branch is clean run "git reset --hard HEAD"
START=$1
END=$2
echo Start version: $START
echo End version: $END
mkdir -p ~/temp
echo > /tmp/status
#get files
git --no-pager diff --name-only ${START}..${END} > ~/temp/files
echo > ~/temp/error.log
# merge every file
for file in `cat ~/temp/files`
do
git --no-pager diff --binary ${START}..${END} $file > ~/temp/git-diff
if [ $? -ne 0 ]
then
# Diff usually fail if the file got deleted
echo Skipping the merge: git diff command failed for $file >> ~/temp/error.log
echo Skipping the merge: git diff command failed for $file
echo "STATUS: FAILED $file" >> /tmp/status
echo "STATUS: FAILED $file"
# skip the merge for this file and continue the merge for others
rm -f ~/temp/git-diff
continue
fi
git apply --ignore-space-change --ignore-whitespace --3way --allow-binary-replacement ~/temp/git-diff
if [ $? -ne 0 ]
then
# apply failed, but it will fall back to 3-way merge, you can ignore this failure
echo "git apply command filed for $file"
fi
echo
STATUS=`git status -s $file`
if [ ! "$STATUS" ]
then
# status is null if the merged diffs are already present in the target file
echo "STATUS:NOT_MERGED $file"
echo "STATUS: NOT_MERGED $file$" >> /tmp/status
else
# 3 way merge is successful
echo STATUS: $STATUS
echo "STATUS: $STATUS" >> /tmp/status
fi
done
echo GIT merge failed for below listed files
cat ~/temp/error.log
echo "Git merge status per file is available in /tmp/status"
是否确实不想合并分支?如果工作分支有一些您不需要的最近提交,您可以在您需要的位置创建一个带有HEAD的新分支。
现在,如果出于任何原因,你真的想要挑选一系列提交,那么一个很好的方法就是只需提取一个补丁集并将其应用于新的集成分支:
git format-patch A..B
git checkout integration
git am *.patch
这基本上就是git rebase所做的,但不需要玩游戏。如果需要合并,可以向git-am添加--3way。如果您逐字遵循说明,请确保执行此操作的目录中没有其他*.patch文件。。。
git cherry pick start_commit_sha_id ^。。结束委托sha_id
例如git cherry pick 3a7322ac。。7d7c123c型
假设您在branchA上,希望从branchB选择提交(给定范围的开始和结束提交SHA,左侧提交SHA较旧)。整个提交范围(包括两个)将在branchA中进行精心挑选。
官方文件中给出的示例非常有用。
先摘樱桃。。LAST仅适用于简单场景。
为了实现一个体面的“将其合并到集成分支中”,同时对自动跳过已集成的拾取、移植钻石合并、交互控制等事情感到舒适……)最好使用重基。这里的一个答案指出了这一点,然而协议包括一个危险的git分支-f和一个临时分支。这里有一个简单的稳健方法:
git rebase -i FIRST LAST~0 --onto integration
git rebase @ integration
-i允许交互控制。如果LAST是分支名称,~0可确保分离的重基(不移动/另一个分支)。否则可以省略。第二个rebase命令只是以安全的方式将集成分支ref向前移动到中间分离的头部-它不会引入新的提交。要使用合并菱形等对复杂结构进行重基化,请考虑第一个重基中的--rebase merges或--rebase convers=rebase cousins。