GIT

Excerpt from: https://zhuanlan.zhihu.com/p/263050507 (screening)

GitIt is the most advanced **"distributed version control system" in the world , SVNbut a "centralized version control system"**. SVN's version management is centralized on the central server, while Git's version management can be localized.

There are four concepts in Git: "remote warehouse, workspace, staging area, and repository" . The remote warehouse is our Git server, which is used to store the code of the managed team.

The workspace, temporary storage area, and version library are our local ones. For example, after we initialize , a directory git initwill appear under the current directory . "The redis directory is our workspace, and the .git directory is owned by our version library. Version information is here" ..git

The index file ( ) in the .git directory .git/indexis **"temporary storage area" , called stageor index, index is similar to the index of our database, so we sometimes call it "index"**.

The schematic diagrams of these four areas are shown below. Those who have used Git are very familiar with the following commands.

It can be seen from the schematic diagram that the code can be transferred between different levels, and can also be transferred across levels. All these actions are realized through Git commands.

When initializing, Git will automatically create the first branch for us master, and a pointer to the master is called HEAD.

clone project

In our actual working environment, the project will be cloned from the server to the local, and git clonethe command can be used to clone the project in Git:

git clone https://github.com/liduchang/redis

Execution git clonewill generate a copy, which will be synchronized in the local warehouse and workspace. The specific schematic diagram is as follows:

submit code

From the figure above, we can see that the code can move between different levels, from high level to low level, or reversely from low level to high level, or across levels.

The movement of code from low level to high level in Git mainly relies on the following commands:

git add .: The file is added to the temporary storage area.
git commit -m "提交信息": The file is added to the local warehouse, and the -m parameter is changed to -am to push it directly to the local warehouse.
git push: The file is pushed to the remote warehouse.

Running git commit -ais equivalent to running git addto add all files to the temporary storage area, and then running git committo submit the files to the local warehouse.

code fallback

Then the command to move code from high level to low level is as follows:

git pull: Pull the code from the remote warehouse to the local.
git reset --files: Overwrite the modification in the temporary storage area with the local warehouse, that is, overwrite the content of the last git add.
git checkout --files: Copy the file from the temporary storage area to the work area to discard the local modification.
git checkout HEAD --files: Roll back the last submission.

code conflict

When collectively using Git in the team, everyone submits their own code and finally merges it into the trunk. There will always be push failures, because the nature of push: "It is to use the commit record of your local warehouse to overwrite the commit record of the remote warehouse . " .

But someone else submitted some code, and you don't have this code locally, so the code will be overwritten, resulting in no record of other people's commit, which is absolutely not allowed.

Therefore, Git will check every time you push. If this situation exists, the push fails. Just git pull first, merge the local warehouse with the remote warehouse, and finally push will succeed. If the file already exists in For conflicting codes, just open the file and resolve the conflict again.

branch management

The most important point in Git is the concept of branches. With branches, there are merge and rebase operations. "Merge" and "rebase" can "effectively manage code versions" .

In the initialization of Git, there is a default main branch called master, and each commit will be strung together into a timeline, which is a branch, and the current branch is HEADpointed by a pointer:

GIF cover

Every time a code commit occurs, the current point will form a new version forward. If a new branch bran is created, and the current commit points to the new branch, the new branch will be updated over time. Form many versions:

When the new branch is developed, submit the warehouse and merge it into the trunk master, and finally delete the bran branch, thus completing a personal development:

Therefore, if only one branch is created on the main branch, the branch merging is very fast. You only need to move the master branch to the current submission, then point the HEAD pointer to the master, and finally delete the bran branch to complete.

However, this is not the case in fact. In a multi-person collaborative development team, each person often creates his own branch, has his own submission, and finally merges it into the trunk. When he submits himself, the remote warehouse code will exist. Code that does not exist in your own local warehouse, which will cause push to fail.

For example: Programmers Tom and Jerry moved out of the code at the same time, and their initial code branches are as shown in the following figure:

When Tom develops his own business module, submits the code and merges it into the trunk, the remote trunk branch is shown in the figure below:

"The remote warehouse master no longer points to gs234, but a new version dfd453 is generated as the currently pointed version . "

At the same time, after Jerry's local has also developed its own module, the branch is shown in the figure below:

branIn Jerry's local environment, his **"local warehouse master still points to gs234"**, Jerry develops in a newly created branch , merges the branch after development, and finally masterpoints to it ed489.

When Jerry submits the code again, Git will check the remote warehouse and Jerry's local warehouse. After comparing, it is found that the remote warehouse has code that does not exist in Jerry's local warehouse. Jerry needs to execute the remote warehouse and resolve the conflict by itself git pull.

