您在团队中使用哪些指南或标准进行版本控制？

Question

我开始在公司内进行少量开发。我打算使用Git进行版本控制，我很想知道人们在他们的小组中使用哪些指南或标准版本，类似于编码标准通常是在小组内写的。

我假设会有类似的东西;

• 经常提交（至少每天/每周/每次会议等）
• 发布版本始终来自主分支
• 在发布之前，将为测试创建一个新分支，并将其标记为。从这一点开始只修复错误。最终版本将被标记为这样，并将错误修复合并回主干
• 每位开发者都有一个公共回购
• 新功能应该有自己的分支

显然，这很大程度上取决于你使用的VCS以及你如何构建它。

类似问题;
git branch naming best practices
Is there a standard naming convention for git tags?

Answer 1

只有一个标准：

1. 检查重大更改将导致踢腿。

Answer 2

在我工作的当前位置，版本控制系统是最先进和最成熟的系统之一。这就是我们的工作方式。

我们有一个称为“主”分支的东西，它是将在生产中的代码库。注意，代码库在一个巨大的庞大结构中。假如一个新项目到来，我们将不得不对其进行范围界定并预订发布周。现在我们必须开始研究它。因此，我们从main切割了一个分支，称为特征分支。团队或开发人员小组继续在该特定功能分支中工作。请注意，主分支将同时进行大量功能分支切换。

现在，一旦开发习惯将代码合并回main。我们不会直接这样做，因为它可能会因明显的关键性问题而造成严重破坏。因此，我们还有一个主要的分支切割，称为预发布。我们将所有代码合并到该版本库中。并在完整的代码库上构建。构建应该通过。当它这样做时，我们提取绿色时间戳（最后传递的构建）。获得绿色时间戳后，代码将从预发布分支合并到main，并且最终确定发布。

一旦代码投入生产并说如果我们遇到一些错误，我们就从一个名为bug-fix分支的main中删除一个分支。做所有的改变。并将它合并回主要;始终遵循预发布/绿色时间戳过程。它不可避免。

重新碱。好的，所以最初我说当我们的功能分支必须完成时我们会预订。在这段时间内，主要会发生很多代码更新。因此，您必须不断更新当前功能分支以与主同步。为此，完成了称为rebase的过程。它就像从main获取最新的代码，这样你就不会在一个过时的分支中工作。在我目前的组织中，虽然政策建议1周，但每2-3周会触发一次反叛。

更有趣的功能：假设我正在开发一个所谓的功能分支，我想从其他一个也在自己的功能分支中工作的团队中获取一些代码（这种情况虽然看起来很常见但经常发生）。为此我们将更改我们的config-spec（ClearCase是我们的版本控制系统），指向其他项目所需的那些文件。可以使用LATEST，也可以指定TIMESTAMP来提取来自其他功能分支的文件。

在项目上线后经过一段时间后，我们切断的功能分支几乎不需要。它可以从系统中终止，例如在空间成为约束之后的一年时间内。

Answer 3

我的'cvs'是TFS所以请把它当作它的价值。

如果有人打破了构建，则应用甜甜圈规则（第二天带上甜甜圈盒）

你提到经常提交，基于日，周或会议。 这个系统不会引入不完整的代码吗？ 代码审查后提交可能会更稳定。

设置单元测试是一个很好的做法，因为它就像让第二个QA团队在夜间工作（当这些单元测试作为隔夜构建的一部分运行时）。

至于每个功能都有一个分支，它不是我使用的东西，而是当有人打破构建时我们谈到的东西，因为如果一个团队破坏了一个功能，其余的东西仍然建立。为此，您的安装程序必须足够灵活，即使缺少可选功能，也可以构建并能够部署。

按照这样的功能构建可以提高工作效率，因为QA可以在第二天开始测试，而不是被破坏的构建阻塞，直到它在下午晚些时候被修复，或者甚至推回到下一天只看到另一个类似的问题发生。 / p>

CVS众所周知，但如果我要开始一个开发团队/项目，我可能会考虑看看Jira Studio

http://www.youtube.com/watch?v=2w2uN3c8pfA http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=related

Answer 4

拥有主分支后，您要使用的任何任务或功能都应在其自己的分支中开发。尽量保持主分支稳定并且生产准备就绪。每当你有一个任务，分叉一个分支，在那里做你的工作，修复任何错误，然后与主人合并。

无需每天办理登机手续（或任何其他时间单位）。我们总是根据功能完成进行签到，不一定是完整的功能集，而是在小的逻辑可管理块中。这使我们能够比每天检查所有代码更容易发现错误，无论它是否相关。

保持您的提交信息清晰明确，这将在您重新访问代码时为您提供极大的帮助。

git的一个小问题，当你分叉一个分支时，它是从你当前所在的分支而不是主分支分叉的。这是显而易见的事情，但在分支新分支之前，请务必仔细检查当前分支。

使用.gitignore文件保存您不想跟踪版本控制的文件，而不是混乱您的git状态消息或覆盖不应该在版本控制中的文件（DB配置等）

Answer 5

仅检入（或根据您的工具提升）工作代码到“main”分支/流/仓库/存储库（选择您自己的“main”定义）。这个“主要”分支应始终保持可编辑和可测试性。