git锁和钩子以及图形化界面-白红宇

git锁和钩子以及图形化界面

阅读量：6281 次

发布时间：2019-06-22

本文共 2905 字，大约阅读时间需要 9 分钟。

1、锁机制 Locking Options

　　严格锁（strict locking）：一个时刻，只有一个人可以占用资源。

　　乐观锁（optimistic locking）：允许多个人同时修改同一文件。乐观锁基于一个假定：大多数时候，这种并发修改不会引起冲突。

2、Git可以定制一些钩子，这些钩子可以在特定的情况下被执行，分为Client端的钩子和Server端的钩子。Client端钩子被operation触发，比如commit，merge等，Server端钩子被网络动作触发，比如pushed commits。

那么钩子是放在哪的呢？

在.git/hooks/文件夹下。当你init一个仓库的时候，下边会有一些钩子的例子，以.sample结尾，都是些sh文件

3、在某个分支下使用命令gitk，可以看到这个分支的提交信息

使用git gui命令可以看到git的图形化用户界面

除了 Git 命令，权限控制也是 Git 中极为重要的组成部分，本文主要介绍 GitLab 系统提供的最常用的权限控制功能。

分配成员角色

首先来了解下，Git 中的五种角色：

角色	描述
Owner	Git 系统管理员
Master	Git 项目管理员
Developer	Git 项目开发人员
Reporter	Git 项目测试人员
Guest	访客

每一种角色所拥有的权限都不同，如下图：

我们需要做的是，为项目成员分配恰当的角色，以限制其权限。

锁定受保护分支

在对 Git 不熟悉的时候，时常苦恼于各个分支不受约束，任何开发人员都可以向任何分支直接推送任何提交，各种未经审查的代码、花样百出的 Bug 就这样流窜在预发布分支上。

其实我们可以通过 GitLab 的 受保护分支（Protected Branches） 功能解决该问题，该功能可用于：

阻止 Master 角色以外的开发人员直接向此类分支推送代码，保持稳定分支的安全性；

在向受保护分支合并代码前，强制进行代码审查。

接下来我们就使用这项功能，锁定我们的受保护分支——主分支 master 和预发布分支 release-* ，以阻止 Developer 直接向这两类分支中推送代码：

锁定后，Developer 推送代码将会报错：

$ git push origin masterCounting objects: 4, done.Delta compression using up to 4 threads.Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 283 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 1 (delta 0) remote: GitLab: You are not allowed to access master! remote: error: hook declined to update refs/heads/master To git@website:project.git ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'git@website:project.git'

发起合并请求

锁定受保护分支后，要么 Master 需要时刻、主动关注各特性分支的进度，要么 Developer 需要线下、口头向 Master 汇报其特性分支的进度，这两种做法都非常不便于 Master 管理每个预发布分支的合并，尤其在团队大、分支多的情况。

我们可以通过 GitLab 的 发起合并请求（Merge Request） 功能解决该问题，这样既可以让 Developer 更自如的掌控自己分支进度，在必要的时候才主动发起合并请求；又可以减轻 Master 的合并工作量和沟通成本，可谓一举两得。

新建合并请求

第一步，按表单要求填写合并请求。注意，对于 Developer 而言：

From 是你的特性分支 feature-* ；

To 只可能是预发布分支 release-* ；

Title 和 Description 要填写恰当的分支描述；

Assign to 是该项目的 Master。

审查合并请求

第二步，Master 收到合并请求后，进行代码审查。逐一查看 Commits 一栏提交的内容即可，对于需要改进的代码，可以直接在该行添加注释，非常方便。

如果对整个请求还有疑问的地方，还可以通过底部的 Discussion 功能进行线上讨论。

处理合并请求

第三步，针对审查结果进行相应处理：

关闭

对于完全不合格的垃圾代码、或者废弃的特性分支的合并请求，Master 点击右上角的 Close按钮即可。合并请求将被关闭，相当于扔进回收站。

改进

对于分支内需改进的代码，Developer 直接修正并推送即可，合并请求将会自动包含最新的推送提交。

接受

Master 审查无误后，可以接受该次合并请求。点击 Accept Merge Request 按钮将自动合并分支，勾选 Remove source-branch 将同时删除该特性分支。

整个自动合并过程如果以命令形式手工执行的话，步骤如下：

#Step 1. Update the repo and checkout the branch we are going to merge git fetch origingit checkout -b test origin/feature-test#Step 2. Merge the branch and push the changes to GitLab git checkout release-2016.4.7 git merge --no-ff feature-test git push origin release-2016.4.7

以非快进式合并完成后，祖先图谱（graph）的展现结果如下：

*   be512fa (HEAD, origin/release-2016.4.7, release-2016.4.7)  Merge branch 'test' into 'release-2016.4.7' |\ | * 1f52adf 测试 |/ * a4febbb (tag: 1.0.0, origin/master) 格式化货币保留两位小数

最后需要注意的是，只有 Assignee 才能够接受合并请求，其它人只会被通知：

You don’t have permission to merge this MR