Gerrit Daily Operations Command collection

The Gerrit Code review tool is a good thing, especially after docking with Gitlab and Jenkins, with unparalleled advantages in code control.

A set of Gerrit systems has been deployed on the company line, and in daily operations, many Gerrit commands have been used, collected here:

I. Creation and destruction

(1) Branch list:
$: Git branch
* Master
Prepub
Product
(2) Create a branch:
$: Git branch prepub
(3) Toggle Existing branch:
$: Git checkout prepub
Switched to branch ' Prepub '
(4) Create and switch branches:
$: Git checkout-b issue1234
Switched to branch ' issue1234 '
(5) Delete branch:
$: Git branch-d issue1234
Deleted Branch issue1234 (was b904c07).

Ii. Mergers and conflicts

(1) First cut back the branch to be merged before merging.
The following indicates that the ISSUE1234 branch is merged into the master branch
$: Git checkout Master
$: Git merge issue1234
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions (+), 0 deletions (-)

At the time of the conflict, GIT will report any file conflicts that need to be manually resolved before the conflict can be submitted.
$: Git merge issue1234
Auto-merging index.html
CONFLICT (content): Merge CONFLICT in index.html
Automatic merge failed; Fix conflicts and then commits the result.

View the conflicting files through git status.

$: Git status
Index.html:needs Merge
# on Branch Master
# Changed but not updated:
# (use "git add <file> ..." To update what would be committed)
# (use "Git checkout-<file> ..." to discard changes in working directory)
#
# unmerged:index.html
#
opening the Index.html,git will be marked in the conflict location.
<<<<<<< HEAD:index.html
<div id= "Footer" >contact: [Email protected]</div>
=======
<div id= "Footer" >
Please contact us at [email protected]
</div>
>>>>>>> iss53:index.html
resolve the conflict, this time need to manually identify the conflict has been resolved, similar to SVN resolved.
$: Git add index.html
$: Git status
# on Branch Master
# Changed but not updated:
# (use "git add <file> ..." To update what would be committed)
# (use "Git checkout-<file> ..." to discard changes in working directory)
#
# modified:index.html
#
This is the time to submit.
$: Git commit-m "Merge issue1234"
[Master e3ece67] Merge issue1234
1 files changed, 1 insertions (+), 0 deletions (-)

Iii. managing multiple Branches
As mentioned earlier, Git is highly recommended for frequent use of branches, and in the case of a large number of branches we need to manage the branches (once on-line, open 13 branches = =)
You can see the last commit log through-V.

See if the branch has been merged by--merged and--no-merged.
$: Git branch--merged
* Master
P4popt
$: Git branch--no-merged
Prepub
Product
Branches that are not merged will be prompted to not merge when deleted.
$: Git branch-d product
Warning:deleting Branch ' product ' that have been merged to
' Refs/remotes/s/product ', but it isn't yet merged to HEAD.
Deleted Branch Product (was 301ae4e).

Branch management process
In general, a branch can be divided into two types: Long Branch and Short branch.
Long Branch

Long-term tasks
Prepub: Merge before you go online, centralize from each branch to the branch from the on-line list, unified deployment to test
Master: Merge after online, long-term retention of a stable available branch emergency task
Project
More difficult bugs to resolve
New feature plot
Refactor
Long Branch, often lag behind other branches a large section, need to develop habits, timely from other important branches of the merger, especially the project branch.
Short Branch

