30

StackOverflow 上有另一个线程，处理提交更改到源代码控制的频率。我想把它放在使用像 git 或 mercurial 这样的 DVCS 的上下文中。

  1. 你多久提交一次？

  2. 您是否仅在正确构建时提交更改？

  3. 你多久推送一次更改（或提交拉取请求或类似请求）？

  4. 你如何开发一个复杂的功能/进行需要很多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库还是在推送之前将所有更改捆绑到单个变更集中？

4

5 回答 5

14

这取决于您正在处理的分支（“开发线”）的性质。

这些 DVCS（git 或 mercurial）的主要优点是您可以轻松：

  • 分支
  • 合并

所以：

1/ 你多久提交一次？
2/ 你是否只在正确构建时提交更改？

在私有分支上尽可能多的时间（例如，如果它编译）。
仅在单元测试通过时才提交的做法是一个很好的做法，但应仅适用于“官方”（如“可以发布或“推送””）分支：在您的私人分支中，如果您合并了一个 gazillon 时间需要。
唯一的事情是：在你的主开发分支上重放它们之前，做一些合并 --interactive 来重新组织你在私有分支上的许多提交，在那里你可以通过一些测试。

3/ 您多久推送一次更改（或提交拉取请求或类似请求）？

发布是另一回事，应该使用“清晰”的历史记录（连贯的合并，表示编译并通过一些测试的内容）。
您发布的分支应该是历史永远不会重写、始终更新的分支。
出版物的速度取决于偏远分支的性质和拉动该分支的人口的性质。例如，如果是为另一个团队，你可以经常推动。如果是针对一个系统范围的集成测试团队，你推送的频率会少很多。

4/ 你如何开发一个复杂的特性/进行需要很多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库还是在推送之前将所有更改捆绑到单个变更集中？

请参阅 1. 和 2.：首先在您自己的私有分支中进行补丁，然后在官方（已发布）补丁分支上重新组织您的提交。如果补丁涉及多个不同的“活动”（或错误修复），则一次提交并不总是最佳选择。

于 2009-09-26T08:16:43.337 回答
5

我会非常、非常频繁地对我的 DVCS（我自己的主题或任务分支）进行更改，这样我不仅可以将其用于“交付更改”，而且还可以在我工作时帮助我：比如“为什么这有效 5几分钟前，它不再工作了？” 如果你经常提交，你可以运行一个差异。

此外，我发现一个非常非常好的技术是使用它来“自文档重构”。让我解释一下：如果您必须对主题分支进行大重构，然后将更改作为一个整体进行审查（修改了一组不错的文件），您可能会迷失方向。但是，假设您检查每个“中间步骤”并用评论记录它，那么您正在创建某种您自己的更改的“电影”，以帮助描述您所做的事情！对审稿人来说是巨大的。

于 2010-03-19T23:54:17.130 回答
4

我承诺很多；添加功能甚至重新格式化我的资源时。

我使用 git 并在非共享分支上完成我的大部分工作。当我添加了足够多的小更改以计为一个块时，我会使用git rebase将较小的相关更改收集到更大的块中并将其提交到主分支。

这样，我就拥有了提交代码的所有优点，我可以向后或向前输入，但我不必犯下所有的错误，也不必回溯到主要历史。

于 2009-09-26T10:22:21.630 回答
1

你多久提交一次？

非常频繁。如果我所做的更改有效并构成了一个不错的补丁，则可能在一小时内多次。或者可能每隔几个小时，这取决于我是花更长时间调试东西，还是尝试有风险的更改。

您是否仅在正确构建时提交更改？

是的，几乎总是。我想不出有理由签入未正确构建的代码。但是，您可能有很多原因可以签入无法正确运行的代码（在分支中）。

你多久推送一次更改（或提交拉取请求或类似请求）？

通常仅当功能完成并准备好进行集成测试时。这意味着它已经通过了单元测试和其他相关测试，并且代码/补丁足够干净，我认为它已准备好进行审查。

你如何开发一个复杂的功能/进行需要很多地方的复杂重构？无法构建的“私人提交”是否可以？完成后，您是将它们也推送到主存储库还是在推送之前将所有更改捆绑到单个变更集中？

我将为该功能创建一个命名分支（该分支将具有跨设计文档和问题跟踪系统的可追溯性）。作为中间步骤，不构建的提交只会在私有分支上真正可行，但仍然是例外的。目前，我没有将整个功能分支重新设置为基础并将其合并到一个单一的变更集中，尽管这是我将来考虑做的事情。只有在适当的测试全部通过时才会推送更改。

于 2009-09-26T08:48:04.760 回答
0

我遵循这种流程
替代文本 http://img121.imageshack.us/img121/3272/versioncontrolsysbestpr.png

（这里是原图网址）

我想这说明了一切。基本上我会在实现完整的工作用例/用户故事（取决于您的软件过程）后进行签入。最重要的事情是你签入在它们编译的意义上工作的东西。永远不要破坏构建！
在每个用户故事/用例之后进行提交的好处是您可以更好地跟踪过去的版本并且撤消更改更容易。

于 2009-09-26T10:27:23.000 回答