Git无处不在，为全球约2700万用户提供服务，包括Facebook，微软，亚马逊，LinkedIn和Apple； 它已成为使用最广泛的版本控制系统。 但是，我们经常发现自己更倾向于错误而不是编码，并且早日意识到Git很难而且容易搞砸。 发现自己纠结在分支机构的网络中。
这通常是由于无法完全理解git的体系结构或更糟，而不是完全遵循体系结构。 随着从事同一个项目的开发人员团队的增加，分支的复杂性也随之增加，这使得解释实际发生的事情变得困难且常常令人困惑。
在此博客中，我们将在CodeNicely共享我们使用的体系结构。 我们不与庞大的团队合作，但是项目要经过许多开发人员的掌控，并且没有适当的架构，因此几乎不可能记录更改。
我们使用由nvie的Vincent Driessen设计和发布的GitFlow模型，事实证明，该模型对于发布管理非常成功。 它为您提供：
- 团队成员之间的并行发展
- 轻松跟踪功能
- 准备生产发布
- 协助快速解决现场生产问题。
我们在这里要做的是对分支策略进行简单，快速的说明，使其更容易理解。 它为开发人员在使用版本控制系统时提供了一套指南，您可以根据需要自由更改。 命令行集成也可用于此模型。 浪费时间，让我们开始吧。
该模型并不像初看起来那样复杂。
我们有两个主要分支，而不是使用单个主要分支： 掌握和开发
- 我们认为
master是反映生产就绪状态的主要分支。 它基本上是正式发布历史记录。 - 我们认为
develop是拥有最新开发代码的主要分支。 它是团队开发人员使用的集成分支。
除了主要分支机构，我们还有各种支持分支机构。 这些分支的寿命总是有限的，最终将被删除。 我们使用的子公司是：
- 功能分支
- 发布分支
- 修补程序分支
基本上，它们只是简单的普通分支，没有技术专长。 分支类型将定义我们将如何使用它们。 这些分支有特定的用途，并具有一些有关分支从何处分支以及合并到哪个分支的规则。
分支并合并回到开发分支
该名称不言自明，功能分支用于向项目添加新功能。 只要功能处于开发状态，功能分支的灵魂就存在，即最终将其合并回到开发分支。
比如说开发人员Domesh，想要开始开发新功能。
- 他将拉出
develop分支的最新副本，处理功能，然后将更改提交到新创建的Feature分支。 - 功能准备好后，他将其合并回
develop分支。 - 在这段时间内，另一位开发人员也可能将其功能分支也合并到
develop中。
该分支的命名约定通常为feature / *。
从开发分支出来，然后合并回去进行开发和掌握。
当开发分支反映下一个新版本（即正式生产）时，将启动发布分支。 该分支包括一些小错误修复和功能的最终补充。 测试人员将在此分支进行测试，并且任何错误都可以在此处报告。 请记住，此分支中未添加任何重大更改或功能。
即将发行的版本是在发行分支中获得新的版本号。 发布分支合并到开发分支和主分支。 最好在合并到master分支时添加标签，这样一来，您就可以跟踪所有主要版本。
该分支的命名约定通常为release-1.2 / *，其中1.2是新版本号。
从母版分支出来，然后合并回去进行开发和掌握。
修补程序分支与发行分支非常相似，通常是短暂的。 当您在生产中遇到错误或不良行为时（需要立即采取行动），将创建一个修补程序分支。 像发行版一样，此修补程序也可以在master和development中合并。 可以用1.2.1（增加的一个分区）标记一个修补程序。
可能会出现一种情况，即已经启动发行版时，需要创建一个修补程序。 在这种情况下，此修补程序将合并到发行分支而不是开发分支中。 最终，该修复程序的结果也将被合并到开发分支。
“分支模型”可以像用于版本控制系统管理的功能完善的机器一样工作。 它不仅为生产修补程序提供了专用渠道，而且还提供了基于发行版的出色软件工作流程。
请访问我们的网站Codenicely.in，并在Facebook上像我们一样保持联系。 另外，鼓掌让我们知道您很喜欢阅读这篇文章，我们始终感谢您的评论。 最后，GitFlow〜并不难！ 请继续关注，还有更多。
