GitLab使用规范

CAMS项目组GitLab使用规范

1.   基本信息

（1）  项目组GitLab地址

      http://gitlab.xxx.xxx.com.cn/cams

（2）  协作开发模式

      开发人员采用fork主仓库的方式进行开发。

      为简化开发过程，方便代码集成。主仓库仅包括两个常驻分支master和hotfix。两个分支都是受保护的。master是代码主分支，主要的开发、代码集成、发布都在此分支上进行。hotfix用于临时bug修复或问题处理。

（3）  成员角色

      项目组成员包含两种权限Master和Developer。主仓库中受保护的分支只有Master成员可以处理代码合并Merge Request和push。

（4）  代码仓库

      开发过程中涉及的代码仓库包括：主仓库、个人远程仓库和本地仓库，它们之间的关系如下图所示：

      主仓库MAIN：位于服务器上代码主仓库，常驻分支master和hotfix，分支均受保护，只有从开发者个人远程仓库发起Merge Request（下文简称MR）才可以进行代码更新。

      个人远程仓库ORIGIN：由MAIN fork而来，位于服务器上个人项目下。

      本地仓库LOCAL：由开发人员从ORIGIN clone而来，位于本地，用于代码开发。后续通过pull/push操作保持LOCAL与ORIGIN的同步。同时，在LOCAL中设置upstream为MAIN，然后通过fetch upstream来获取MAIN的代码。

2.   协作流程

（1）  开发流程

1. Master新建代码主仓库MAIN、添加项目成员。
2. Developer从主仓库fork一份到自己的个人远程仓库ORIGIN。
3. Developer从个人远程仓库clone代码到本地，建立本地仓库，同时将主仓库MAIN设置为本地仓库LOCAL的upstream
4. 在本地仓库进行开发，需要提交代码时，按照如下步骤：

            a) Commit：提交代码到本地仓库

            b) Fetch：获取主仓库的更新，同步到个人本地仓库

            c) Merge：合并主仓库的代码和本地的开发代码。代码会自动合并，但如果有冲突，需手动合并代码解决冲突

            d) Push：提交代码到个人远程仓库

            e) Merge Request：在GitLab的个人主页，发起Merge Request请求将个人远程仓库代码合并到主仓库的对应分支

       5. Master处理Merge Request请求，进行code review。如果一切正常，最终合并到主仓库，打Tag上线。如果有问题，则拒绝Merge Request，要求修改。

（2）  Bug修复流程

      假设是tag v1.0的代码上出现bug需要紧急修复，协作流程如下。

1. Master合并主仓库的master分支的v0.1至hotfix分支。
2. Developer成员拉取主仓库的hotfix分支，按照代码开发的步骤4进行开发。修复完成后提交代码并发起merge request，请求合并个人远程仓库的hotfix分支至主仓库的hotfix分支
3. Master成员处理Merge Request请求，进行code review，最终合并hotfix分支至master分支

（3）  命令及操作参考

      1. Clone代码到本地

git clone [email protected]:012829 /test .git

      2. Commit

## Commit message需要注意规范，详见下一节 git commit –am “ #XYPJ-1111# message example”

      3. Fetch同步主仓库与个人远程仓库，对应（1）小节中第4步

## 建立本地仓库时，设置本地仓库的upstream为主仓库 git remote add upstream git@gitlab.xxx.xxx.com.cn:cams /test .git ## 查看remote信息 git remote – v ## 结果类似如下： origin  git@gitlab.xxx.xxx.com.cn:012829 /test .git (fetch) origin  git@gitlab.xxx.xxx.com.cn:012829 /test .git (push) upstream        git@gitlab.xxx.xxx.com.cn:cams /test .git (fetch) upstream        git@gitlab.xxx.xxx.com.cn:cams /test .git (push)   ## 之后代码开发时的操作 ## fetch主仓库代码到本地（只是获取，还未合并） git fetch upstream ##本地代码切换到master分支（如果已经在master分支就跳过这一步），然后合并主仓库的master分支到本地的master分支 git checkout master git merge upstream /master ## 提到代码到个人远程仓库 git push origin master ## 注意：如果是bug修复，则以上fetch/merge/push都是hotfix分支

      4. Merge Request

      登录GitLab，在个人项目主页中，发起Merge Request。如下图所示，表示要将个人仓库012829/test的master分支的代码合并到主仓库cams/test的master分支。

         如果发起MR时发现有报代码冲突，则可以自己关闭MR，按照上一步的操作解决冲突合并代码后，重新发起MR。

      5. 分支管理

      详见附录3《分支管理》

3.    相关规范

（1）  commit规范

      代码commit时必须带上正确的commit message和正确的author

      commit message必须是“#XYPJ-2199# corrent commit message example”格式，与之前SVN代码提交时一样。

      git commit –m “#XYPJ-1234# this is the correct commit message”

      Author必须是K开头的或者0开头的，务必设置git的user.name为工号（git config --global user.name "012829"）

      详见：https://blog.csdn.net/qq_34117825/article/details/80448620

      如果commit message或者author不正确，会出现无法push到远程仓库的错误。出现这种情况时，用如下方法修改最近一次commit

##修改最近一次commit的author git commit --amend --author= "012829<xxx@xxx.com>" ##修改最近一次commit的commit message git commit --amend -m  "#XYPJ-2179#初始化SV代码仓库"

      当前commit规范可以由git hook强制实施，但是其他流程目前无自动化的强制措施，需要开发人员在开发中形成习惯。

（2）  代码合并

• 注意与主仓库的同步，保持一定的fetch频率。防止出现长时间不同步而冲突严重的情况。
• 如果发起MR时发现有冲突，可自己撤回手动解决冲突后再重新发起。
• 向主仓库发起MR不要过于频繁，一般以JIRA中一个任务为单位，任务完成提交代码并向主仓库发起MR

（3）  分支管理

      在个人仓库和本地仓库开发时，可以也鼓励多使用git的分支功能来管理代码，但为了保持主仓库的整洁，主仓库不会有多余的分支。因此个人开发的功能必须先合并到个人仓库的master分支（处理bug时是hotfix分支），然后再发起MR。

4.   附录：参考资料

《Git基本教程》：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

《Git常用命令》：http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html

尤其要重视分支和远程仓库这两个概念

《分支管理》：http://www.ruanyifeng.com/blog/2012/07/git.html

《远程仓库操作》：http://www.ruanyifeng.com/blog/2014/06/git_remote.html