Shulou(Shulou.com)06/02 Report--

This article mainly explains the "Git-related knowledge points", the content of the explanation is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "what are the Git-related knowledge points"!

I. Git work flow

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

Workspace: workspace

Index / Stage: temporary storage area

Repository: warehouse area (or local warehouse)

Remote: remote warehouse

Work area

The place where programmers make development changes is what you see right now, and it is also *.

Usually, our development is to copy a branch of the remote warehouse, based on this branch for development. During the development process, it is the operation of the workspace.

Temporary storage area

The index file in the .git directory, and the staging area records the information about the files added by git add (file name, size, timestamp...) Without saving file entities, point to each file entity through id You can use git status to view the status of the staging area. The staging area marks which content in your current workspace is managed by git.

When you complete a requirement or function and need to submit it to the remote repository, then the * * step is to submit it to the temporary storage area through git add and be managed by git.

Local warehouse

Saves the submitted versions of the object, which is older than the contents of the workspace and staging area.

After git commit, synchronize the directory tree of index to the local warehouse, so that it is convenient to synchronize the local warehouse and the remote warehouse through git push.

Remote warehouse

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

Summary

Any object is born and modified in the workspace

Any changes will not be versioned until you enter the index area.

Only when the change is submitted to the local warehouse can the change leave a trace in the warehouse.

Share local changes with collaborators and push them to a remote repository to share.

The following picture more directly describes the relationship between the four regions, some commands may not be very clear, it does not matter, the lower part will be described in detail.

Second, commonly used Git commands

I found a picture on the Internet and a picture sorted out by others. It's all very good. I can borrow it. Some common commands are explained in detail below.

HEAD

Before you master the specific commands, understand HEAD.

HEAD, which always points to the submission point of the current branch. When your branch changes, or a new commit point is generated, the HEAD will change accordingly.

Add

Add-related commands are very simple. The main implementation is to submit the modified contents of the workspace to the temporary storage area, which is managed by git.

Commit

The commit-related command is also very simple, mainly to submit the contents of the temporary storage area to the local warehouse, and to make the HEAD of the current branch move back one submission point.

Branch

When it comes to collaboration, it naturally involves branches, and about branches, there are probably four operations: show branches, switch branches, create branches, and delete branches.

Although there are many operations about 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 up, we may cut a branch from the master branch and then develop to complete the requirements. After the commit record of R3Magic R4PowerR5, * the development needs to be integrated into master, which uses merge.

Generally, after merge, conflict will appear, and you need to manually resolve the conflict according to the conflict situation. This is mainly because two users have modified the same area of the same file. As shown in the following figure, you need to release it manually.

Rebase

Rebase, also known as derivative, is another option for mergers.

In the beginning, we are on the new branch and execute git rebase dev, so the new commit on the new branch repeats itself on the master branch, and the * * checkout switches back to the new branch. This is the same as merge, where the branches have not changed before and after the merger. Git rebase dev, the popular explanation is that the new branch wants to stand on the shoulder of dev and continue. Rebase also needs to resolve conflicts manually.

The difference between rebase and merge

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

Dmurmure test / A---B---C---F master

Execute git merge test in master and get the following result:

Dmure /\ A---B---C---F----G test, master

Execute git rebase test in master and get the following result:

Amura, test, master

As you can see, the merge operation generates a new node, and the previous submissions are displayed separately. Instead of generating new nodes, the rebase operation merges the two branches into a linear commit.

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 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 workspace and staging area accordingly.

Revert

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

The difference between revert and reset

Git revert is used to roll back with a new commit before the commit,git reset is directly deleted from the specified commit.

In the rollback operation, the effect is about the same. But there is a difference when you continue the previous version of merge in the future. Because git revert uses a reverse commit to "neutralize" the previous submission, when merging the old branch later, this part of the change will not occur again, reducing conflicts. However, git reset removes some commit from a branch, so when merge with the old commit again, these rolled-back commit should still be introduced, resulting in a lot of conflicts.

Git reset moves the HEAD backwards, while the git revert is the HEAD to move forward, but the content of the new commit is the opposite of that of the revert, and can counteract the content that is going to be revert.

Push

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

Other commands

Thank you for your reading, the above is the content of "Git-related knowledge points". After the study of this article, I believe you have a deeper understanding of what Git-related knowledge points have, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.