Read git in one article

In daily work, Git operations are often used. But for newcomers, I was new to Git when I first came up, and the operation was also very awkward. This article is mainly aimed at newcomers who are just beginning to get in touch with Git, understand the basic principles of Git, and master some commonly used commands.

One, Git workflow

The above includes some simple and commonly used commands, but don't care about these first, let's first understand the following 4 proper nouns.

Workspace: Workspace
Index / Stage: Temporary storage area
Repository: Warehouse area (or local warehouse)
Remote: remote warehouse

Work area

The development changes made by the programmers are what you currently see and are also the latest.

Usually our development is to copy a branch in a remote warehouse and develop based on that branch. In the development process is the operation of the workspace.

storage cache

In the index file under the .git directory, the temporary storage area will record git addthe relevant information (file name, size, timestamp...) of the added file, and does not save the file entity, and points to each file entity by id. You can use to git statusview the status of the staging area. The staging area marks what content in your current workspace is managed by git.

When you need to submit to a remote warehouse after completing a certain requirement or function, then the first step is git addto be managed by git by submitting it to the staging area first.

Local warehouse

Save the submitted versions of the object, which is older than the contents of the work area and temporary storage area.

git commitAfter synchronizing the index tree to the local warehouse, it is convenient to git pushsynchronize the local warehouse and the remote warehouse from the next step .

Remote warehouse

The content of a remote warehouse may be modified by local warehouses in a collaborative relationship distributed in multiple locations. Therefore, it may be synchronized with the local warehouse or may not be synchronized, but its content is the oldest.

summary

Any object is born and modified in the workspace;
Any modification is version controlled after entering the index area;
Only by submitting the modification to the local warehouse can the modification leave a trace in the warehouse;
Share local changes with collaborators, and push them to remote warehouses for sharing.

The following picture more directly explains the relationship between the four areas, some commands may not be clear, it does not matter, the next part will introduce in detail.

Two, commonly used Git commands

I found a picture on the Internet, and a picture compiled by someone else is very good. I can borrow it. Some common commands are explained in detail below.

HEAD

Before grasping the specific commands, understand HEAD first.

HEAD, it always points to the latest commit point of the current branch. If the branch you are on changes, or a new commit point is generated, HEAD will change accordingly.

add

The add-related commands are very simple, and mainly realize that the modified content of the workspace is submitted to the temporary storage area and managed by git.

git add .	Add all files in the current directory to the temporary storage area
git add <dir>	Add the specified directory to the temporary storage area, including subdirectories
git add <file1>	Add the specified file to the staging area

commit

Commit related commands are also very simple. They mainly implement the submission of the contents of the temporary storage area to the local warehouse and make the HEAD of the current branch move backward by one commit point.

git commit -m <message>	Submit the temporary storage area to the local warehouse, and message represents the information
git commit <file1> -m <message>	Submit the specified files in the temporary storage area to the local warehouse
git commit --amend -m <message>	Use a new commit to replace the previous commit

branch

When it comes to collaboration, branches are naturally involved. Regarding branches, there are probably four operations: display branches, switch branches, create branches, and delete branches.

git branch	List all local branches
git branch -r	List all remote branches
git branch -a	List all local branches and remote branches
git branch <branch-name>	Create a new branch, but still stay in the current branch
git checkout -b <branch-name>	Create a new branch and switch to that branch
git branch --track <branch><remote-branch>	Create a new branch and establish a tracking relationship with the specified remote branch
git checkout <branch-name>	Switch to the specified branch and update the workspace
git branch -d <branch-name>	Delete branch
git push origin --delete <branch-name>	Delete remote branch

Although there are many operations on branches, they are relatively simple and easy to remember.

merge

The merge command merges different branches. As shown in the figure above, in the actual opening, we may cut a branch from the master branch, and then develop to complete the requirements. In the middle, the commit records of R3, R4, R5 are passed, and finally the development is completed and needs to be merged into the master. This uses merge .

git fetch <remote>	Pull the latest code of the remote warehouse before merge
git merge <branch>	Merge the specified branch to the current branch

Generally, conflict will appear after the merge, and you need to manually resolve the conflict in response to the conflict. Mainly because two users modified the same area of the same file. As shown in the figure below, it needs to be released manually.

rebase

Rebase, also known as rebase, is another option for merging.

At the beginning, we are on the new branch and execute git rebase dev, then the new commits on the new branch will be repeated on the master branch, and finally the checkout will switch back to the new branch. This is the same as merge. The branch before and after the merge has not changed. git rebase dev, The popular explanation is that the new branch wants to stand on the shoulders of dev to continue. Rebase also requires manual conflict resolution.

The difference between rebase and merge

Now we have such two branches, test and master, submitted as follows:

      D---E test     /A---B---C---F master

Execute in the master git merge test, and then get the following results:

      D--------E     /          \A---B---C---F----G   test, master

Execute in the master git rebase test, and then get the following results:

A---B---D---E---C'---F'   test, master

As you can see, the merge operation will generate a new node, and the previous submissions will be displayed separately. The rebase operation does not generate new nodes, but merges the two branches into a linear submission.

If you want a clean, linear history tree without merge commit, then you should choose git rebase.
If you want to keep a complete history and want to avoid the risk of rewriting commit history, you should choose to use git merge

reset

The reset command points the current branch to another location, and changes the work area and temporary storage area accordingly.

git reset —soft <commit>	Only the commit point is changed, and the contents of the temporary storage area and the working directory are not changed
git reset —mixed <commit>	Change the commit point and change the content of the temporary storage area at the same time
git reset —hard <commit>	The contents of the temporary storage area and work area will be modified to the state exactly the same as the submission point
git reset --hard HEAD	Return the workspace to the state it was in when it was last submitted

revert

git revert uses a new commit to eliminate any changes made by a historical commit.

The difference between revert and reset

Git revert uses a new commit to roll back the previous commit, and git reset directly deletes the specified commit.
Looking at the operation of rollback, the effect is similar. But there is a difference when you continue to merge the old version in the future. Because git revert uses a reverse commit to "neutralize" the previous submission, when the old branch is merged in the future, this part of the change will not appear again, reducing conflicts. But git reset deletes some commits on a certain branch, so when it merges with the old branch again, these rolled back commits should still be introduced, causing many conflicts. Regarding this point, you can read this article if you don't understand.
Git reset moves the HEAD back a bit, while git revert moves the HEAD forward, but the content of the new commit is the opposite of the content to be reverted, which can offset the content to be reverted.

push

Upload the local warehouse branch to the remote warehouse branch for synchronization.

git push <remote><branch>	Upload the local designated branch to the remote warehouse
git push <remote> --force	Forcibly push the current branch to the remote warehouse, even if there is a conflict
git push <remote> --all	Push all branches to the remote warehouse

Other commands

git status	Show changed files
git log	Display the version history of the current branch
git diff	Show the difference between staging area and work area
git diff HEAD	Show the difference between the workspace and the latest commit of the current branch
git cherry-pick <commit>	Choose a commit and merge into the current branch

The above are some common commands and detailed explanations about Git. I believe I can have a preliminary understanding of Git.