git idea 如何删除本地分支_如何选择 Git 分支模式？

简介：编写代码，是软件开发交付过程的起点，发布上线，是开发工作完成的终点。代码分支模式贯穿了开发、集成和发布的整个过程，是工程师们最亲切的小伙伴。那如何根据自身的业务特点和团队规模来选择适合的分支模式呢？本文分享几种主流 Git 分支模式的流程及特点，并给出选择建议。

分支的目的是隔离，但多一个分支也意味着维护成本的增加。我们可以分别从开发和发布分支的多寡，做个简单组合，即：

• 主干开发，主干发布。
• 分支开发，主干发布。
• 主干开发，分支发布。
• 分支开发，分支发布。

设想两个不同的场景：

• 如果一个软件，只有一个开发者，只需要一个发布版本，那他需要什么样的分支模式？
• 如果一个软件，有 10 位开发者，需要支持多个版本，那他们又需要什么样的分支模式？

一个好的分支模式，可以大大提高软件的开发、集成和发布效率。选择什么样的分支策略，是每一个开发团队开始工作时面临的第一个问题。那么，选择什么样的分支模式才适合我们呢？在回答这个题之前，我们先了解一下几种常见的分支模式。

主流的分支模式

常见的分支模式有 TBD（即主干开发模式）、Git-Flow 模式、Github-Flow 模式及 Gitlab-Flow 模式。

TBD（主干开发模式）

即所有开发者，仅在一个开发分支（即主干）上进行协作开发的模式，在这种模式下，不允许新建任何长期存在的开发分支，有且仅保留主干分支进行开发协作。

因为没有长期分离的其他开发分支，任何代码变更持续地更新到主干上，在一定程度上避免了 merge 代码带来的困扰。同时，在这种开发模式下，建议采用发布分支的策略，根据软件版本的发布节奏拉出发布分支。在 TBD 模式下，所有的修改都是在主干上，哪怕是缺陷的修改也是，修改完缺陷后，再 cherry pick 到发布分支上。

其特点总结一下就是：

• 有且仅有一个开发分支，即主干分支。
• 所有改动都发生在主干分支。
• 发布可以从主干拉发布分支。
• 主干上进行的修复需要根据缺陷的修复策略，确定是否 cherry pick 到对应版本的发布分支。

因为团队共享一个开发分支，并且在开发分支上进行集成验证，而每次代码提交都会触发集成验证，这就要求每次代码的变更在主干上都能快速地验证，以确定是否接受下一次代码变更（每次代码变更都应该基于前一个稳定的版本进行），为了保证主干一直处在可工作状态，这就需要：

• 每一次的变更要小，这样在验证的过程中才能控制范围。
• 快速完成验证，这就要求有相对完善的自动化检查验证机制。

所以，主干开发模式可以说是持续集成的关键推动者。主干开发模式非常利