Git分支策略

适用场景
总结
参考

Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称”快照”）的指针，因此非常快捷易用。

但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。

Git 提供了丰富的分支策略和工作流方式，在深入学习业界 Git 工作流时，每种工作流都设计的非常好，似乎都能运用到团队实践。但在引入 Git 工作流规范开发时要留意：Git 工作流仅仅是整个研发流程中的一环。上游项目管理/缺陷追踪系统虎视眈眈，下游 CD (Continuous Delivery) 嗷嗷待哺，还得考虑团队规模、产品形态、发版方式等等因素。因此，在团队中落地 Git 工作流规范并不是一件能轻松决定的事

Git 工作流程有一个共同点：都采用“功能驱动式开发”（Feature-driven development，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除

适用场景

在套装软件的背景下，以上流程运作起来匹配度很高。

我们需要同时支持多个版本。因为不同的用户可能需要不同的版本，用户需要去学习这些版本之间的差别，找到那个适合自己的。
我们不需要频繁推出新功能，可能半年一次，或者一年一次。

不过还有另一种软件 - 互联网服务(网站、手机端、智能设备等)，需求就不一样了：

用户并不需要关心自己使用的是哪个版本，好用就行。有的甚至不需要安装，打开既用
需要频繁发布新的版本和新的功能，有的每天发布好多次。因为市场的竞争太过激烈，用户的需求也在很快的发生变化

从以上特性可以看出理念的转变：

以产品为中心到以用户为中心

不管是以产品为核心还是以用户为核心，其实大家的目的都是一样的 - 帮助用户解决问题，创造价值。不同的点就是重心在哪里。互联网之所以发展如此迅速，我相信和TA的理念 - 以客户为中心是分不开的。

站在Git这一类产品的角度，我们开发人员就是用户。站在我们自己开发的服务角度，使用我们服务的人就是我们的用户。那我们现在站在客户的角度，来梳理一下我们的诉求：

如何让合并代码不会成为恶梦，我只想开心的写代码，不想一合并就有很多冲突
我的代码为什么要被审核？如果是为了保证质量，是否可以提前告诉我标准，我可以按标准来写，梳理测试用例。如果是想帮助我提高我的代码技能，是否可以提前沟通，我也可以查漏补缺
我为什么要关心服务的版本号，我只是想查看一下我的工资是否到账了
年底了，大家都会收到年度账单，我也想看看我的储蓄卡这一年的账单。如果现在没有，两天后我能不能看到？
总结

Git 工作流是为了上线有保障，上线过程中充分测试必不可少，良好的 Git 工作流能保障测试是渐进且可靠的。环境管理和 Git 工作流结合在头条内部也形成了很多规范，包括「环境部署」、「流量调度」、「连通性测试」等使用规范；「限定场景允许」、「暂时场景允许」、「限定流程允许」等环境约束规范。再结合 CI/CD，我们就可以全链路保障业务的快速迭代、安全上线

参考

https://nvie.com/posts/a-successful-git-branching-model/
https://homes.cs.washington.edu/~mernst/advice/version-control.html#Dont_commit_generated_files -Version control concepts and best practices
https://zhuanlan.zhihu.com/p/257158164 - 字节研发设施下的 Git 工作流

适用场景

总结

参考