我一直在努力学习并习惯版本控制，更具体地说是git。但是，我的开发团队目前（并且在可预见的未来）完全由我组成，因此，我对git的关注一直在尝试掌握分支和提交技术。
我已经看过并尝试了一些工作流示例，例如git-flow。但是，我似乎无法真正掌握如何使用它们。例如，提交的频率和提交的内容有多少？什么时候我应该真正分支新功能？我经常发现自己正在编写一个新功能的情况下，突然意识到我需要修复以前的编码错误，或者说应该完成一个新功能，然后意识到我仍然会遗漏一些东西。
这导致一些混乱的分支和提交，这绝对没有帮助。我发现自己想知道有多少帮助版本控制。
我做错了什么？或者不是用于单人开发的git /版本控制系统？
答案 0 :(得分：8)
如果您刚开始使用版本控制，对于单人项目，那么最初不要担心所有这些工作流程等。首先，习惯于提交。
你刚刚运行你的程序并测试一些东西，它有用吗？很好，承诺。要做一些你不太确定会有用的事情吗？承诺。尽早并经常提交。关于git的好处是提交是可撤销的，如果你选择了一个不好的地方提交（提示：如果它不编译，它可能是一个不好的地方 - 但是有一些例外，一旦你对{{1}感到满意}和git rebase -i（虽然是一种高级工具，所以首先要习惯基础！（嵌套的括号很有趣！））。）。
现在，关于切换焦点 - git有很多有用的工具。
例如，如果你想修复一个bug，但已经有很多其他工作......
git add -igit stash save
然后在错误修复之上重新应用所有这些更改。
如果您正在处理一个小功能，但后来意识到这实际上有点复杂，您可能会不止一次...
git stash pop
你去了 - 你现在在一个新的分支上。您可以随时使用
返回另一个分支机构git checkout -b mynewbranch
您可以与git checkout someotherbranch
一起使用它来保存未提交的更改，然后交换到另一个分支以执行完全不同的操作。如果你想回来，git stash。
作为一个稍微高级的工具，如果你有一个小错误修复，并且不想打扰整个存储的东西，你可以做
git checkout mynewbranch这要归功于git索引 - git add -i
# select what changes to include
git commit # commits only what you selected
允许您选择从单个行级别确切地从工作副本复制到索引的内容，然后git add -i将其保存为提交。通过这样做，您可以非常快速，轻松地从一堆其他更改中删除小修复。但请注意，这意味着您刚刚提交了一些从未在该表单中编译或测试的内容;所以需要注意不要提交完全破坏的东西（你通常应该避免提交完全破坏的代码，因为它会中断git bisect - 一个非常方便的工具来跟踪回归）。
一旦习惯了这个基本流程，就可以开始向它添加一些流程了。例如，您可以将git commit分支仅用于1.x系列的错误修正。管他呢。使用适合您的工作流程。