IT干货网

Gitlab使用规范

itxm 2022年03月04日 DevOps 167 0

项目组GitLab使用规范
1.   基本信息
(1)  项目组GitLab地址
(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)  开发流程
Master新建代码主仓库MAIN、添加项目成员。
Developer从主仓库fork一份到自己的个人远程仓库ORIGIN。
Developer从个人远程仓库clone代码到本地,建立本地仓库,同时将主仓库MAIN设置为本地仓库LOCAL的upstream
在本地仓库进行开发,需要提交代码时,按照如下步骤:
            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需要紧急修复,协作流程如下。

Master合并主仓库的master分支的v0.1至hotfix分支。
Developer成员拉取主仓库的hotfix分支,按照代码开发的步骤4进行开发。修复完成后提交代码并发起merge request,请求合并个人远程仓库的hotfix分支至主仓库的hotfix分支
Master成员处理Merge Request请求,进行code review,最终合并hotfix分支至master分支
(3)  命令及操作参考
      1. Clone代码到本地

git clone git@gitlab.aa.com.cn: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.aa.com.cn:cams/test.git
## 查看remote信息
git remote –v
## 结果类似如下:
origin  git@gitlab.aa.com.cn:012829/test.git (fetch)
origin  git@gitlab.aa.com.cn:012829/test.git (push)
upstream        git@gitlab.aa.com.cn:cams/test.git (fetch)
upstream        git@gitlab.aa.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")

      详见:http://wiki.aa.com.cn/pages/viewpage.action?pageId=22275447

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

##修改最近一次commit的author
git commit --amend --author="012829<wangbin012829@htsc.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

 
————————————————
版权声明:本文为CSDN博主「ruanhao1203」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ruanhao1203/article/details/80440824


评论关闭
IT干货网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

什么是敏捷解读敏捷