您应该rebase --interactive
在生产之上创建一个设计分支,其中:
- 您可以重新排序提交,从生产中需要的提交开始
- 然后,您可以将生产合并到您想要合并的设计的最后提交(快进)
-x--x--x1--x--x2(设计)
\
p--p(生产)
x1 和 x2 需要包含在生产中:
git checkout design
git rebase --interactive production
-x
\
p--p (production)
\
x1'-x2'--x'--x' (design)
然后:
git checkout production
git merge x2'
-x
\
p--p--x1'--x2' (production)
\
x'--x' (design)
这允许您:
- 根据生产提交验证当前的设计提交(在变基期间)
- 重新排序设计提交
- 包括生产中的第一个
- 允许从设计到生产的后续合并是一个快进的合并。
Lakshman Prasad补充道:
大多数时候,我会在一天结束时推送更改。所以并没有那么大的帮助。对于推送的主分支,您的答案将如何变化
我也会这样做,但是使用仅为操作创建的私有分支:
git checkout master
git checkout -b master-private
-x--x--x1--x--x2 (master, master-private)
\
p--p(生产)
,然后是变基,这次是私有分支(即你永远不会推送的分支)。
git rebase --interactive production
-x--x--x1--x--x2 (master)
\
p--p (production)
\
x1'-x2'--x'--x' (master-private)
然后:
git checkout production
git merge x2'
-x--x--x1--x--x2 (master)
\
p--p--x1'--x2' (production)
\
x'--x' (master-private)
master
不会从提交重新排序中受益(使用更合乎逻辑的顺序),但至少您可以随时推送master
。
并且production
仍然可以准确包含它需要的内容。
如果后续提交master
有相同的问题(有些需要包含在 中production
,其他将稍后包含),我会:
- 删除
master-private
(我们并不真正关心那些 x',来自 master 的 x 提交的副本)
- 在 master 上创建一个
master-private
分支
- 使用粗略的冲突解决策略重新执行
rebase --interactive
(除了该master-private
分支的第一次提交,因为那些需要集成到production
分支中)
-x--x--x1--x--x2--x--x3--x (主)
\
p--p--x1'--x2'--x3'(生产)
| \
| x''--x'' (主-私有)
\
x'..x'(来自第一个主-私有的旧 x')