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

Question

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

我假设会有这样的事情；

• 经常 promise (至少每天/每周/ session 等)
• 发布版本总是从 master 分支生成
• 在发布之前，将创建一个新分支用于测试并标记为测试。从这一点开始只修复错误。此版本的最终版本将被标记为这样，错误修复将 merge 回主干
• 每个开发者都有一个公共(public)仓库
• 新特性应该有自己的分支

显然，这在很大程度上取决于您使用的 VCS 以及您构建它的方式。

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

Answer 1

在我目前工作的地方，版本控制系统是最先进、最成熟的系统之一。我们就是这样做的。

我们有一个称为“主”分支的东西，它是将投入生产的代码库。请注意，代码库位于一个巨大的庞大结构中。比如说，如果有一个新项目来了，我们将不得不为它做一个范围界定，并预定一个发布周。现在我们必须开始研究它。因此，我们从 main 中切出一个分支，称为功能分支。团队或开发人员组继续在该特定功能分支中工作。请注意，主分支会同时进行许多功能分支切割。

现在，一旦开发结束，通常会将代码 merge 回 main。我们不会直接这样做，因为它可能会由于明显的关键性问题而造成严重破坏。所以我们从 main 中又多了一个分支，叫做 pre-release。我们将所有代码 merge 到该发布基础。并在完整的代码库上进行构建。构建应该通过。当它这样做时，我们提取一个绿色时间戳(最后通过的构建)。一旦获得绿色时间戳，代码将从预发布分支 merge 到主分支并完成发布。

一旦代码投入生产，如果我们遇到一些错误，我们就会从主分支中切出一个分支，称为错误修复分支。做所有的改变。并将其 merge 回 main；始终遵循预发布/绿色时间戳过程。这是不可避免的。

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

更多有趣的功能:假设我目前正在一个所谓的功能分支上工作，我想从其他也在自己的功能分支上工作的团队之一获取一些代码(这种情况虽然看起来不常见，但经常发生)。为此，我们将更改配置规范(ClearCase 是我们的版本控制系统)，以指向其他项目所需的那些文件。可以使用 LATEST 或指定 TIMESTAMP 来提取来自其他功能分支的文件。

在项目上线一段时间后，我们剪切的功能分支几乎不需要了。它可以从系统中终止，比如在几年后如果空间受到限制。