Gerrit日常維護記錄

 

Gerrit代碼審核工具是個好東西，尤其是在和Gitlab和Jenkins對接后，在代碼控制方面有着無與倫比的優勢。

在公司線上部署了一套Gerrit系統，在日常運維中，使用了很多gerrit命令，在此收集下：

一、創建和銷毀

（1）分支列表：
$: git branch
* master
prepub
product
（2）創建分支：
$: git branch prepub
（3）切換已有分支：
$: git checkout prepub
Switched to branch 'prepub'
（4）創建並切換分支：
$: git checkout -b issue1234
Switched to branch 'issue1234'
（5）刪除分支：
$: git branch -d issue1234
Deleted branch issue1234 (was b904c07).

二、合並和沖突

（1）合並前要先切回 要並入 的分支。
以下表示issue1234分支合並入master分支
$: git checkout master
$: git merge issue1234
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

沖突的時候，git會報出哪些文件沖突，這時候需要手動解決完沖突方可提交。
$: git merge issue1234
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

通過git status查看沖突文件。

$: git status
index.html: needs merge
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# unmerged: index.html
#
打開index.html，git會在沖突位置做上標示。
<<<<<<< HEAD:index.html
<div id="footer">contact : [e-mail]</div>
=======
<div id="footer">
please contact us at [e-mail]
</div>
>>>>>>> iss53:index.html
解決完沖突，這時候需要手動標識該沖突已經解決，類似svn的resolved。
$: git add index.html
$: git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.html
#
這時候就可以提交了。
$: git commit -m "合並issue1234"
[master e3ece67] 合並issue1234
1 files changed, 1 insertions(+), 0 deletions(-)

三、管理多個分支
前面提到，git非常推薦頻繁使用分支，在大量分支的情況下，我們需要對分支做好管理（曾經一次上線，開了13個分支 = =）
通過-v可以看到最后一次提交日志。

通過--merged和--no-merged來查看分支是否已經合並完成。
$: git branch --merged
* master
p4popt
$: git branch --no-merged
prepub
product
未合並的分支，在刪除時會提示分支未合並。
$: git branch -d product
warning: deleting branch 'product' that has been merged to
'refs/remotes/s/product', but it is not yet merged to HEAD.
Deleted branch product (was 301ae4e).

分支管理流程
一般情況下，分支可以划分為長分支和短分支兩種。
長分支

長期任務
prepub：上線前合並，根據上線列表，從各個分支中集中到該分支，統一部署提測
master：上線后合並，長期保留一個穩定可用的分支應付緊急任務
項目
較難解決的bug
新特性試驗田
重構
長分支，經常會落后其他分支一大截，需要養成習慣，適時從其他重要分支進行合並， 尤其是項目分支 。
短分支

臨時需求
小bug
分支可視化
git本身的log提供--gragh選項，可以提供字符界面的分支可視化視圖。
$: git log --graph --pretty=oneline
| * 50cc7a78b7f2704a2014afa3667f6ac5b5b47374 merging refs/remotes/origin/prepub into HEAD
| |\
| | * 8f685bd1be3757effe32d6ff37f86bd07dd2b549 又被無情地沖掉了代碼
| * | 75a17b4ad610327a9b0e1eecfc6c4bf9cade7359 修改icon
| |/
| * 146a0990de450c854b1a7d9995e12979fff2d537 merging refs/remotes/origin/prepub into HEAD
| |\
| | * 93b379680796eb443961bb8c59008f8ae5678be4 Merge branch 'prepub' of search.ued.taobao.net:projects/search into prepub
| | |\
| | * | 8b93380ccfb9020bf8f8e1e8a4a553601de3c788 p4p加上refpid，開發給出來的配置是 P4P_refpid
| * | | 08201de89834f6fecb195c2b7c3546b5cafccc85 秒殺折扣浮動層樣式
| | |/
| |/|
| * | 0f4d1df17f79c7aa3ca3d36ab848c10b78029010 修改icon
| * | ae719fc29cc550321f284323db06a294b97c1398 p4p創意優化
| |/
| * a6d4501e1456589d30ab1a5800b651876629c8ca 修改icon
git還有很多GUI工具，可以提供可視化地分支走勢圖，比如gitk，qgit，GitX等等。
遠程分支

至今為止，前面所有提到的概念都是直接本地操作的，並不需要任何網絡連接。
而git本身是一個分布式代碼管理工具(DVCS)，所以分支管理上，存在本地分支和遠程分支兩種概念。
可以簡單的理解，遠程分支就是別人的本地分支push到服務器上的時候產生的。比如master就是一個最典型的遠程分支（默認）。
$: git push origin master
除了master之外，我們還可以隨便創建分支，然后push到服務器上去。
$: git push origin prepub
Counting objects: 27, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (15/15), 7.30 KiB, done.
Total 15 (delta 10), reused 0 (delta 0)
To [e-mail]:projects/search.git
1b95a57..779dbe1 prepub -> prepub
遠程分支的標識形式為{remote/branch}，比如origin/product。
$: git branch -a
master
p4popt
* prepub
product
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/p4popt
remotes/origin/prepub
remotes/origin/product
遠程分支和本地分支需要區分，所以，在從服務器上拉取特定分支的時候，需要指定本地分支名字。
$: git branch product origin/product
Branch product set up to track remote branch product from origin.
而1.6.2以上版本的git，可以通過--track選項，簡化這一過程。這也是為什么直接執行git clone的時候，會自動創建本地master分支的原因。（實際上，pull操作相當於fetch+merge。）
$: git checkout --track origin/product
Branch product set up to track remote branch refs/remotes/origin/product.
Switched to a new branch "product"
遠程分支和本地分支是松散的結構，可以把任意遠程分支合並到任意本地分支里；同樣，也可以把任意本地分支push到任意遠程分支上。
# THIS WILL MESS UP YOUR REPO!!
$: git branch
master
* prepub
p4popt
product
$: git pull origin product
$: git push origin master
同步本地遠程分支。
$: git fetch origin
刪除遠程分支。
$: git push origin :p4popt
To [e-mail]:projects/search.git
- [deleted] p4popt
補充：git cherry-pick和git rebase
git cherry-pick可以選擇某一個分支中的一個或幾個commit(s)來進行操作。例如，假設我 們有個穩定版本的分支，叫v2.0，另外還有個開發版本的分支v3.0，我們不能直接把兩個分支合並，這樣會導致穩定版本混亂，但是又想增加一個v3.0 中的功能到v2.0中，這里就可以使用cherry-pick了。

# 先在v3.0中查看要合並的commit的commit id
git log
# 假設是 commit f79b0b1ffe445cab6e531260743fa4e08fb4048b

# 切到v2.0中
git check v2.0

# 合並commit
git cherry-pick f79b0b1ffe445cab6e531260743fa4e08fb4048b
git rebase有點類似git merge，但是兩者又有不同，打個比方，你有兩個抽屜A和B，里面都裝了衣服，現在想把B中的衣服放到A中，git merge是那種橫沖直撞型的，拿起B就倒入A里面，如果滿了（沖突）再一並整理；而git rebase就很持家了，它會一件一件的從B往A中加，會根據一開始放入的時間順序的來加，如果滿了你可以處理這一件，你可以繼續加，或者跳過這一件，又 或者不加了，把A還原。所以merge適合那種比較瑣碎的，簡單的合並，系統級的合並還是用rebase吧。

# 合並b
git rebase b

# 處理完沖突繼續合並
git rebase --continue

# 跳過
git rebase --skip

# 取消合並
git rebase --abort