我一直在研究一个分支new_feature
:
A -- B -- C -- D master
\ \
\ 1 -- 2 -- 3 new_feature
\
E -- F -- G port
我们的代码库还有一个较旧的分支 port
,另一个开发人员将我们的产品移植到另一个 RDBMS。 port
尚未准备好 merge 回 master
。
最近有必要让 new_feature
在 port
中工作。所以我将这两个 merge 到一个新的分支 port/new_feature
中,并在那里做了一些提交(I,J)以使其工作:
A -- B -- C -- D master
\ \
\ 1 -- 2 -- 3 -- I* -- J* -- K new_feature
\ \
E -- F -- G -- H -- I -- J -- K* port/new_feature
port
我挑选 I 和 J 回到 new_feature
(如 I*、J*),因为它们涉及重要的重构,而我也希望在 new_feature
中包含这些重构。我也一直在对 new_feature
进行新的提交 (K),需要将其提交给 port/new_feature
(K*)。
展望 future ,保持 new_feature
和 port/new_feature
同步的最佳计划是什么(但仅限于新更改)?我应该保持从一个到另一个的 cherry-picking 提交(反之亦然)吗?或者有没有一种方便的方法通过 merge 来做到这一点?
最佳答案
cherry-pick 是危险的,因为:
重复提交(下一次 merge 会很复杂,因为 Git 会尝试在...
I-J-K
之上重新应用I-J-K
)。
如果您将一个分支 rebase 到另一个分支之上(请参阅“Git cherry pick and datamodel integrity”),情况就不会如此,但在您的情况下这是不可能的。功能依赖性(参见“How to merge a specific commit in git”),但我怀疑这不是您的问题:
I
和J
不是依赖于H
,并且可以安全地应用于3
。
如果您不打算将端口和新功能 merge 在一起,那么 cherry-pick 很方便。
如果是这样,请继续 cherry-pick 。
关于Git 保持独立的分支同步,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13482433/