我一直在努力学习和习惯版本控制，更具体地说是git。然而，我的开发团队目前(以及在可预见的未来)只由我一个人组成，因此，我对git的关注一直是试图掌握分支和提交技术。
我已经看到并尝试了一些工作流示例，例如gift -flow。然而，我似乎不能真正掌握如何使用它们。例如，提交的频率和内容类型?什么时候我应该为一个新功能进行分支?我发现自己经常遇到这样的情况:我正在编写一个新功能，突然意识到我需要修复之前的编码错误，或者本应完成一个新功能，但后来意识到我仍然遗漏了一些东西。
这会导致一些令人困惑的分支和提交，这绝对没有帮助。我发现自己在想版本控制到底有多大帮助。
我做错了什么?或者git/版本控制系统不适合单人开发吗?
如果您刚开始使用版本控制，对于一个单人项目，那么最初不要担心所有这些工作流等。首先，要习惯提交。
你是否刚刚运行了你的程序并测试了一些东西，并且它工作了?太好了,提交。准备做一些你不确定是否有效的事情吗?提交。尽早并经常承诺。git的好处是，如果你选择了一个错误的地方提交，那么提交是可撤销的(提示:如果它没有编译，那么它可能是一个错误的地方——但也有例外，一旦你习惯了git rebase -i和git add -i(尽管这是一种高级工具，所以首先要习惯基本的!)(嵌套括号很有趣!))).
现在，关于切换焦点——git有很多有用的工具。
例如，如果你想修复一个bug，但已经有一堆其他工作…
git stash save
Git然后获取所有未提交的更改，保存它们，并恢复到上次提交。你可以修复错误，测试，提交，然后
git stash pop
所有这些更改然后重新应用于错误修复之上。
如果你正在做一个小功能，但后来意识到这实际上有点复杂，你可能会提交不止一次…
git checkout -b mynewbranch
好了，你现在在一个新的分支上。您可以随时使用
返回到另一个分支git checkout someotherbranch
您可以将此与git stash一起使用以保存未提交的更改，然后交换到另一个分支来做完全不同的事情。当你想要回来的时候，git checkout mynewbranch。
作为一个稍微高级一点的工具，如果你有一个小的错误要修复，并且不想为整个隐藏的事情而烦恼，你可以使用
git add -i
# select what changes to include
git commit # commits only what you selected
这要感谢git索引——git add -i允许你选择，精确到单个行级别，从工作副本复制到索引的内容，然后git commit将其保存为提交。通过这样做，您可以非常快速和轻松地从一堆其他更改中梳理出小的修复。但是，请注意，这意味着您刚刚提交了从未以这种形式编译或测试过的东西;因此，需要小心不要提交完全损坏的代码(通常应该避免提交完全损坏的代码，因为它会破坏git bisect——一个非常方便的跟踪回归的工具)。
一旦您习惯了这个基本流程，您就可以开始向其中添加一些流程。例如，您可以将v1.x分支保留为1。x系列。之类的。使用适合您的工作流程