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