这可能是一个常见的场景，但是在这里有很多Git工作流程问题，我无法找到我的确切问题的答案。这是：
我在Git中有一个master和future分支并行生效。 future包含一些未来功能，而master是当前版本（大约）。
在开发未来功能时，我经常会遇到需要进行修复的情况。我现在做什么：
future master master future master 在某些情况下，如果在future分支中更好地测试修复，则该过程变得更加麻烦，包括在future中进行更改，将其提交到那里，切换到master，cherry - 从未来挑选，检查未来，重新定位未来，最后从大师合并。
必须有更好的方法，但我无法弄清楚。无法实现的方法（我相信;如果我错了，请纠正我）：
future合并到master。我不希望所有未来的提交都在掌握。future，然后挑选某些提交到master。单独使用 是不够的，因为从master到future的未来合并会导致重复提交（甚至可能会发生冲突？）。也许我可以在future中为那些挑选到master的人提出相反的提交，但这感觉很麻烦。人们如何处理这个工作流程？
答案 0 :(得分：2)
如果您在future分支上独自开发，则可以在master之上对其进行修改，而不是将其合并到其中。
自从git 1。8。4（2013年7月）以来，git rebase已经学会了自动转播＆＃34;：请参阅this answer。
git checkout future
git rebase --autostash master
对于相反的情况，樱桃挑选仍然是主要选择。
答案 1 :(得分：1)
- 将来正在进行的收藏工作
- 切换到主人
- 修复主代码
- 切换到未来
- 从主人合并
- Stash pop
必须有更好的方法，但我无法弄清楚。
我曾经做过这个过程，但是在我发现需要经常来回切换之后，我改为简单地拥有2个工作目录 - 一个用于工作目录＆＃34; master＆＃34;分支和一个用于＆＃34; future＆＃34;分支（＆＃34;开发＆＃34;在我的情况下）。两个目标都使用相同的远程回购/原点，两个工作的目录也相互作为遥控器。两个dirs消除了在切换分支之前/之后存储保存/弹出的需要。
除非我有理由，否则我也没有立即感觉需要立即将修复从主人转移到未来（步骤5）。通常情况下，我会在未来首先完成当前功能并延迟从主人合并到方便。
答案 2 :(得分：0)
您只需为修复程序创建一个新分支即可。