Temporary requirements
Small bug
Branch visualization
The log of Git itself provides the--gragh option to provide a branching visual view of the character interface.
$: git log--graph--pretty=oneline
| * 50cc7a78b7f2704a2014afa3667f6ac5b5b47374 merging refs/remotes/origin/ Prepub into HEAD
| |\
| | * 8f685bd1be3757effe32d6ff37f86bd07dd2b549 was ruthlessly washed away code
| * | 75a17b4ad610327a9b0e1eecf c6c4bf9cade7359 Modify Icon
| |/
| * 146a0990de450c854b1a7d9995e12979fff2d537 merging REFS/REMOTES/ORIGIN/PREPUB into HEAD
| |\
| | * 93b379680796eb443961bb8c59008f8ae5678be4 Merge branch ' prepub ' of Search.ued.taobao.net:proje Cts/search into prepub
| | |\
| | * | 8b93380ccfb9020bf8f8e1e8a4a553601de3c788 P4P plus REFPID, the developed configuration is P4P_REFPID
| * | | 08201de89834f6fecb195c2b7c3546b5cafccc85 seconds kill discount floating layer Style
| | |/
| |/|
| * | 0f4d1df17f79c7aa3ca3d36ab848c10b78029010 Modify Icon
| * | ae719fc29cc550321f284323db06a294b97c1398 P4P Creative Optimization
| |/
| * a6d4501e1456589d30ab1a5800b651876629c8ca modify icon
Git also has a lot of GUI tools that can provide visual branching charts, such as Gitk,qgit,gitx and so on.
Remote Branch

So far, all the previously mentioned concepts have been directly locally operated and do not require any network connectivity.
And git itself is a distributed Code management tool (DVCS), so branch management, there are local branch and remote branch of the two concepts.
It is easy to understand that a remote branch is generated when someone else's local branch is push to the server. For example, Master is the most typical remote branch (default).
$: Git push origin master
In addition to master, we can create branches casually and push them to the server.
$: 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 (delta), reused 0 (Delta 0)
to [email protected]:p Rojects/search.git
1b95a57. 779dbe1 Prepub-Prepub
The remote branch is identified in the form {Remote/branch}, such as 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
Remote and local branches need to be differentiated, so when you pull a specific branch from the server, you need to specify the local branch name.
$: Git branch product origin/product
Branch product set up to track remote Branch product from Origin.
1.6.2 or more versions of Git, you can use the--track option to simplify this process. This is why the local Master branch is created automatically when you execute Git clone directly. (In fact, the pull operation is equivalent to 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"
Remote branches and local branches are loosely structured and can be combined into any local branch by merging any of the remote branches, or you can push any local branch to any remote branch.
# This'll MESS up YOUR repo!!
$: Git branch
Master
* Prepub
P4popt
Product
$: Git pull Origin product
$: Git push origin master
Synchronizes the local remote branch.
$: Git fetch origin
Delete the remote branch.
$: Git push origin:p 4popt
to [email protected]:p Rojects/search.git
-[deleted] P4popt
Add: Git Cherry-pick and git rebase
Git Cherry-pick can choose one or several commits (s) in one branch to operate. For example, suppose we have a stable version of the branch, called V2.0, there is a development version of the Branch v3.0, we can not directly merge two branches, which will lead to stable version confusion, but also want to add a v3.0 in the function to v2.0, here can use Cherry-pick.

# first view the commit ID of the commit to merge in v3.0
git log
# Assuming it's a commit f79b0b1ffe445cab6e531260743fa4e08fb4048b

# cut into the v2.0
Git Check v2.0

# Merge Commit
Git Cherry-pick f79b0b1ffe445cab6e531260743fa4e08fb4048b
Git rebase a bit like git merge, but the two are different, for example, you have two drawers A and B, which are loaded with clothes, now want to put B in a, git merge is the kind of rampage, pick up B into a inside, if full of (conflict) and then tidy up , and Git rebase is very housekeeping, it will be a piece from B to a in addition, according to the beginning of the order of time to add, if full you can deal with this, you can continue to add, or skip this, or do not add, a restore. So merge fits that trivial, simple merge, system-level merge or rebase.

# Merge B
git rebase b

# The conflict continues to merge after processing
Git rebase--continue

# Skip Over
Git rebase--skip

# Cancel Merge
Git rebase--abort

Gerrit Daily Operations Command collection