git 流程中这两种方法之间是否存在显着差异
Are there significant differences between these 2 methods in git flow
我经常发现我正在处理一个 gitflow 功能分支，我偶然发现了一些东西，后来我意识到实际上需要对开发人员进行一个小的更新（例如，与功能，但基于当前开发的所有分支都需要）。但是我已经保存了代码，所以 git 看到了未暂存的更改。我想我可以通过两种方式解决这个问题：
git stash，切换回开发，git pop，提交，切换回功能，变基- 提交功能，切换到开发，挑选，切换回功能
选项 2 在某种程度上感觉更容易，特别是如果在处理所有未暂存的更改所需的初始提交集中涉及其他 'feature-only' 更改。这也意味着我可以完成我在功能方面的工作，然后再把它放回开发中。
但是，我是 git 的新手，尤其是 gitflow，所以不确定还有什么可能潜伏在等着我。上面的选项 2 是处理这种情况的合适方法吗？出于任何原因还有其他更好的方法吗？
我认为选项 2 更简洁。如果你的功能分支应该从最新的开发分支开始，你可能想在最后做 rebase。
Git 存储在技术上与真正的提交非常相似，因此这两个选项之间没有太大的技术差异。您可以使用 gitk 来检查与正常提交相比，存储看起来如何。唯一重要的区别是 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 分支推送即可。
我经常发现我正在处理一个 gitflow 功能分支，我偶然发现了一些东西，后来我意识到实际上需要对开发人员进行一个小的更新（例如，与功能，但基于当前开发的所有分支都需要）。但是我已经保存了代码，所以 git 看到了未暂存的更改。我想我可以通过两种方式解决这个问题：
git stash，切换回开发，git pop，提交，切换回功能，变基- 提交功能，切换到开发，挑选，切换回功能
选项 2 在某种程度上感觉更容易，特别是如果在处理所有未暂存的更改所需的初始提交集中涉及其他 'feature-only' 更改。这也意味着我可以完成我在功能方面的工作，然后再把它放回开发中。
但是，我是 git 的新手，尤其是 gitflow，所以不确定还有什么可能潜伏在等着我。上面的选项 2 是处理这种情况的合适方法吗？出于任何原因还有其他更好的方法吗？
我认为选项 2 更简洁。如果你的功能分支应该从最新的开发分支开始，你可能想在最后做 rebase。
Git 存储在技术上与真正的提交非常相似，因此这两个选项之间没有太大的技术差异。您可以使用 gitk 来检查与正常提交相比，存储看起来如何。唯一重要的区别是 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 分支推送即可。