What is a Gerrit?

Gerrit is actually a Git server that provides a set of permission controls for the Git repository hosted on its server, as well as a Web foreground page for Code Review. Of course, its main function is to do Code Review.

How do I configure SSH for Gerrit

1. Run the gitbash command to check whether you have an SSH key: CD ~/.ssh

2. Generate an SSH key:

$ssh-keygen -t rsa -c "Username you want to set"Copy the code

3. After the key is generated, you need to set a password. Press Enter to skip this step

4. Log in to Gerrit and paste the contents of id_rsa.pub in the generated.ssh folder into setting–SSH Public Keys

5. You may also need to add a plain config file to SSH

Please ask your colleague who built gerrit service what configuration needs to be written in the config file. Once done, you can use Gerrit normally.

Daily use of Gerrit

Select “Clone with commit- MSG hook” and “SSH” to obtain the clone address. Open Gitbash for the code download.

After downloading, check whether the commit-msg file has been downloaded successfully. If not, please go to Gerrit to download it and put it in the project directory, as shown below

The commit-msg file is used to automatically generate a unique changeId for each commit.

Git Push origin Head:refs/for/branch Branch is the name of the branch you want to commit to

Possible problems with Gerrit usage

  • Gerrit ensures orderly code commit and review by adding a unique changId to each individual commit. Multiple commits with the same changId are considered as modifications to the same commit. If a commit does not carry a changId, it cannot be pushed. So the first thing to do when a push fails is to check whether the current COMMIT has a ChangID. If the last commit does not have a ChangID, you can use git commit –amend. This command points the last commit to the last one with a ChangID. You can checkout these commits and add changids one by one, or rebase them to the last valid commit and then reedit the commit.

  • If a commit fails because the user information is different from that configured on the Gerrit website, run the git command to check or change the local account:

    To view user name and email address: $git config user.name $git config user.email $git config --global user.name "XXXX" S git config --global user.email "xxxx"Copy the code

    You can also directly modify git configuration files to open the global. Gitconfig file using vi ~/.gitconfig.

  • Note that the “How to save and exit under Vim” question on StackOverflow has received over a million views: Esc exits edit mode, then colon: wq.

The following is the newly reprinted content:

  • Git revokes the COMMIT

Git reset –hard HEAD^

Create three new files: demo1,demo2,demo3

Git reset HEAD demo1 is used to reset the file submitted to the staging area.

In the image above, doing git reset HEAD Demo1 untracked demo1 from the staging area. Now untracked.

Git commit commit

Git commit commits demo2 and demo3 to the local repository.

Git reset –hard HEAD^ git reset –hard HEAD^

In step 3, commit demo2 and then demo3, so now HEAD is the commit value of demo3.

(HEAD refers to the latest commit, the last commit was HEAD^, the last commit was HEAD^^, or HEAD ~ 2, and so on.)

So git reset –hard HEAD means to undo the latest demo3 submission completely and delete the local file.

  • Restore git reset-hard error

Sometimes working with Git is tricky, especially when it comes to more advanced operations like reset, rebase, and merge. Even for small operations, such as deleting a branch, I worry about data loss.

Not so long ago, before I did something grand, I always backed up my entire version repository, just in case. Until recently I discovered that Git’s history is immutable, meaning you can’t change anything that has already happened. Anything you do is just a modification of the original. That is, even if you delete a branch, modify a commit, or force a reset, you can still roll back those actions.

Let’s look at some examples:

$ git init
$ touch foo.txt
$ git add foo.txt
$ git commit -m "initial commit"

$ echo 'new data' >> foo.txt
$ git commit -a -m "more stuff added to foo"
Copy the code

If you look at Git’s history now, you can see two commits:

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit
Copy the code

Now let’s reset the state of the first commit:

$ git reset --hard b7057a9
$ git log
* b7057a9 (HEAD, master) initial commit
Copy the code

It looks like we’ve lost our second submission and there’s no way to get it back. But Reflog is designed to solve that problem. Simply put, it records the history of all heads, which means that when you do a reset, checkout, etc., those operations are recorded in the reflog.

$ git reflog
b7057a9 HEAD@{0}: reset: moving to b7057a9
98abc5a HEAD@{1}: commit: more stuff added to foo
b7057a9 HEAD@{2}: commit (initial): initial commit
Copy the code

So, to retrieve our second commit, just do the following:

$ git reset --hard 98abc5a
Copy the code

Git record:

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit
Copy the code

So, if you lose a commit due to something like reset, you can always get it back, unless your commit has been garbage by Git, usually after 30 days.