Pau*_*yuk 8 git version-control standards
我开始在公司内进行少量开发.我打算使用Git进行版本控制,我很想知道人们在他们的小组中使用的版本是什么准则或标准,类似于编码标准通常是在小组内写的.
我假设会有类似的东西;
显然,很多这将取决于您使用的VCS以及您如何构建它.
在我目前工作的地方，版本控制系统是最先进、最成熟的系统之一。这是我们如何做到。
我们有一个称为“主”分支的东西，它将是生产中的代码库。请注意，代码库位于一个巨大的庞大结构中。假设如果有一个新项目到来，我们将必须对其进行范围界定并预订发布周。现在我们必须开始努力。因此，我们从 main 中切出一个分支，称为功能分支。团队或开发人员组继续在该特定功能分支中工作。请注意，将从主分支同时切出许多功能分支。
现在，一旦开发结束，通常会将代码合并回主程序。我们不会直接这样做，因为这可能会因明显的关键性问题而造成严重破坏。因此，我们从主分支中又切出了一个分支，称为预发布。我们将所有代码合并到该版本库中。并在完整的代码库上进行构建。构建应该会通过。当它这样做时，我们提取一个绿色时间戳（最后通过的构建）。一旦获得绿色时间戳，代码将从预发布分支合并到主分支，并最终确定发布。
一旦代码投入生产，如果我们遇到一些错误，我们就会从 main 中删除一个分支，称为错误修复分支。做所有的改变。并将其合并回 main；始终遵循预发布/绿色时间戳流程。这是不可避免的。
重新基地。好的，所以最初我说我们会在我们的功能分支必须完成时进行预订。在此期间，main 上将会发生大量代码更新。因此，您非常有必要不断更新当前的功能分支以与主分支保持同步。为此，完成了称为变基的过程。这就像从 main 获取最新的代码，这样您就不会在过时的分支中工作。在我当前的组织中，虽然政策建议 1 周，但每 2-3 周就会触发一次变基。
更有趣的功能：假设我目前正在一个所谓的功能分支上工作，我想从也在自己的功能分支中工作的其他团队之一获取一些代码（这种情况虽然看起来不常见，但经常发生）。为此，我们将更改我们的配置规范（ClearCase 是我们的版本控制系统），以指向其他项目所需的那些文件。可以使用 LATEST 或指定 TIMESTAMP 来提取来自其他功能分支的文件。
项目上线一段时间后，我们削减的功能分支几乎不再需要了。如果空间受到限制，一年后，它可以从系统中终止。