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

轉載于:https://www.cnblogs.com/shengulong/p/8325302.html

總結

以上是生活随笔為你收集整理的git锁和钩子以及图形化界面的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。