问题描述
我经常发现我在 gitflow 功能分支上工作，并且我偶然发现了一些我后来意识到实际上需要对开发人员进行小更新的东西（例如，与该功能无关的配置更改，但在所有基于当前开发的分支）。但是我已经保存了代码，所以 git 可以看到未暂存的更改。我想我可以通过两种方式解决这个问题：
选项 2 感觉在某种程度上更容易，特别是如果在处理所有未暂存更改所需的初始提交集中涉及其他“仅功能”更改时。这也意味着我可以完成我在功能中所做的任何工作，然后再放手将其放回开发中。
但是，我是 git 的新手，尤其是 gitflow，所以不确定还有什么可能潜伏着等着我稍后咬我。上面的选项 2 是处理这种情况的好方法吗？是否还有其他更好的理由？
解决方法
我认为选项 2 更简洁。如果您的功能分支应该从最新的 dev 分支开始，您可能希望在最后进行 rebase。
Git stash 在技术上与真正的提交非常相似，因此这两个选项之间没有巨大的技术差异。您可以使用 gitk 来检查 stash 与正常提交相比的情况。唯一重要的区别是 stash 可以保存有关哪些更改在索引中以及哪些更改仅在工作目录中的信息。如果您觉得这些信息值得保留，最好使用 stash。
除此之外，选项 2 就足够了，它可以更好地扩展到更复杂的情况，所以如果你学会将它用于这个简单的情况，那么在更复杂的情况下使用相同的方法可能会更容易处理。
一个额外的选择是使用 rebase -i <the common ancestor for your current branch and the dev branch> 并将您想要的补丁作为分支中的第一个提交移动到 dev 中。您可以将 dev 分支快进到该提交。这也是一个非常好的方法，因为如果您有 5 个错误修复，这可以轻松地将所有这些错误修复移动到您的分支的开始，并使用一个 rebase。我主要是个人使用这种方法。
您可以像这样更新本地 dev 分支而无需结帐（假设它是真正的快进）：
git push . sha1-you-want:dev
这是有效的，因为您的 push 目标存储库可以是当前存储库 (.)，您只需将 sha1-you-want 作为新的 dev 分支推送。