Miscellaneous notes on using git

Preface

As a developer, if you don't know git or can't use git yet, then you should reflect on yourself. Go read the introduction carefully. Today I will only introduce some common commands I use in daily git and the commands I think are good and can improve our office efficiency. The content may be a bit messy, but they are definitely classic commands. I will take notes here and hope it can help you who come to visit.

area

Before that, let's introduce the three areas of git

• working directory
• Stage index
• Local historical area (history)

Through a picture, you can understand the conversion between them simply and easily.

clone

Let's start with the clone command. Anyone who has used git knows it. The git clone command pulls the remote repository to the local. But when we want to pull it to a specified folder, you may directly mkdir it. In fact, there is no need to do so. One command can get git clone the remote repository file name. It's that simple.

rm

We may encounter such a situation at work. We use git add . to directly add all modified files in the working area to the temporary storage area, but later we find that there is a file that we do not want to add first. At this time, we can use the following command to return the file to the working area.

 git rm --cached <file>  

stash

There is a situation where you are developing and there is an urgent bug that needs to be fixed online. At this time, the function under development is not completed and you don't want to submit it. At this time, you can use git stash to store all the files in the workspace. At this time, you can safely cut branches to fix the bug. After the fix, execute git stash pop to remove the previously stored files. Of course, there are some other related commands, such as git stash list to view the stored records, and git stash drop to discard the stored records.

tag

During development, we may need to tag git tag tagName and push the corresponding tag to the remote repository. At this time, we can use the following command to push.

 git push --tags tagName  

amend

After you commit, you find that a file is not included in the last commit, or some files have been modified. At this time, you do not want to add new commit information, but just want to add it to the last commit. In this case, you can use

 git commit   --amend <file>  

Add the files in the temporary storage area, and you can also modify the commit information at this time.

reset

reset can also achieve the effect of the previous rm. You can use the following command to replace the previous git rm --cached <file> command

 git reset HEAD <file>

But reset is more widely used. Combined with the soft parameter, it can be rolled back to any commit node for operation.

 git reset --soft index  

After executing this command, the system returns to the index, the workspace remains unchanged, and the temporary storage returns to the current index. There is also a hard parameter.

 git reset --hard index  

It can be said to be the opposite of soft. Its effect lies in the difference between the working area and the temporary storage area. It will clear these two areas.

rebase

Rebase means redirection. If there is a difference between your current branch and the remote branch commit information, you will be reminded that you cannot push at this time. You must first pull the remote commit information to the local before you can commit. In this case, you can use the rebase command.

At this time, you should execute the rebase command first

 git fetch  
 git rebase origin/master

After execution, *** push to the remote master

 git push origin master

The final result of each branch is as shown in the figure above. If you find the command difficult to remember, you can also use one command to achieve the above effect.

 git pull --rebase origin master  

This is a simple application of rebase, and it is also a common command. The following is an optional parameter of rebase, --onto.

--onto

Use scenario: During the development process, we will create different branches to develop different functions. When you create a new branch B on branch A to develop functions and submit some commits, you find that there is an erroneous commit on the original branch A. If you want to rebase to master, you cannot attach this erroneous commit. This is when --onto comes into play.

Currently in branch B, to get the above results, just execute the following command

 git rebase --onto master <b's commit hash code> B  

This can be applied not only to different branches, but also to the same branch. So for the above situation, you can only operate on branch B. The equivalent command is as follows:

 git rebase --onto <a's commit hash code> <b's commit hash code> B  

--interactive

When we want to modify the name of the commit information, if the commit to be modified is at the first time, we can use

 git commit   --amend  

If it is not the first time, we have to use the --interactive optional parameter of rebase, which can be abbreviated as -i.

 git rebase -i < commit hash code>

The commit hash code after the parameter is the previous commit that needs to be modified. After execution, a message similar to the following will appear:

 pick 137cf0a First coommit
 pick 163dc38 Second   commit   
 
 # Rebase f9aee6e..163dc38 onto f9aee6e (2 command(s))
 #
 # Commands:
 # p, pick = use commit  
 # r, reword = use commit , but edit the commit message
 # e, edit = use commit , but stop for amending
 # s, squash = use commit , but meld into previous commit  
 # f, fixup = like   "squash" , but discard this commit 's log message
 # x, exec = run command (the rest of the line) using shell
 #
 # These lines can be re-ordered; they are executed from   top   to bottom.
 #
 # If you remove a line here THAT COMMIT WILL BE LOST.
 #
 # However, if you remove everything, the rebase will be aborted.
 #
 # Note that empty commits are commented out  

According to the prompt, we can choose 6 operations. I believe the prompt has made it very clear that for our case of modifying the First coommit, we need to use r.

 r 137cf0a First   commit  
 pick 163dc38 Second   commit  

After execution, you will be redirected to the interface for modifying the First coomit, where you can make modifications.

 First   commit   
 
 # Please enter the commit message for your changes. Lines starting
 # with   '#' will be ignored, and an empty message aborts the commit .
 #
 # Date : Thu Jan 26 23:07:10 2017 +0800
 #
 # rebase in progress; onto f9aee6e
 # You are currently editing a commit while rebasing branch 'master'   on   'f9aee6e' .
 #
 # Changes to be committed :
 # new file: file1

As for other operations, you can try them yourself if you are interested. For example, the s operation can be used to merge commits.

branch

I believe you are all familiar with branch, but here I want to talk about another possible use case of it. The scenario is this: when you create a new branch, you do not want to create a branch from the current commit information node.

To achieve the above effect, just add an additional parameter after creating the branch. This parameter is the hash code of the commit node you need to call.

 git branch new_branch < commit hash code>

push

Here we mention the --set-upstream of push, which has the effect of setting the upstream branch. When we push a local branch that does not exist remotely to the remote, if it is not on the pushed branch, we generally use the following command to push it.

 git checkout push_branch
 git push origin push_branch

The following is a concise method. You can use this parameter without switching branches and push directly using the following command.

 git push --set-upstream origin push_branch  

cherry-pick

The scenario for this command is: when the branch you are in is useless, you want to delete it, but you still want to push one of the commits to the remote master.

Switch the branch to master and execute the following command:

 git cherry-pick <b’s commit hash code>

merge

We all know that we use merge to merge branches. Every time we use merge, the secondary branch will be automatically merged into a commit and pushed to the main branch. If I don't want it to be automatically pushed to the main branch (maybe I still need to modify it), I can use the --squash operation.

 git merge --squash dev_branch  

After executing the above command, we can see a file status that has not been submitted in the temporary storage area.

reflog

When we cut branches too frequently, we may forget which branch some branches are cut from. In this case, we can use the following command to check:

 git reflog

 894a16d HEAD@{0}: commit : commit another todo
 6876e5b HEAD@{1}: checkout: moving from solve_world_hunger to kill_the_batman
 324336a HEAD@{2}: commit : commit todo
 6876e5b HEAD@{3}: checkout: moving from blowup_sun_for_ransom to solve_world_hunger
 6876e5b HEAD@{4}: checkout: moving from kill_the_batman to blowup_sun_for_ransom
 6876e5b HEAD@{5}: checkout: moving from cure_common_cold to kill_the_batman
 6876e5b HEAD@{6}: commit (initial): initial commit  

In this way, we can see the operation history used. In this way, if we accidentally delete something we need using the git reset command, we can use this to find the hash code of the deletion operation, and then we can restore it using the following command.

 git checkout <hash code>

That's all I can think of for now, hope this helps