我有以下存储库布局:
主分支(生产)集成工作
我想实现的是从工作分支中挑选一系列提交,并将其合并到集成分支中。我对git很陌生,我无法弄清楚如何在不破坏存储库的情况下准确地做到这一点(在一次操作中挑选提交范围,而不是合并)。对此有什么建议或想法吗?谢谢
我有以下存储库布局:
主分支(生产)集成工作
我想实现的是从工作分支中挑选一系列提交,并将其合并到集成分支中。我对git很陌生,我无法弄清楚如何在不破坏存储库的情况下准确地做到这一点(在一次操作中挑选提交范围,而不是合并)。对此有什么建议或想法吗?谢谢
当前回答
假设您有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
继续樱桃采摘过程。
其他回答
另一种选择可能是将我们的策略合并到范围之前的提交,然后与该范围的最后一次提交(或当它是最后一次时的分支)进行“正常”合并。因此,假设只有2345和3456个主提交要合并到功能分支中:
master: 1234 2345 3456 4567
在功能分支中:
git merge -s ours 4567 git merge 2345
我将VonC的代码打包成一个简短的bash脚本gitmulticherry-pick,以便于运行:
#!/bin/bash
if [ -z $1 ]; then
echo "Equivalent to running git-cherry-pick on each of the commits in the range specified.";
echo "";
echo "Usage: $0 start^..end";
echo "";
exit 1;
fi
git rev-list --reverse --topo-order $1 | while read rev
do
git cherry-pick $rev || break
done
我目前正在使用这个方法来重建一个项目的历史,该项目在同一个svn主干中混合了第三方代码和定制。我现在正在将核心第三方代码、第三方模块和定制拆分到各自的git分支上,以便更好地理解未来的定制。gitcherry-pick在这种情况下很有用,因为我在同一个存储库中有两棵树,但没有共享的祖先。
从git v1.7.2起,cherry-pick可以接受一系列提交:
git cherry-pick学会了选择一系列提交(例如cherry-pick a..B和cherry--pick-stdin),git revert也学会了选择;然而,这些并不支持rebase[-i]所具有的更好的测序控制。
正如Gabe Moothart所指出的,cherry pick A..B不会得到commit A(你需要A~1..B),如果有任何冲突,git不会像rebase那样自动继续(至少在1.7.3.1)。
先摘樱桃。。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。
假设您有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
继续樱桃采摘过程。