如何在 git 中的多个分支之间划分变化？答案

【问题标题】：How does one divide changes among multiple branches in git?如何在 git 中的多个分支之间划分变化？
【发布时间】：2013-07-10 11:42:15
【问题描述】：

在 git 的多个分支之间划分一组更改的“最佳”（阅读：“最简单”、“首选”、“适当”）方法是什么？例如，假设我在分支 X 上进行了一组（未提交的）更改，但确实需要将一些更改提交到分支 Y，其他更改到分支 Z，还有一些更改到分支 W；通常我会本能地做（如推荐的here）是隐藏更改，签出Y，应用更改，仅提交与Y相关的内容，然后重复其他分支。我遇到的问题是，应用隐藏的更改通常会导致必须处理的合并冲突，如果我执行隐藏弹出而不是应用（这经常发生，对我来说是一个真正的风险！），我最终在 Y 分支中混合了针对 Z 的更改，并且必须手动解开它们。

有没有更好的方法？我该如何更好地处理这种情况？

请注意，我的问题与this one 之类的问题有关，但不同之处在于我寻求在多个分支之间划分当前更改集的最佳方法。另请注意，在开发一组更改之前，我无法切换到 Y、Z 或 W；我必须从 X 开始并在 X 上开发一系列更改。

【问题讨论】：

"另外请注意，在开发更改集之前我不能切换到 Y、Z 或 W；我必须从 X 开始并在 X 上开发更改集" i>：听起来这些变化都是相关的。如果是这样，当它们依赖于提交到另一个分支的更改时，你打算如何将它们提交到不同的分支？
@DanielHilgarth，这些更改是相关的，但我想在不同的分支中提交它们的原因是让使用分支 Y、Z 和 W 的其他人也可以使用这些改进；一些更改在逻辑上属于分支 Y、Z 和 W，想要这些改进的人可以从这些分支中合并它们。
那么你为什么不能直接在各自的分支上开发这些变化呢？只是想在这里了解您的情况...
@DanielHilgarth，由于我的回购协议的性质，我必须同时开发这些更改与 X 中的更改。可以这样想：X 是功能分支，Y 是测试功能的分支，测试 X 需要更新 Y 中的测试软件，但其他人应该也可以使用对 Y 的改进。
分支与共同根源和分歧如何相关？顺便说一句：我仍然不明白为什么你不能先在 Y 中编写改进，将它们合并到 X 中，然后开发新功能。

标签： git branch git-branch git-stash

【解决方案1】：

git stash 和多个分支的问题在于，一旦它被弹出，你必须再次为下一个分支存储。要解决这个问题，只需使用一个临时分支就很容易了。

git checkout -b temp_branch
git commit -a -m 'Changes that will go to several branches.'
git checkout W
git cherry-pick -n temp_branch
(fixup all files here here)
git commit -a -m 'Changes for W.'
git checkout X
git cherry-pick -n temp_branch
(fixup all files here here)
git commit -a -m 'Changes for X.'
git checkout Y
git cherry-pick -n temp_branch
(fixup all files here here)
git commit -a -m 'Changes for Y.'
git checkout Z
git cherry-pick -n temp_branch
(fixup all files here here)
git commit -a -m 'Changes for Z.'
git branch -D temp_branch

【讨论】：

这让我觉得相当于存储，然后在每个分支上应用（但不弹出）存储并有选择地提交更改。我错过了什么吗？
这些步骤不能帮助您解决合并冲突。这是我认为无法避免的事情，因为您不希望 git 在这种情况下尝试为您做某事。

【解决方案2】：

避免合并问题的一种方法是在原始分支中进行多次提交，然后从目标分支中挑选它们，最后回滚更改。

像这样：

git add -i
git commit -m 'changes for X'
git add -i
git commit -m 'changes for Y'
git log -n 2 # to see hashes
git checkout X
git cherry-pick <hash of the first commit>
git checkout Y
git cherry-pick <hash of the second commit>
git checkout original_branch
git reset --hard HEAD~2

【讨论】：