Gerrit平常维护记录

 

Gerrit代码审核工具是个好东西，尤为是在和Gitlab和Jenkins对接后，在代码控制方面有着无与伦比的优点。

在公司线上部署了一套Gerrit系统，在平常运维中，使用了不少gerrit命令，在此收集下：

1、建立和销毁

（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).

2、合并和冲突

（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 : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</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(-)

3、管理多个分支
前面提到，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 git@search.ued.taobao.net: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 git@search.ued.taobao.net: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