什么是最好的方式来“分叉”一个项目，与维护人员保持联系，更改和开发您自己的功能，同时仍然能够很容易地贡献回任何功能一旦被接受？
这是我所做的，但遇到了一个问题。
我克隆了一个存储库，在Feature1分支中做了一些工作，然后合并了从原点到Feature1，再到原点的更改…
然后我开发了Feature2，当然，它也包含Feature1代码。
下面的艺术描述了这个场景（希望如此）。
我有所有上游的变化，在我的主人和发展之上。但是，我不能贡献回feature2，因为它还包含feature1代码。我能做什么？如何获得针对“AAA”的Feature2补丁？
重新设置Feature2和Cherry Pick以排除Feature1提交？没什么解决办法。
然后呢？所有补丁都必须手动应用！
Feature1 Feature2
a---b---c---d---e---f---g-----h---i f2---f3---f4
/ \ \ \ /
--------x'---y'---z'----1---o'---p'---2---3---q'-----r'---t'---l'---aaa'
/ / / / / / / / / /
origin----x----y----z--------o----p-------------q------r----t----l---aaa
最佳答案
如果要保留图表中描述的合并工作流。
git rebase --onto q Feature2
git checkout aaa
git merge Feature2
如果我正确地理解了图表，这将把您的本地存储库转换为如下内容：
Feature1
a---b---c---d---e---f---g------h---i
/ \ \ \
------x'---y'---z'--1----o'---p'---2---3----aaa'
/ / / / / /
origin----x----y----z--------o----p-------------q----r----t----l---aaa
\ \ \ \
\----r'---t'---l'---4---aaa''
\ /
f2---f3---f4-----
Feature2
如果Feature2不依赖于Feature1中所做的任何更改，则这就是您需要做的全部工作。如果Feature2确实依赖于Feature1的某些更改，那么您也必须将这些更改选择到Feature2分支上。
替代解决方案
另一种方法是忘记所有合并，并将feature2直接重设为适当的上游提交（aaa）。如果你愿意的话，你也可以用Feature1做同样的事情。
git rebase --onto aaa Feature1
git rebase --onto aaa Feature2
这将使您的本地存储库看起来像这样：
a---b---(...)---aaa' Feature1
/
origin---x---(...)---t---l---aaa
\
f2---f3---f4---aaa'' Feature2
同样，这只在feature2在逻辑上不依赖feature1时才有效。如果是这样的话，你仍然需要从Feature1到Feature2挑选那些东西。