单独开发人员的最佳版本控制习惯？

我是自己的唯一开发人员，并且我了解VCS的好处；我发现很难坚持良好做法。目前，我正在使用git开发主要是Web应用程序（由于我的工作，该应用程序永远不会开源）。

我当前的工作流程是对开发站点进行大量更改，测试，修改，测试，满意并提交更改，然后将提交推送到实时站点（因此，如果我正在进行新的大更改；我可能只每周提交一次；但是我的IDE对于未提交的内容具有良好的撤消历史记录）。

基本上，我仅在机器之间切换时才使用git（例如，从工作开发计算机到家用开发计算机或在运行中的计算机），但是在白天，我并没有真正看到它的好处。这导致我的更改清单很长（而且我很难为每次提交找到合适的msg；而且每当我匆忙时-我往往会留下一些糟糕的消息，例如“对管理员和模板的其他更改”）。

我应该多久提交一次？每个单行更改都应该提交吗？我应该在任何测试之前提交（例如，至少针对语法/编译错误，然后必须完全撤消它；因为该想法行不通或消息是谎言）？

我应该确定每天早晨/下午都下班之前，还是在仍然新鲜的时候停止吃晚饭吗？不良的VCS习惯让我错过了什么？

你很想念。

我也是一个人 每次做出重大更改时，或者在开始重大更改之前，我都会做出承诺，这样，如果我把事情搞砸了，就可以回去，即使我没有做任何大的事情，也时不时地回去。确实不是每天都在，但是很亲密。有时一天几次。

我得到的是我可以随时返回。有很多 此外，安排分支机构也有帮助。

我想这给了我很多命令。

我正在使用svn，现在已经厌倦了。但是不能花更多的时间学习其他东西。

祝好运。

你应该经常犯错。在达到某些逻辑里程碑之后，您当然应该做出承诺。如果那花费了一天以上的时间，那么您至少应该在工作日结束时投入工作，或者更好的是，将您的工作分解成更小的部分。

这样做有很多原因。例如，如果您的计算机崩溃了怎么办？只损失一天的工作要比一周或一个月的工作好得多。另一个原因是频繁的提交使得隔离错误更加容易。您可以进行二进制搜索并找出导致该错误的微小更改。

另一件事：提交之前，您应该做一个比较并查看所做的所有更改。这使您可以检查所有更改是否有意义，并且您没有忘记任何内容。这也有助于您提出更好的提交消息。而且，当然，这是经常执行的另一个原因：经历一天的变化比一个月的变化要容易得多。

为了充分利用CVS，您应该一次处理一个功能/错误修复，并在该功能/错误修复完成后提交。通过这样做，您将获得：

• 提交消息将更易于创建并且更有意义；
• 更容易地将将来的错误追溯到引入它们的更改；
• 更容易地恢复到先前的状态（即使那意味着失去失败的功能，但保留之后发生的错误修复）。

另外，由于要在PC之间切换，因此至少应有两个分支：

• 始终有效的“准备就绪”分支（当然，除了开发分支中正在处理的错误外）
• 一个开发分支，可能会时不时处于无法运行的状态（例如在下班回家时）。

每个单行更改都应该提交吗？

如果那是修复错误的原因，那么可以肯定。

不良的VCS习惯让我错过了什么？

我和一个有“不良VCS习惯”的人一起工作。他喜欢自己一个人工作，他所负责的产品线每年带来约一百万美元的收入。他只会在老板agged他时做出承诺。然后有一天他的硬盘崩溃了。在为他准备好替代品后，我们发现他的最后一次入住是6个月前。由于VCS是源代码安全的，因此您可以猜测还有什么问题–上次提交已损坏。我们必须回溯一年多才能获得他产品系列的未损坏版本。即使他本应被解雇，他也没有被解雇。

另一个轶事涉及我自己。我曾经将爱好和研究项目的代码存储在可移动硬盘上。有一天，我的公寓被打破了。笔记本电脑（已损坏）和所有可移动硬盘驱动器均被盗。每张DVD（红色黎明除外）均被盗。没有台式计算机被盗。如果我拥有异地源代码控制，我将不会失去15年的项目价值，尤其是由于某些项目是基于学术项目的，因为许多教授离开了学术界而去了私营企业，所以这些项目消失了，成为了公司IP黑洞，丢失的代码无法恢复。

我应该多久提交一次？

我将其分为几个指标：

• 如果计算机死机，您愿意损失多少工作？或被盗？

• 如果这可以修复Bug_1234，则请在注释中输入代码“修复Bug_1234”。

• 如果这是合乎逻辑的交付/里程碑，则使用“ Bug_1234，form_xyz”（或适当的Task_1234）之类的注释进行检入。

• 在回家之前，请始终在星期五晚上检入代码。还可以在休假前对所有物品进行登机（或撤消签出）。

• 公司政策规定的任何时候。

不要认为行数发生变化。大量考虑功能。VCS允许您在每个功能块的中央位置给出标题，以便您可以轻松地通过“ git log”查看“此处发生了什么”。