The above mentioned the basic principles of branching, and the problems that have occurred in the management of branches. Next, we will go into the basic commands of operating branches step by step.

new branch

The command for Git to create a new branch is: git branch <分支名字>, and after the new branch is created, the command to switch branches is: git checkout <分支名字>.

The essence of creating a new branch: "It is to create a new reference pointing to the current submission, and the master is like a reference" ; the essence of switching branches: it is HEADto redirect the reference pointing to the original reference to the reference of the branch to be switched:

Of course, the above two commands for creating branches and merging branches can be combined into one command:git checkout -b <分支名字>

After switching points, the HEAD pointer will move along with the new bran branch every time the commit code is submitted, forming each version on the bran branch:

If a certain version is developed on the new bran branch, switching back to the master branch for development will form a fork:

view branch

When the branch is created, you can git branchcheck your local branch by:

Branches with an * in front of them represent the current branch. After viewing the score, you can clearly know which branch you want to checkout.

merge branch

After developing and playing with your own module, you will merge branches locally later. The command to merge branches: , git merge <分支名字>which means **“merge the specified branch into the current branch”**, for example: the current branch is master, execute: , which git merge branmeans merge bran branch to the current master branch.

Branch merging will also fail. When your two branches modify the same file, Git will not be able to determine which modification you want to keep, and a merge conflict will appear.

For example: I first mastermodify the README.md file in the branch, and then submit the local warehouse:

Then switch back to branch dev, modify the README.md file again, and submit again

Finally, merge the branch. At this time, the conflicting code of the two modifications will appear in the README.md file you modified twice:

Because you modify the operation of the same file twice, Git does not know which operation you want to keep after merging, so it will leave this decision to you to decide, it only tells you where the code in the file conflicts, specifically How to change it is up to you.

delete branch

Finally, delete the branch you created by yourself. git branch -d <分支名字>Delete the branch through: . If the branch cannot be deleted, you can git branch -D <分支名字>force delete the branch through: :

The essence of deleting a branch in Git: dev is just a reference to a branch, so deleting a branch means deleting this reference, and will not delete any commit, so the deletion operation is also very efficient.

If the reference to a branch commit is deleted, then there is no reference to this branch, so this branch will not be found, and will be recycled by the Git recycling mechanism.

view remote

In a multi-person collaborative team, you may want to check the status of the remote warehouse at any time. You can check it through: git remote, and add the -v parameter to check the details of the remote warehouse.

git remote
git remote -v

push branch

Pushing the branch to the remote has been mentioned in the previous section. The branch can be pushed by using the git push command. The branch command is added after the command to indicate which branch to push:

git push origin master // 将本地master分支推送到远程库

pull branch

The pull of the branch uses the git pull command, which is equivalent to the following two commands:

git fetch
git merge

But in general practice, you may use the git pull command directly:

branch management strategy

When merging branches, Git will merge in the fast merge mode (Fast forward), but after this mode deletes the branch, the information of the branch will be lost.

Git can also merge in **"normal mode"**, just add the –no-ff parameter after the original git merge command, the merge command is as follows:

$ git merge --no-ff -m "message" dev

Temporary Access Workspace Changes

During development, if at some point you want to temporarily store the current changes, you can use git stashthe command, which means that the changed files will be stored in an independent storage area, and will not be submitted, and can be used at any time when needed again take out.

The thing to note here is: "git stash is the changed file, that is, the file tracked by Git. The newly added file is not tracked by Git, so git stash will not stash" .

The git stash command can also be added with the save command followed by remark information for easy viewing:

git stash save "备注信息"

git stashAfter success **“The code of the local working directory will be the same as the local warehouse”**, you git stashcan use git stash listthe command to view the history of the previous stash. When you need to take out the changed file again, you can use the following command:

git stash pop

git stash popMeans **"Pop up the first stashed record, and the stash will be deleted from the history" ; you can also use git stash applythe command "Pop up the stash, but the stash of this command will still be saved in the stash history"**, You can also use the : git stash dropcommand to delete.

This article only explains Git's branching principle and Git's temporary access operations. Due to space limitations, we will stop here today. We will continue to illustrate Git operations in the next issue. See you in the next issue.

In this article, we continue to illustrate Git. The previous two original illustrations illustrated the basic operations of Git. If you are interested, you can take a look at [] and [].

After writing the basic Git operation in this article, the diagram is over. If you want to learn more about Git, here are some Git hardcore books: [Proficient in Git], [GitHub Getting Started and Practice], [Git Authoritative Guide], [Git Version Control Management], [GitHub Practice].

…(img-mUC6O40i-1684305577842)]