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 master
Counting 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 origin
git 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
总结
GitLab 提供的上述功能非常实用，为项目的源码管理提供了有力的支持。
http://blog.csdn.net/hongchangfirst/article/details/46693237