我使用 git 来维护某种版本控制并在多台机器上同步我的工作,因为我确实倾向于在多台机器上工作。我是唯一一个处理我的代码的人。
我可以使用 git 完成大部分基础操作,例如 git checkout a file 将单个文件返回到早期状态,并使用 git revert (我害怕使用 git revert ,因为我还没有完全理解其中的一些复杂性)来返回整个项目到较早的状态。我有时也会使用 git branch 将代码分叉到不同的方向,特别是在我不确定方向的情况下。
然而,我对 git 的了解有些薄弱,当我进一步研究它时,我仍然倾向于继续逐步重新保存源文件。例如,当我完成代码时,我可能在 project18.c 上工作,在完成代码时已经经历了 1...18。这是在处理文件时频繁进行 git 提交的补充,因此有效地我有两种方法可以“回拨”我在项目上的工作。然而,这种增量文件编号不适用于分布在多个文件中的代码,因为跟踪跨多个文件实现的功能太疯狂了。我怀疑通过更加努力地创建封装的自包含函数,并从周围的函数中隐藏内部实现是解决我的一些问题的更优雅的解决方案。
人们经常建议为每个主要的新特性或代码段执行一次 git 提交,但是当我无法执行频繁的 git 提交时,我经常会花费大量时间手动“退出”一段有问题的代码,如果我我正在放弃实现代码的特定方式。我怀疑提前更好地规划//设计代码有时可能会有所帮助,但通常很难完全预测最终会成为死胡同或有缺陷的代码。
我正在寻找一种实用的版本控制策略,它在事情进展不顺利时特别有用,并且有助于调试问题部分。