0x00 背景
很多小伙伴的代码都借由git做版本控制和协同开发,但不管是小团队任务还是个人开发,大多都是简单通过不同分支去控制开发任务。但是当团队大起来、人员多起来,各种开发者随手建立的分支四处横飞,简单的基于分支的协作管理方式就不够用了。今天介绍下Git团队合作的一个工作流程。
0x01 流程图
团队合作的模式主要是基于团队项目仓库和个人仓库之间的fork和merge request机制,结构图如下:
+-------+
| 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:
# 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
然后切换到需要跟踪的分支,执行:
# Fetch from upstream remote
git fetch upstream
# View all branches, including those from upstream
git branch -va
然后回到自己分支合并下远端上的修改:
# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master
0x04 优点
- 这样的开发模式有完整的权限保护机制,可以避免一个
git push -f
命令引发血案的悲剧 - 避免大家都在主repo上开发,人一多起来各种
dev_xxx
和hotfix
分支乱飞的情况 - 对于一个gitlab使用者来说,在
update request
的阶段可以集成一些gitlab-ci的工具用于强制代码检查等操作
0xff 参考资料
GitHub Standard Fork & Pull Request Workflow
GitHub - Fork a Repo
查看更多文章请访问我的博客——左旋异构
本文地址Git团队合作开发流程
网友评论