版本控制和 Git 策略？ [关闭]答案

【问题标题】：Version Control and Git Strategy? [closed]版本控制和 Git 策略？ [关闭]
【发布时间】：2012-10-05 04:33:24
【问题描述】：

我使用 git 来维护某种版本控制并在多台机器上同步我的工作，因为我确实倾向于在多台机器上工作。我是唯一一个处理我的代码的人。

我可以使用 git 完成大部分基础知识，例如git checkout a file 将单个文件返回到较早的状态，并使用 git revert （我害怕使用 git revert 因为我还没有完全理解其中的一些复杂性）将整个项目返回到较早的状态。我有时也会使用 git branch 将代码分叉到不同的方向，特别是在我不确定方向的情况下。

然而，我对 git 的了解有些薄弱，我仍然倾向于在进一步处理源文件时逐步重新保存源文件。例如当我完成代码时，我可能在 project18.c 上工作，在完成代码时已经经历了 1...18。这是除了在处理文件时经常进行 git 提交之外，因此有效地我有两种方法可以“回拨”我在项目上的工作。然而，这种增量文件编号不适用于分布在多个文件中的代码，因为跟踪跨多个文件实现的功能太疯狂了。我怀疑通过更加努力地创建封装的自包含函数，并从周围的函数中隐藏内部实现是解决我的一些问题的更优雅的解决方案。

人们经常建议为每个主要的新功能或代码段执行一次 git 提交，但是当我无法执行频繁的 git 提交时，我经常会花费大量时间手动“退出”一段有缺陷的代码，如果我放弃实现代码的特定方式。我怀疑提前更好地规划//设计代码有时可能会有所帮助，但通常很难完全预测最终会成为死胡同或有缺陷的代码。

我正在寻找一种实用的版本控制策略，它在事情进展不顺利时特别有用，并且有助于调试有问题的部分。

【问题讨论】：

标签： git version-control

【解决方案1】：

如果您认真对待自己的工作习惯（例如，如果您想为生活编写代码或为某些免费软件项目做出贡献），那么最好习惯于经常提交。提交中仍然应该有一些逻辑，为你编写的每十行代码有一个单独的提交是失礼的。小而合理的提交很高兴审查或bisect，如果您遇到回归。

如果您需要有多个检查点，您可以为您正在开发的功能的测试套件提交一次，并为测试套件的每个通过部分提交一次。或者类似的东西，取决于你的工作方式。（如果需要，使用 Git，您可以在发布更改时随时清理历史记录。）如果您发现这还不够，那就是您做错了。

【讨论】：

【解决方案2】：

您的问题的解决方案分为两个不同的部分：

了解提交

您需要更好地理解提交背后的想法以及最初的想法。理想情况下，提交必须与执行某些操作（如函数或重构某些部分）的代码处于同一级别。所以你需要经常提交，如果你不这样做，你只会丢失关于你的进度的信息，如果你做了这些提交，这些信息就会被记录下来。我建议阅读 http://git-scm.com/book 以更好地了解 git 的工作原理。

探索分支

如果您在同一个项目中处理不同的不相关功能，则执行彼此无关的连续提交可能会很烦人。分支出现了，这是一个强大的功能，可让您同时处理不同的想法，彼此独立（代码方面）。您可以在上一个链接中找到有关如何分支等的信息。而且，这里有一篇关于使用 git 分支的模型的文章，它对具有多种功能的大型软件特别有用http://nvie.com/posts/a-successful-git-branching-model/

【讨论】：