背景
Ruby on Rails作者汉森说,灵活性被过分高估——约束才是解放。 无规矩不成方圆。世事向来如此,不在一定规则之内,十之八九不能成事。 假使一个团队内部没有约束,形成一套做事的规范,必定走向混乱。
协作流程
目前比较广泛使用的协作流程有三种,Git Flow/Github Flow/Gitlab Flow,所处团队使用的是Git Flow/Github Flow,就聊聊这个。 那么,当谈论协作流程时,我们在应该讨论些什么?可以参考这篇文章,Gitflow Workflow。
操作
分支
主分支
主分支(Master)
代码库有且只有一个主分支,用来发布正式版本。
开发分支
开发分支(Develop)
- 开发分支用来生成代码的最新开发中的版本
- 需要对外发布时,则在Master分支上,对Develop分支进行合并
临时分支
功能分支(feature)
- 为了开发特定功能从Develop分支checkout下来的,开发完成后再并入Develop
- 命名为feature/x
- 合并成功后删除此分支或可保留一周再删除
预发布分支(release)
- 预发布分支是从Develop分支checkout下来,在正式发布版本之前,需要对预发布的版本进行一个全面测试
- 命令为release/x
- 预发布结束后,确认没问题后需要分别合并到Master分支和Develop分支
热修复分支(hotfix)
- 线上出现紧急bug需要发布一个分支修复,从Master分支checkout出来
- 命名为hotfix/x
- 修复结束后再合并进Master和Develop分支
修复分支(fix)
- 软件发布后难免有bug,需要发布一个分支进行bug修复,从Develop分支checkout出来
- 命名为fix/x
- 修复结束后再合并进Develop分支
P.S. Master分支和Develop分支都是在主仓库上,feature/release/fix/hotfix分支是开发者从主仓库fork下来的仓库上创建的,分支命名可以参考语义化版本 2.0.0。
提交
- 不要一次提交就推送,可多次提交再推送
- 提交合并时的粒度是一个功能点/bug fix
-
第一行是不超过50个字的提要,空一行罗列出改动原因、主要变动、以及需要注意的问题,最后一行提供对应的记录网址,包括bug/功能点 ```bash Present-tense summary under 50 characters
- More information about commit (under 72 characters).
- More information about commit (under 72 characters). ……
http://taiga.bu6.io/project/p_c-appxiang-guan-ye-wu/us/274 ```
推送/拉取
- 分支在开发的过程中,需要经常和master分支保持一致
- 分支开发完成后,在合并到master分支前,可以先将多个commit合并
合并
- 在分支的代码合并到master分支时,如果master分支是分支的父分支,考虑用git rebase,不使用git merge
- 在与多人合作时,合并前必须进行code review
其他补充
25 Tips for Intermediate Git Users