而且，像Eclipse这样的IDE允许您指向给定的行并转到将其变为您所看到的形状的提交。换句话说，您可以直接从源代码行转到提交。如果提交很小并且有一个好的信息，那么它比“修复大量的错误”要有用得多。

我想说的是，通过将更改分组在一起，您错过的最大事情就是能够跟踪引入错误的时间和位置。

根据我的经验，在引入bug的两到三周后，有几次发现该bug，而事后很长时间，很难筛选一周的提交值。在这些情况下，简单地对提交进行二进制搜索以找出导致问题的单个更改是有帮助的。这些错误大部分是C ++代码上的内存使用错误，因此对于您的项目，它可能不会经常发生。

在团队中发展时，其他好处也会发挥作用-简单的提交注释，更容易的合并，将提交与错误修复相关联等。

我猜您的工作流程是，如果您确实开始每天或每半天提交一次，则需要使用标签或书签来跟踪实时站点上正在使用的代码版本。我想这是最重要的事情。

我也是一个独立开发人员，我使用SVN，而且我喜欢它。我什至编写了一个工具，将数据库的结构以及其中的测试数据转换为xml，以便可以将其包含在源代码管理中。

我通常会在完成自治工作单元时作出承诺。有时，如果我在这里和那里执行了一堆琐碎且无关的单行修复，然后将它们一起提交，但是如果在两个不相关的大型自主工作单元之间发生了单行修复，那么它将得到自己的提交，那没有什么错。

另外，我总是提交编译的代码，并且几乎总是提交通过所有基本测试的代码。如果没有，请确保在提交消息中包括“不工作”。发生这种情况的唯一情况是，我做了一些重要的更改，即使它们还没有完成，我也不想丢失，最重要的是，我将开始一次伟大的重构冒险，我不确定是否它将成功。因此，然后，我将存储库用作到目前为止已完成工作的备份，然后才有可能将其弄乱并不得不扔掉。

这意味着我总是在需要提交我的源代码时提交。有早上提交规则或晚上提交规则绝对没有任何意义。代码所处的状态决定了是否该提交。

您放入存储库中的消息无关紧要。如果您绝对无法提出有意义的建议，那么与空白消息一起提交总比在必要时完全不提交要好。

如果您由于提出的所有内容听起来很愚蠢而无法想到一个好的提交消息，请记住这没关系；提交消息应该是显而易见的，因此当您编写它们时，它们一定听起来很愚蠢。但是请相信我，如果您需要在一个月后检查旧版本，那么即使是愚蠢的消息也要感谢没有消息的情况，您将不胜感激。

每次进行“逻辑”更改时都要提交。例如，如果要实施一项新功能，则需要逐步进行。这些步骤中的每一个通常相互依赖。因此，您可以单独提交这些步骤，并在提交消息中解释为什么需要每个步骤。

提交消息非常重要。您必须避免告诉自己在做什么，告诉自己为什么在做。该代码已经记录了这些更改，但是在6个月内，您将很高兴看到您为什么进行更改。

如果偶然有人跳入而您不再孤单，这也很有用。即使只是对您而言，干净的历史记录也可以使您更轻松地使用a git blame来知道何时以及为什么更改了带有错误的代码行。

进行较小的提交而不是进行大量更改，也可以测试中间状态。如果必须紧急发布某些内容，则可以隐藏更改。如果您是在以前工作的时候引入了错误，则可以存储并检查是由于未提交的更改导致了错误，还是在较早的提交中。

您还可以释放它的强大功能，git bissect从而告诉您该讨厌的错误。如果提交的长度为2,000行，它仍然会有所帮助，但效果却不是那么好...

另一件事是，这是持续集成（CI）然后进行连续部署（CD）的第一步。CI和测试可以在新的提交时触发，因此，每当您推送更改是否破坏某些内容时，它就会告诉您。这样，您就可以知道是否可以安全部署，并在出现问题时立即通知您，而不是在急忙发布之前将其通知。

关于您的其他问题：

• 不要提交您甚至没有编译过的东西，除非您愿意（使用git rebase --interactive）重写它的历史记录。
• 如果一行更改具有单独的用途（修复错误或与您当前未提交的更改无关），则应提交一次提交。使用git add --patch阶段性的。
• 无需强迫自己在晚餐前做出承诺，除非您有重要的东西无法承受而失去。在这种情况下，您可能需要将一个单独的分支提交到正在进行的工作中。
• 提交并推送到远程存储库是一个备份。如果您每周仅提交和推送一次，则在最坏的情况下，您可能会失去一周的工作。

我应该多久提交一次？

作为一个单独的开发人员，我通常会在进行基本测试后，以及当我在深夜离开项目时，只要我做出了重大改变，便做出承诺。

每个单行更改都应该提交吗？

不可以，除非单行更改会显着更改功能或错误。

我应该在任何测试之前提交（例如，至少针对语法/编译错误，然后必须完全撤消它；因为该想法行不通或消息是谎言）？

