项目在手，天下我有！

但是，这个地方的区别在于参与者有了超时机制，如果参与者超时未收到doCommit命令的话，将会默认去提交事务。

DoCommit

DoCommit阶段对应到2PC的执行阶段，如果上一个阶段都是收到YES的话，那么就发送doCommit命令去提交事务，反之则会发送abort命令去中断事务的执行。
 

新功能大量合并到 master 分支后容易造成 master 分支质量不稳定，不稳定会有什么问题?比如线上突然有个 bug 要解决，可能只需要修改一行代码就能解决，但是 master 分支已经合入了大量新特性，测试人员还没来得及测试，那最稳妥的办法就是将代码回退到上一次发版本的时间节点，基于这个节点再修改一行代码，是不是太麻烦了?

为了解决这些问题，Vincent Driessen大佬基于开发实践总结了一套 Git 分支管理的流程和规范，下面详细介绍一下。

Gitflow 工作流

Gitflow 工作流是目前非常成熟的一个方案，它定义了一个围绕项目发布的严格分支模型，通过为代码研发、项目发布以及维护分配独立的分支来让项目的迭代过程更加地顺畅，不同于之前的集中式工作流以及功能分支工作流，Gitflow 工作流常驻的分支有两个：主干分支 master、开发分支 develop。

和功能分支工作流相比，Gitflow工作流没有增加任何新的概念或命令，它给不同的分支指定了特定的角色，定义它们应该如何、什么时候交互。除了功能分支之外，还为准备发布、维护发布、记录发布分别使用了单独的分支。

Gitflow 常见分支：

• 开发主分支：master 分支

master 分支的代码是可以直接部署到生成环境的，为了保持稳定性一般不会直接在这个分支上修改代码，都是通过其他分支合并过来的。

• 开发主分支：develop分支

develop 分支是主开发分支，包含所有要发布到下一个release的代码，主要是由feature分支合并过来的。

• 临时分支：feature 分支

feature 分支主要是用来开发一个新特性，一旦开发完成会合入 develop 分支，feature 分支也随即删除掉。

• 临时分支：release 分支

当需要一个发布一个新release版本时，会基于develop分支创建一个release分支，经过测试人员充分测试后再合入 master 分支和 develop 分支。

• 临时分支：hotfix 分支

当在生成环境发现新的Bug时候，如果需要紧急修复，会创建一个hotfix分支， 充分测试后合入master和develop分支，随后删除该分支。

各分支如何配合工作?

(1)master/develop分支

原则上master分支上所有的commit 都应该打上Tag，因为一般情况下master不存在 直接commit;

devlop分支 是基于 master分支创建的，与 master 分支一样都是主分支，不会被删除。

develop 从 master 拉出来之后会独立发展，不会与 master 直接产生联系。

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!