谈Git分公司管理策略

如果你认真对待编程，你肯定会使用版本控制系统。

Git是目前最流行的版本管理系统。

Git比类似的软件有很多优势。值得注意的一点是，分支和合并版本非常方便。在一些传统的版本管理软件中，分支操作实际上会生成一个现有代码的物理副本，而Git只生成一个指向当前版本的指针(也称为“快照”)，因此非常快速且易于使用。

然而，过于方便也会引起副作用。如果你不注意，你可能会留下一个到处都是开放的版本库。到处都是分支，根本看不到骨干的发展。

文森特德里森提出了分支机构管理的策略，我认为值得借鉴。可以保持版本库的演进简洁，主干清晰，各分支各司其职，井井有条。理论上，这些策略适用于所有版本管理系统，Git只是作为一个例子。如果您不熟悉Git，请跳过示例部分。

一、主分支机构主

首先，代码库应该只有一个主分支。所有提供给用户的官方版本都在这个主要分支上发布。

默认情况下，Git主分支的名称称为Master。它是自动创建的。版本库初始化后，默认在主分支开发。

第二，发展科发展

主分支只用于分发主要版本，日常开发应该在另一个分支上完成。我们称发展部门为发展。

该分支可用于生成代码的最新隔夜版本。如果要正式发布，请合并主分支上的“开发”分支。

Git创建开发分支的命令：

Git签出-b开发主命令将开发分支发布到主分支：

#切换到Master分支git检出master# merge Develop分支git merge-no-ff develop在这里，稍微解释一下前面命令的-no-ff参数是什么意思。默认情况下，Git执行“远近合并”，直接将主分支指向开发分支。

当使用-no-ff参数时，会执行正常合并，在主分支上生成一个新节点。为了保证版本演进的清晰性，我们希望采用这种方式。关于合并的更多解释，请参考本杰明桑德夫斯基的《Understanding the Git Workflow》。

三、临时分支机构

我提到了版本库的两个主要分支：Master和developer。前者用于官方发布，后者用于日常开发。实际上，永久分行只需要这两项，不需要其他任何东西。

然而，除了永久分支之外，还有一些临时分支，用于处理某些特定目的的版本开发。临时分支有三种主要类型：

*功能分支

*预发行分支

*修复bug(fixbug)分支

这三个分支是暂时需要，使用后应该删除，这样代码库的永久分支永远只有Master和developer。

第四，职能部门

接下来，逐一看看这三个‘临时分支’。

第一个是功能分支，它是从开发分支中分出来的，目的是开发一个特定的功能。开发完成后，应重新纳入开发。

功能分支的名称可以以功能-*的形式命名。

创建职能部门：

git checkout -b feature-x develop开发完成后，将功能分支合并到develop分支中：

Git签出开发git合并-no-ff功能-x删除功能分支：

Git分支-d特性-x v .预发布分支

第二个是预发布分支，这意味着在正式版本发布之前(也就是合并到Master分支之前)，我们可能需要有一个预发布版本进行测试。

预发布分支从开发分支分支而来。预发布后，必须将其合并到开发分支和主分支。可以用release-*的形式命名。

创建预发布分支：

git check out-b release-1.2 develop在确认没有问题后被合并到主分支中：

Git签出主git merge-no-ff release-1.2 #为合并生成的新节点制作一个tag git tag -a 1.2并将其合并到develop分支中：

Git签出开发git merge-no-ff release-1.2最后，删除预发布分支：

Git分支-d版本-1.2 VI。错误修复分支

最后一个是修复bug分支。软件正式发布后，难免会出现bug。此时，有必要创建一个分支来修复该错误。

错误修复分支是从主分支分支而来的。打完补丁后，合并到主分支和开发分支。它可以以fixbug-*的形式命名。

创建错误修复分支：

Git checkout -b fixbug-0.1 master已打补丁并合并到master分支中：

Git签出主git merge-no-ff fix bug-0.1 git tag-a 0 . 1 . 1然后将其合并到develop分支：

Git签出开发git merge-no-ff修复bug-0.1最后，删除“bug修复分支”:

Git branch -d fixbug-0.1以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。