可能不会。至少对我来说，我在“工作副本”上进行了大部分测试和编码，并在对更改感到满意后提交。在许多IDE中，它将向我显示在实际进行提交之前发生了什么变化，并使我有机会在提交中附加注释

我应该确定每天早晨/下午都下班之前，还是在仍然新鲜的时候停止吃晚饭吗？不良的VCS习惯让我错过了什么？

我对VCS或它引起的不良习惯不是很熟悉。我想我在回答第一个问题时基本同意了我的观点。

在回答假定的一般问题时，您似乎主要是将提交用作分支，这在另一响应者的帖子中已解决。我不确定所使用的IDE是否具有良好的撤消历史记录等，但是除了重新启动IDE并在计算机之间移动之外，我还没有找到一个我认为还不错的IDE。

我是一个惯常的提交者，我发现它很适合我，但是请记住，我的提交消息几乎总是像，

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

因此，我不能确切地说对我的分支（Mercurial）进行如此频繁和惯常的提交正是鼓励了最详细的提交日志。有时，如果我的妻子要我出去吃饭，我什至会中途提交代码，此时我只是匆忙复制并使用前面的“正在处理”提交消息。

我的提交日志模式通常是这样的， "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

另一方面，它挽救了我的屁股。有时，我确实遇到了我没有预料到和无法测试的极端情况，这时频繁的提交可以帮助我弄清楚我在哪里引入了错误。

因此，我不了解最佳习惯，就理想的提交日志记录习惯而言，我当然不是一个人，但是我可以肯定地说，更频繁地提交绝对可以在需要执行回归操作时提供帮助。

每个单行更改都应该提交吗？

我之前进行过单行更改，但是通常比较棘手，也许我的时间很短。我的承诺并不总是类似于完美或完整的工作或变更单元。如上所述，有时候这只是我妻子要求我出门吃晚饭的结果。

TBH我遵循该"Working on [...]"日志模式所做的许多承诺都没有对变化的统一单位进行建模（为什么我常常无法提出比更好的信息"Working on [...]"），而仅仅是我喘口气的结果，例如让自己喝杯咖啡。该"Completed [...]"消息指示该工作单元的结束，并且"Started working on [...]"在我刚开始从事某些工作时，我通常会在其中写上更详细的消息以及第一类消息。如果您平均每15分钟提交一次，则那些“正在处理”消息更像是中间人，代表某人可能在一次更大的提交中提交了更详细的消息。

我应该在任何测试之前提交（例如，至少针对语法/编译错误，然后必须完全撤消它；因为该想法行不通或消息是谎言）？

我只是继续提交它，甚至在有时甚至运行测试之前再次提交（同样，如果发生意外事件）。同样，即使我是独奏，我也会推送到执行CI的服务器（仅在局域网上在家中运行的一台服务器）。这似乎有些过分，但不知道，我已经习惯在以前的工作场所中依靠它了。另外，我不必每次都必须手动运行所有单元测试和集成测试。我喜欢将所有这些都与推送相关。如果测试失败，那么以前进的方式进行回归就很容易了，我可以进行回归分析，更正最新版本中的错误，然后继续进行。就是说，我至少在提交之前针对调试版本构建了代码。

我应该确定每天早晨/下午都下班之前，还是在仍然新鲜的时候停止吃晚饭吗？

我喜欢在出门之前先提交，然后在编程之间休息一下。在遇到这个问题之前，我并没有真正思考为什么要这么做。我想这是为了防止自己在没有提交日志的情况下接管我离开的地方，而不是在我可以进行差异等操作的地方离开。嗯，我需要就此向您回复，因为从理论上讲，考虑到我的承诺频率，这可能不是必需的。无论出于何种原因，在离开计算机之前，我仍会更愿意提交和推动。其中一些可能是以前的心理恐惧，例如，我离开后，电脑开始着火，在我们使用SVN的日子里，项目经理回到过去，有时开发人员要花数周的时间，而不会冒犯我们的脖子，并不断提醒我们尽可能频繁地检入代码，同时提醒我们我们的代码是公司的财产。另外，这样做特别有效率，特别是在推动时，这样我的CI流程就可以在我不在的时候开始运行所有测试，以便可以返回并查看结果。

哦，有时候离开后我会有点醉，在醉酒时尝试编写复杂的代码通常是一个坏主意（尽管并非总是如此；有一次我在醉酒的时候有一个尤里卡的时刻，想出了一个非常不错的上下文菜单系统，但我只喝了6杯啤酒，编写起来并不复杂。如果我尝试这样做，至少我提交了清醒的代码，然后才离开，而不是将醉汉的代码与清醒的代码混合，这时我的提交日志可能看起来像这样，"Reverting back to code written before Jagermeister shots."我不这样做除非我得到醉酒的代码启发，否则我会经常这样做，但是在极少数情况下，确实可以帮助我在出门喝醉之前做出一些贡献。