Git团队合作开发流程

发表于 | 分类于 | |

0x00 背景

很多小伙伴的代码都借由git做版本控制和协同开发，但不管是小团队任务还是个人开发，大多都是简单通过不同分支去控制开发任务。但是当团队大起来、人员多起来，各种开发者随手建立的分支四处横飞，简单的基于分支的协作管理方式就不够用了。今天介绍下Git团队合作的一个工作流程。

0x01 流程图

团队合作的模式主要是基于团队项目仓库和个人仓库之间的fork和merge request机制，结构图如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
                                             +-------+
                                             |  dev  |
                                             +---+---+
                                                 |
                                                 |push
+-------------------+                            |
|                   |      fork        +---------v--------+
|   Upstream repo   +------------------>  Personal repo   |
|                   |                  +---+-----+--------+
+---------+---------+                      |     |
          ^                                |     |
    merge |                   create update|     |
          |                   +------------+     |
          |                   |                  |
          |                   |                  |
          |           +-------v--------+         |
          +-----------+  Merge Request <---------+
            approve   +---+---------+--+ update request
                          ^         ^
                          |         |
                    +-----+--+   +--------+
                    |Reviewer|   |Reviewer|
                    +--------+   +--------+

0x02 流程解释

此开发流程首先需要建立一个公共的仓库，用于存储大家协商一致审核通过的开发代码。在这个仓库中需要设置严格的权限保护，确认开发者不能直接推代码到主分支上去。

需要开发的开发者通过fork的方式复制一个主仓库到自己的个人仓库。然后就是正常的开发流程，拉取自己仓库的代码到本地，在这个仓库上建立分支进行开发。这个过程中的push、pull、commit等操作如果不熟悉的话，可以参考Github这份文档或者这份互动教程（墙裂推荐！）。在这个过程中如果主仓库有更新需要跟踪，可以参考下一节的内容。

完成一个比较完整的功能开发，也完成自测，各种修改都提交到自己的repo之后，便需要创建一个Merge Request/Pull Request，在Github中这个操作被叫做Pull Request，在Gitlab中是Merge Request。但实质一样，都是一个需要把代码合并入主分支的请求。在自己的代码仓库界面可以找到“Compare and Pull Request”按钮，点开页面填写修改细节之后提交请求。

提交后被Assign的代码审核者或者项目管理员会审核相关代码，并且在有问题的部分评论，如果需要更改，可能会有多个“提交-打回-提交”的循环。最后，审核者觉得无误后便会统一合并，新修改的代码便被合并进了主仓库中。

0x03 一些操作细节

跟踪主仓库的修改

如果主仓库有修改，我们想把这些修改拉到自己的仓库的话，可以先添加一个remote：

1
2
3
4
5
# Add 'upstream' repo to list of remotes
git remote add upstream https://github.com/UPSTREAM-USER/ORIGINAL-PROJECT.git

# Verify the new remote named 'upstream'
git remote -v

然后切换到需要跟踪的分支，执行：

1
2
3
4
5
# Fetch from upstream remote
git fetch upstream

# View all branches, including those from upstream
git branch -va

然后回到自己分支合并下远端上的修改：

1
2
3
# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master

0x04 优点

  • 这样的开发模式有完整的权限保护机制，可以避免一个git push -f命令引发血案的悲剧。主项目只会有几个人有权限做merge，而大家fork下来到自己仓库的代码自己想怎么管就可以怎么操作
  • 避免大家都在主repo上开发，人一多起来各种dev_xxx和hotfix分支乱飞的情况
  • 对于一个gitlab使用者来说，在update request的阶段可以集成一些gitlab-ci的工具用于强制代码检查等操作
  • 同样是集成CI/CD工具，如果想测试一些自己改动的功能，提交patch的时候不用直接提到主的repo上，造成大家一堆人的测试patch都在主repo里

0xff 参考资料

GitHub Standard Fork & Pull Request Workflow
GitHub - Fork a Repo