在这篇文章中，我介绍了大约一年前我为一些项目（工作和私人）介绍的开发模型，结果证明非常成功。我一直想写一段时间，但是我从来没有真正找到时间这么做，直到现在。我不会谈论任何项目的细节，只讨论分支策略和发布管理。
为什么是Git？
有关专业人士对于Git源代码的版本控制系统的利弊请参见https://git.wiki.kernel.org/index.php/GitSvnComparsion 。那里有很多关于其利弊的争论。作为一个开发人员，我个人更倾向于使用git，而不是其他的什么工具。git真的在很大程度上改变了开发人员对于分支（branching）和合并(merging)的理解或者说看法。合并（merge）/分支（branch）一直以来都是让人恐惧的（小心合并冲突了，他们咬你），而且你每隔一段时间还不得不做一次。
但是使用git，这些工作将变得非常方便和简单，而且，他们被认为是你工作中的不可或缺（甚至是核心）的一部分。由于其简单性和重复性，分支和合并不再是一件令人害怕的事情。版本控制工具应该比其他任何东西更有助于分支/合并。
主要分支
在核心，开发模型受到现有模型的极大启发。中央仓库拥有两个主要分支，具有无限的生命周期：
masterdevelop
该master分支在origin应该熟悉到每一个用户的Git。与master分支并行，另一个分支称为develop。
我们认为origin/master是源代码HEAD始终反映生产就绪状态的主要分支 。
我们认为origin/develop是主要分支，其源代码HEAD始终反映了下一版本中最新交付的开发更改的状态。有些人称之为“整合分支”。这是建立任何自动夜间构建的地方。
当develop分支中的源代码到达稳定点并准备好发布时，所有更改都应以master 某种方式合并回来，然后使用版本号进行标记。将如何详细地进行详细讨论。
因此，每次将更改合并回时master，根据定义，这是一个新的生产版本。我们对此非常严格，因此从理论上讲，我们可以使用Git钩子脚本在每次提交时自动构建和推出我们的软件到我们的生产服务器 master。
支持分支
接下来的主要分支master和develop，我们的发展模式，采用了多种支持分支机构，以帮助并行开发团队成员之间，缓解功能跟踪，生产准备释放，并协助快速修复现场制作的问题。与主要分支不同，这些分支的寿命有限，因为它们最终会被删除。
我们可能使用的不同类型的分支是：
- 功能分支
- 发布分支机构
- 修补程序分支
这些分支中的每一个都有特定的目的，并且必须遵守关于哪些分支可以是它们的起始分支以及哪些分支必须是它们的合并目标的严格规则。我们将在一分钟内完成它们。
从技术角度来看，这些分支绝不是“特殊的”。分支类型根据我们如何使用它们进行分类。他们当然是简单的旧Git分支。
功能分支
可能分支出自：
develop
必须合并回：
develop
分支命名约定：
任何东西，除了 master，develop，release-*，或者hotfix-*
功能分支（或有时称为主题分支）用于为即将到来或将来的版本开发新功能。在开始开发特征时，此特征的目标版本可能在此处未知。功能分支的本质是，只要功能处于开发阶段，它就会存在，但最终会合并回develop（以便将新功能添加到即将发布的版本中）或丢弃（在实验令人失望的情况下）。
功能分支通常仅存在于开发人员存储库中，而不存在于origin。
创建功能分支
在开始处理新功能时，从develop分支机构分支。
$ git checkout -b myfeature develop
切换到新分支“myfeature”在开发中加入完成的功能
完成的功能可能会合并到develop分支中，以确保将它们添加到即将发布的版本中：
$ git checkout develop
切换到分支'develop'
$ git merge --no-ff myfeature
更新ea1b82a..05e9557
（更改摘要）
$ git branch -d myfeature
已删除分支myfeature（为05e9557）。
$ git push origin开发该--no-ff标志使合并始终创建新的提交对象，即使可以使用快进执行合并。这样可以避免丢失有关功能分支历史存在的信息，并将所有一起添加功能的提交组合在一起。比较：
在后一种情况下，不可能从Git历史中看到哪些提交对象一起实现了一个功能 - 您必须手动读取所有log消息。恢复整个功能（即一组提交）在后一种情况下是一个真正的头痛，而如果使用该--no-ff标志则很容易完成 。
是的，它会创建一些（空的）提交对象，但增益远远大于成本。
发布分支
可能分支出自：
develop
必须合并回：
develop 和 master
分支命名约定：
release-*
发布分支支持准备新的生产版本。他们允许最后一分钟点缀我和交叉t。此外，它们允许小错误修复和准备发布的元数据（版本号，构建日期等）。通过在发布分支上执行所有这些工作，develop 分支将被清除以接收下一个大版本的功能。
分支新发布分支的关键时刻develop是开发（几乎）反映新版本的期望状态。至少所有针对要构建的版本的功能必须develop在此时合并到其中 。针对未来版本的所有功能可能不会 - 他们必须等到发布分支分支后。
正是在发布分支的开始，即将发布的版本被分配了版本号 - 而不是更早版本。直到那一刻，develop 分支反映了“下一个版本”的变化，但不清楚“下一个版本”最终是否会变为0.3或1.0，直到发布分支开始。该决定是在发布分支的开始时做出的，并且由项目的版本号碰撞规则执行。
创建发布分支
发布分支是从develop分支创建的。例如，假设版本1.1.5是当前的生产版本，我们即将推出一个大版本。状态develop为“下一个版本”做好了准备，我们已经决定这将成为版本1.2（而不是1.1.6或2.0）。因此，我们分支并为发布分支提供反映新版本号的名称：
$ git checkout -b release-1.2 develop
切换到新分支“release-1.2”
$ ./bump-version.sh 1.2
文件修改成功，版本提升到1.2。
$ git commit -a -m “Bumped version number to 1.2”
[release-1.2 74d9424] Bumped version number改为1.2
1个文件，1个插入（+），1个删除（ - ）创建新分支并切换到它后，我们会修改版本号。这 bump-version.sh是一个虚构的shell脚本，它可以更改工作副本中的某些文件以反映新版本。（这当然可以是手动更改 - 关键是某些文件会发生变化。）然后，提交了有问题的版本号。
这个新分支可能存在一段时间，直到发布可能肯定推出。在此期间，可以在此分支中应用错误修复（而不是在develop分支上）。严禁在此处添加大型新功能。它们必须合并develop，因此等待下一个大版本。
完成发布分支
当发布分支的状态准备好成为真正的发布时，需要执行一些操作。首先，发布分支被合并到 master（因为每次提交master都是按照定义的新版本，请记住）。接下来，master必须标记该提交，以便将来参考此历史版本。最后，需要将发布分支上的更改合并回来develop，以便将来的版本也包含这些错误修复。
Git中的前两个步骤：
$ git checkout master
切换到分支'master'
$ git merge --no-ff release-1.2
由递归合并而成。
（更改摘要）
$ git tag -a 1.2该版本现已完成，并标记以供将来参考。
编辑：您可能还想使用
-s或-u <key>标记以加密方式对您的标记进行签名。
为了保持发布分支中所做的更改，我们需要将这些更改合并到其中develop。在Git中：
$ git checkout develop
切换到分支'develop'
$ git merge --no-ff release-1.2
由递归合并而成。
（变更摘要）这一步很可能导致合并冲突（可能甚至，因为我们已经更改了版本号）。如果是这样，请修复并提交。
现在我们已经完成了，并且可能会删除发布分支，因为我们不再需要它了：
$ git branch -d release-1.2
删除了分支版本1.2（ff452fe）。修补程序分支
可能分支出自：
master
必须合并回：
develop 和 master
分支命名约定：
hotfix-*
修补程序分支非常类似于发布分支，因为它们也可用于准备新的生产版本，尽管是计划外的。它们源于必须立即采取实际生产版本的不良状态。当必须立即解决生产版本中的严重错误时，可以从标记生产版本的主分支上的相应标记分支修补程序分支。
实质是团队成员（在develop分支机构）的工作可以继续，而另一个人正在准备快速生产修复。
创建修补程序分支
从master分支创建修补程序 分支。例如，假设版本1.2是当前生产版本正在运行并且由于严重错误而导致麻烦。但是变化develop仍然不稳定。然后我们可以分支修补程序分支并开始修复问题：
$ git checkout -b hotfix-1.2.1 master
切换到新分支“hotfix-1.2.1”
$ ./bump-version.sh 1.2.1
文件修改成功，版本提升到1.2.1。
$ git commit -a -m “Bumped version number to 1.2.1”
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1个文件更改，1个插入（+），1个删除（ - ）分支后不要忘记提高版本号！
然后，修复错误并在一个或多个单独的提交中提交修复。
$ git commit -m “修复了严重的生产问题”
[hotfix-1.2.1 abbe5d6]修复了严重的生产问题
5个文件发生了变化，32个插入（+），17个删除（ - ）完成修补程序分支
完成后，需要将错误修复合并回来master，但也需要合并回来develop，以保证错误修复程序也包含在下一个版本中。这与发布分支的完成方式完全相似。
首先，更新master并标记版本。
$ git checkout master
切换到分支'master'
$ git merge --no-ff hotfix-1.2.1
由递归合并。
（更改摘要）
$ git tag -a 1.2.1编辑：您可能还想使用-s或-u <key>标记以加密方式对您的标记进行签名。
接下来，也包括错误修复develop：
$ git checkout develop
切换到分支'develop'
$ git merge --no-ff hotfix-1.2.1
由递归合并而成。
（变更摘要）此处规则的一个例外是， 当发布分支当前存在时，需要将修补程序更改合并到该发布分支中，而不是develop。将错误修复反向合并到发布分支中最终会导致错误修复也被合并到develop发布分支完成时。（如果develop立即工作需要此错误修复并且不能等待发布分支完成，您可以安全地将错误修复合并到develop现在。）
最后，删除临时分支：
$ git branch -d hotfix-1.2.1
删除了分支修补程序-12.1.1（是abbe5d6）。说明：文章翻译自https://nvie.com/posts/a-successful-git-branching-model/