这可能是
一种常见的情况，但是SO上的Git工作流问题太多了，以至于我找不到确切问题的答案。这是：
我在 Git 中有一个并行存在的master和future分支。 future包含一些未来的功能，而master是当前版本(大约(。
在开发未来的功能时，我经常遇到需要进行修复的情况，而修复需要掌握。我现在做什么：
future正在进行储藏工作- 切换到
master - 修复
master中的代码 - 切换到
future - 从
master合并 - 藏匿流行音乐
在某些情况下，在future分支中更好地测试修复时，该过程变得更加繁琐，包括更改future，在那里提交，切换到主节点，从未来挑选，检查未来，重置未来并最终从主节点合并。
一定有更好的方法，但我想不通。行不通的方法(我相信;如果我错了，请纠正我(：
- 从
future合并到master。我不希望将来在主人中提交所有提交。 - 将所有内容提交到
future，然后挑选某些提交到master。仅此还不够，因为将来从master合并到future会导致重复提交(甚至可能冲突？也许我可以future那些精心挑选的提交来创建相反的提交master但这感觉很混乱。
人们如何处理这个工作流程？
如果你独自在future分支上进行开发，你可以在master之上重新定位它，而不是将 master 合并到它上面。
从 git 1.8.4(2013 年 7 月(开始，git rebase 已经学会了"自动存储"：看到这个答案。
git checkout future
git rebase --autostash master
对于相反的情况，樱桃采摘仍然是主要选择。
我
- 未来藏匿工作正在进行
中- 切换到主服务器
- 修复主控中的代码
- 切换到未来
- 从主节点合并
- 藏匿流行音乐
一定有更好的方法，但我想不通。
曾经做过这个过程，但是在我发现我需要经常来回切换后，我改为简单地拥有 2 个工作目录 - 一个用于"主"分支，一个用于"未来"分支(在我的情况下为"开发"(。两个目录都使用相同的远程存储库/源，两个工作目录也相互作为远程。 两个目录消除了在切换分支之前/之后存储保存/弹出的需要。
我也不觉得有必要立即将修复程序从主服务器拉到将来(第 5 步(，除非我也有原因。 通常，我会先完成当前功能以供将来使用，然后将从主节点合并延迟到方便为止。
您可以为修复创建一个新分支。
- 在主控中合并它 如果当时不
- 方便，请将其合并到您的分支中时刻直接掌握。
- 其他开发人员可以将其合并到自己的分支中。