Git 代码分支模型（3）：Atlassian Simple Git Flow & Google Upstream First

Post Views: 4,598

除了之前描述的Gitflow、Github Flow、TBD和GitLab Flow之外，业界还有很多其他的分支模型，其中多数是追求简单高效的TBD模式，我们在选择Atlassian、Google和被Atlassian收购的BitBucket看看，可以看到大体上他们的工作模式都是追求极简的工作流。

本系列一共3篇文章：

（1）GitFlow、GitHubFlow 和 TBD

（2）GitLab Flow

（3）Atlassian Simple Git Flow & Google Upstream

一、Atlassian Simple Git Workflow

Atlassian算是目前最主流的开发管理工具提供商了，这几年陆续收购了OpsGen、Trello、StatusPage、Bitbucket、SourceTree、Wikidocs等开发工具提供商，基本上已经完成了DevOps转型。Atlassian的建议是采用简单的Git工作流程。仔细看完了其建议和思路，其实和我们1995年手工版本管理、1996年用VSS版本管理的思路一样，都是提前合并代码，避免最后代码合并困难，现在有个新词儿叫做rebase。

整体7个步骤如下：

1. Start by pulling down the latest changes from master

2. Branch off to isolate the feature or bug-fix work in a branch

3. Now you can work on the feature

4. To keep your feature branch fresh and up to date with the latest changes in master, use rebase

5. When ready for feedback push your branch remotely and create a pull request

6. Perform a final rebase cleanup after the pull request has been approved

7. When development is complete record an explicit merge

二、Google Chromium Upstream First

没啥太多干货，大体意思是，要想被Chromium接受patch，必须首先被上游的社区接受，比如Linux Kernel、Subsystem Maintainer等等。这种模式可以避免开发者面临太多的分支，当然，也会增加补丁接收周期

三、Bitbucket的Git流程比较

这个文章分析了各种流程：

1、集中化的开发模式：基本类似前面的Simple Workflow（TBD + Rebase），给出了例子，比较简明

2、Freature Branching：这个很类似GitLab Flow

3、GitFlow Workflow：这个是最复杂的Flow，但是依然是一个仓库

4、Forking Flow：这个是比GitFlow更复杂，有两个仓库

结论：

通过这3篇文章的分析，基本上可以看到，Git出现后，并没有什么新的开发模型，最简单的、最复杂的都和20年前我们用VSS、甚至手工方式管理代码大同小异，只是工具有所不同。这应了一句话：工具是死的，人是活的。

钱五哥の原创空间