开发一个功能发现其他功能有bug怎么办？
What do you do when you find a bug in other function when develop a function?
比如有几个大函数：User[需要开发UserControl、UserModel、UserService]，以及Admin、Post、Comment。
现在你在features/post分支，开发post相关功能。但是您在 User 相关函数中遇到了一些错误。
那么就 gitflow 而言，建议的方法是什么？
在User相关函数中添加TODO或Fix me，并在完成post开发并合并代码到master后修复bug？
stash未完成的post相关代码，创建fix分支，修复bug，合并到features/post，stash pop未完成的post ]相关代码，那接着说？
我没有特别遵循 git-flow，但这是我尝试做的事情：
- 隐藏，或使用
git-worktree。
- 修复相关上游分支的bug
- 将修复合并到工作分支中（通常我稍后会重新设置它）。
或者，您可以先将其作为离散提交修复在当前分支中，然后 git cherry-pick 将其放入上游分支并 git rebase 将其从当前分支中删除。
您可以自由修改任何您喜欢的内容，无论它是否与您正在处理的 "topic" 相关。
然后使用 git commit --patch 只添加提交那些符合主题的更改。 （非常值得学习此工作流程的所有细节，包括如何将大块拆分成更小的更改，以及如何编辑不能拆分但包含所需更改和不需要更改的混合的大块）。
当主题提交全部使用一个或多个 git commit --patch 操作进行时，那么工作副本中剩下的就是偏离主题的更改。那时你可以 git checkout 到不同的分支来提交那些，如果合适的话，使用 git stash save 和 git stash pop 来解决任何关于你有未暂存的更改的投诉。
如果所有内容都在同一个分支中，那么顺序可能并不重要。您可以 git commit --patch 您发现的错误修复，然后继续讨论该主题。如果修复落在正在进行的主题修复的中间，您总是可以 git rebase -i：交互式地对其进行变基，以便主题提交在一起，并且偶然的错误修复在之前或之后。
在我的软件组织中，我必须为这个偶然的错误修复创建一个票证并获得一个错误编号，然后将其提交到 Gerrit 进行审查。如果这是显而易见的事情，看起来可以快速轻松地获得批准，我会先这样做，然后再进行 "weighty" 更改。
我没有发现 GitFlow 对此有定义。
对于我来说，基于BUG的严重性，我会决定立即修复它或者稍后添加TODO来修复它。
我没有在与当前开发功能相同的分支中修复它，因为这会让我的队友在查看我的源代码时感到困惑。
这是一个基于意见的问题 - git-flow 不要求您以特定方式解决此问题。
我通常会回到 develop 分支，创建一个新的功能分支，修复那里的错误，然后一旦合并到 develop 中，我就会将我最初正在开发的功能 rebase 到 develop 上，这样我现在修复错误。
如果 bug 很紧急并且 develop 与 master 不同，我会使用一个 hotfix 分支，一旦 hotfix 合并到 master 和 develop 中，我会再次将我的分支 rebase 到 develop。
比如有几个大函数：User[需要开发UserControl、UserModel、UserService]，以及Admin、Post、Comment。
现在你在features/post分支，开发post相关功能。但是您在 User 相关函数中遇到了一些错误。
那么就 gitflow 而言，建议的方法是什么？
在User相关函数中添加
TODO或Fix me，并在完成post开发并合并代码到master后修复bug？stash未完成的post相关代码，创建
fix分支，修复bug，合并到features/post，stash pop未完成的post ]相关代码，那接着说？
我没有特别遵循 git-flow，但这是我尝试做的事情：
- 隐藏，或使用
git-worktree。 - 修复相关上游分支的bug
- 将修复合并到工作分支中（通常我稍后会重新设置它）。
或者，您可以先将其作为离散提交修复在当前分支中，然后 git cherry-pick 将其放入上游分支并 git rebase 将其从当前分支中删除。
您可以自由修改任何您喜欢的内容，无论它是否与您正在处理的 "topic" 相关。
然后使用 git commit --patch 只添加提交那些符合主题的更改。 （非常值得学习此工作流程的所有细节，包括如何将大块拆分成更小的更改，以及如何编辑不能拆分但包含所需更改和不需要更改的混合的大块）。
当主题提交全部使用一个或多个 git commit --patch 操作进行时，那么工作副本中剩下的就是偏离主题的更改。那时你可以 git checkout 到不同的分支来提交那些，如果合适的话，使用 git stash save 和 git stash pop 来解决任何关于你有未暂存的更改的投诉。
如果所有内容都在同一个分支中，那么顺序可能并不重要。您可以 git commit --patch 您发现的错误修复，然后继续讨论该主题。如果修复落在正在进行的主题修复的中间，您总是可以 git rebase -i：交互式地对其进行变基，以便主题提交在一起，并且偶然的错误修复在之前或之后。
在我的软件组织中，我必须为这个偶然的错误修复创建一个票证并获得一个错误编号，然后将其提交到 Gerrit 进行审查。如果这是显而易见的事情，看起来可以快速轻松地获得批准，我会先这样做，然后再进行 "weighty" 更改。
我没有发现 GitFlow 对此有定义。
对于我来说，基于BUG的严重性，我会决定立即修复它或者稍后添加TODO来修复它。
我没有在与当前开发功能相同的分支中修复它，因为这会让我的队友在查看我的源代码时感到困惑。
这是一个基于意见的问题 - git-flow 不要求您以特定方式解决此问题。
我通常会回到 develop 分支，创建一个新的功能分支，修复那里的错误，然后一旦合并到 develop 中，我就会将我最初正在开发的功能 rebase 到 develop 上，这样我现在修复错误。
如果 bug 很紧急并且 develop 与 master 不同，我会使用一个 hotfix 分支，一旦 hotfix 合并到 master 和 develop 中，我会再次将我的分支 rebase 到 develop。