Gitlab使用手册

Groups还是Users

对于项目namespace,一般来说,团队项目,Groups更好一些,一个组内可以添加很多项目,更符合一般团队的开发习惯,而Users更适合私人的一些项目。当然,美中不足的是,Groups中成员权限一旦确定,就不能在项目中进行修改。

分支模型

一个中心库至少包含两个分支,即master,dev分支,作为基础分支,另外还有一些辅助分支的概念,常见的有feature、hotfix、release等,另外还有tag,一般也可替代release分支。

  • 基础分支
    • master:隔夜代码,定期将dev的代码合并到master
    • dev:开发主战场,一般任何修改都要合并进来
  • 辅助分支
    • feature:用于开发独立的模块,一旦跟dev合并,一般就删除
    • hotfix:一般是用于修改bug的临时分支,命运和feature类似
    • release:用于发布稳定版本
代码贡献者

如果开发一个新功能,应该在独立分支上,命名feature_id,当然,也可以是hotfix_id、,一般这种分支生命周期为新功能的开发时间,完毕后可删除。为保证开发过程基于最新代码,执行:

1. git fetch origin dev:feature_id;# 将origin/dev抓取下来,在本地重命名为feature_id

修改项目之前,切换到相应分支:

2. git checkout feature_id

修改之后本地提交,然后再pull一遍

3. git pull origin dev # origin/dev可能会被人修改

没有冲突之后,将代码提交到远程gitlab:

4. git push origin feature_id:feature_id # 将本地feature_id推送到远程代码库,新分支名为feature_id

代码提交完毕后,记得发一个merge request,代码审核者会收到邮件通知,那么有两种结果:

  • 如果合并并且功能开发完毕,则可删除feature_id分支: git branch -D feature_id
  • 没有合并,则回到第3步继续修改。
代码审核者

审核者一旦收到merge request,先查看分支对不对,是不是合并到dev,然后查看贡献者所做的修改:

  • 如果不能直接合并,一般close merge request,并要求改正后再提交。
  • 如果能直接合并,考虑到贡献者能力不一,有时需要谨慎,还需将其代码pull到本地仓库进行合并,运行结果满意,则merge,并在留言注明:LGTM, look good to me;反之close merge request,给出理由。
Commit Message规范

格式:[分支名称]+message
例如:[feature_id]添加logo。

一般稍做修改即可在本地做一次提交,一旦功能完善,则使用rebase对先前多次提交进行合并。

SSH Key配置

网上相关资料很多,如果有多个密钥,可新建~/.ssh/config文件,添加多个host:

host gitlab
hostname 10.108.123.211
user git
identityfile ~/.ssh/sunnycomes

host gitolite
hostname 10.108.113.14
user git
identityfile ~/.ssh/admin
额外:Git文件状态
三种文件状态
  1. 状态1. untracked files:需要git add后才能提交
  2. 状态2. changes not staged for commit:commit时需要指定文件,否则不做提交,是一个文件修改之后产生的状态
  3. 状态3. changes to be committed:即使不指定,也会提交
状态转换
  • 新建的文件:

    • 状态1->状态3:git add file_name
    • 状态3->状态1:git reset file_name,git reset默认是reset所有
  • 修改的文件:

    • 状态2->状态3:git add file_name
    • 状态3->状态2:git reset file_name

有时候我们需要撤销对一个文件的修改,回到最近一次提交,那么如果该文件处于状态3,则不能直接使用git checkout file_name,应该先git reset file_name,使其转为状态2,再做检出。

comments powered by Disqus