我在同时使用多个分支的项目中使用git，即：
A ---- B ---- C
\ \
\ ---- D
---- E
根据具体情况使用每个命名项目（即我需要访问A，B和D ......）。当我修改代码时，我在更高的相关分支（我主要是A）中进行，然后我将每个分支重新绑定到新的“A”以传播差异。
因为我被告知这是一个坏习惯，因为它会产生推/拉的问题，现在我必须在我的项目中添加一个新的维护者，我想有另一种方法来做我想要的。< / p>
我被提议做条件编译，这是我在早期开发中的方式，但现在我有很多分支（目前约10个），代码变得非常难以阅读，这就是为什么我来到这个分支解决方案......
Cherry-picking看起来很棒，但是每次提交都会进行10次提交，而且我们失去了B是A的孩子的“视觉”表示......
还有其他想法，建议吗？ 谢谢！
答案 0 :(得分：3)
只需使用'git merge'而不是'git rebase'。
假设图表中的分支A中出现了错误。它是显示错误的最上游分支，因此这就是您修复的内容。你检查出来，编码修复，测试修复，并确认它在A上工作。然后，当你想在其他地方传播它时，你：
如果问题首先出现在B中，您将结帐B，编写修复程序，测试修复程序，然后执行第3步和第4步。
Search for "merge upwards" on this page for more information.
这确实会导致许多合并操作，如果您修复A，10个后代分支的父分支，则在您的示例中为10，但它也是您可以使用的最佳工作流程，不会a）驱动您的协作者坚果因为重新提交继续被推到遥控器，并且b）不会完全破坏你将分支合并到一起的能力。
b）顺便说一下，为什么你不想要'git cherry-pick'。 Cherry-pick会将您的更改集从A传播到其他10个分支，当然，它会在它使用的每个不同分支中更改该提交的SHA1哈希值。例如，如果您稍后将B合并到A中，那么您最终会得到冗余历史记录：更改集的功能相同，但具有完全不同的SHA1哈希值。这有时并不是什么大不了的事，但if you codify it into your workflow, it will fail you in miserable ways.冗余合并历史也破坏了'git bisect'和'git rebase'，几乎不可能阅读。对于这种分支模型，请避免使用'git cherry-pick'。