在我的日常工作中，我发现自己用 Git 做了一个新的代码提交习惯：而不是创建dev/master/main分支的分支，在那里进行更改，当我完成时，然后通过解决冲突合并回引用分支，我根本不分支。相反，我在引用分支上本地进行更改，当我必须推送更改时，为了使其他人所做的更改保持最新，我存储我的更改，我拉取新的提交，然后我将我隐藏的更改应用到这些其他人的新提交之上并解决冲突(如果有(。然后我终于推动了改变。我发现这种做法比处理分支更容易和更简单。
这种提交更改的方式是否错误、可接受，甚至比传统分支更好？为什么？
您规定的git stash工作流程没有任何问题(完全可以接受(，因为请记住，它是您的本地存储库。你可以做任何你想做的事情，只要你推动到世界其他地方的任何东西保持一致。例如，不要重写那些被推送以惹恼其他人的提交的历史。
这里要认识到的重要一点是，分支和存储并不相互排斥。如果存储满足您当前的需求，请继续使用它，直到更复杂的方案出现，您需要同时考虑分支和存储。
要记住的几件事：
- 在 git 中分支是一种低或没有仪式的操作。在我的团队中，这是我们日常工作流程的一部分。
- 分支允许团队成员共享尚未准备好推送到
master(或任何上游主分支(的正在进行的代码。从本质上讲，这使我们能够在团队成员之间组建子团队。 - 分支允许我们向 github 提交拉取请求，同时为其他项目做出贡献，或请求代码审查。
- 我总是通过使用
git stash pop和git stash drop来保持我的存储列表较小以避免将来出现混淆。 - 仍然会有与存储的合并冲突。
通常，这在某种程度上等于将你的功能分支重新定位到你正在关注的功能分支上，因此，例如，你跟随一个 featureX 的上游主节点，然后你做：
git fetch --all
git checkout featureX
git rebase master
这将根据新拉取的代码应用更改。
如果您周围已经有藏匿处，则可以将它们转换为功能分支，如下所示：
git branch featureX [<stash>]
我发现处理功能分支比处理存储更习惯，对我来说，这很容易被遗忘，你不能在最终的远程开发存储库中推动它们。