我使用git来维护某种版本控制并在多台机器上同步我的工作，因为我倾向于在多台机器上工作。我是唯一一个处理我的代码的人。
我可以用git做大部分基础知识，例如git checkout一个文件将一个单独的文件返回到一个早期的状态，并使用git revert（我害怕使用git revert，因为我仍然没有完全理解它的某些错综复杂）将整个项目返回到一个早期的状态。我有时也会使用git branch将代码分叉到不同的方向，特别是如果我不确定方向的话。
然而，我对git的了解有些微不足道，我仍然倾向于继续逐步重新保存源文件。例如我完成时可能正在使用project18.c，在完成代码时经历了1 ... 18。这是在处理文件时经常进行git提交的补充，因此我有两种方法“回拨”我在项目上的工作。然而，这种增量文件编号不适用于跨多个文件的代码，因为跟踪跨多个文件实现的功能太疯狂了。我怀疑通过更加努力地创建封装的自包含函数，并从周围函数隐藏内部实现是我的一些问题的更优雅的解决方案。
人们经常建议为每个主要新功能或代码片段执行git提交，但是当我无法执行频繁的git提交时，我会经常花费大量时间手动“退出”一段错误的代码如果我放弃实现代码的特定方式。我怀疑更好的计划//提前设计代码有时会有所帮助，但通常很难完全预测到最终会成为死胡同或错误的代码。
我正在寻找一种实用的版本控制策略，特别是当事情进展不顺利时，这有助于调试问题部分。
答案 0 :(得分：4)
如果你认真对待自己的工作习惯（比如你想为生活编写代码或为某些自由软件项目做贡献），最好习惯经常提交。提交应该仍然有一些逻辑，对于你编写的每十行代码都有一个单独的提交是一种失礼。小＆amp;如果您遇到回归，逻辑提交很容易审核或bisect。
如果您需要有许多检查点，则可以为您正在使用的功能提供一个测试套件提交，并为测试套件的每个传递部分提交一个提交。或者类似的东西，取决于你的工作方式。 （使用Git，如果需要，您可以在发布更改时随时清理历史记录。）如果您发现这还不够，那么您做错了。
答案 1 :(得分：2)
您的问题的解决方案有两个不同的部分：
了解提交
您需要更好地理解提交背后的想法以及最初的想法。理想情况下，提交必须与执行某些操作的代码（如某个部分的函数或重构）处于同一级别。因此，您需要经常提交，如果您不这样做，您将丢失有关您在执行这些提交时记录的进度的信息。 我建议您阅读http://git-scm.com/book以更好地了解git的工作原理。
探索分支
如果您正在处理同一项目中不同的不相关功能，那么进行与其他项无关的连续提交可能会很烦人。这里有分支，这是一个强大的功能，可以让你在同一时间独立地处理不同的想法（代码方面）。 您可以在上一个链接中找到有关如何分支的信息。但是，这里有一篇关于使用git分支的模型的文章，这对于具有多个功能的大型软件特别有用http://nvie.com/posts/a-successful-git-branching-model/