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

This article introduces the relevant knowledge of "Git workflow and commonly used command arrangement". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

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 the latest.

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

For the index file in the .git directory, the temporary storage area records the information (file name, size, timestamp...) of the file added by git add, does not save the file entity, and points 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, the first 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 latest commit 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.

Git add. Add all files in the current directory to the staging area git add add the specified directory to the staging area, including the subdirectory git add add the specified files to the staging area 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.

Git commit-m submits the temporary storage area to the local warehouse, and message represents the description information git commit-m submits the specified files of the temporary storage area to the local warehouse git commit-- amend-m uses a new commit instead of the last submitted 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.

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 create a new branch, but still stay in the current branch git checkout-b create a new branch, and switch to that branch git branch-- track create a new branch, establish a tracking relationship with the specified remote branch git checkout switch to the specified branch And update the workspace git branch-d delete branch git push origin-- delete delete remote branch

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 out a branch from the master branch, and then develop to complete the requirements, and then go through the commit record of R3Magic R4PowerR5, and finally the development needs to be integrated into master, which uses merge.

Before git fetch merge, pull the latest code of remote warehouse git merge to merge the specified branch to the current branch.

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 finally 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.

Git reset-soft only changes the commit point, and the contents of the staging area and working directory do not change the git reset-mixed. At the same time, the contents of the git reset-hard staging area and the workspace will be modified to the same state as the submission point. Git reset-- hard HEAD makes the workspace return to the state it was when it was last submitted. 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. With regard to this point, those who do not quite understand can read this article.

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.

Git push upload local specified branch to remote warehouse git push-- force forcibly pushes the current branch to the remote warehouse, even if there is a conflict git push-- all pushes all branches to the remote warehouse other commands git status displays changed files git log displays the version history of the current branch git diff displays the differences between the temporary storage area and the workspace git diff HEAD displays the differences between the workspace and the latest commit of the current branch git cherry-pick choose a commit Merge into the current branch of "Git workflow and common command collation" content is introduced here, thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.