Git is no longer afraid of poor memory.

What is git?
Git is a distributed code management container. The same code is stored locally and remotely. The GIT repository is mainly composed of three parts: Local Code, cache area, and commit history. This is the essence of almost all operations. But for the sake of simplicity and ease of understanding, the GIT repository does not focus on this part, if you are interested, you can find out. Let's talk about common git operations.

What general operations does git have?
Let's briefly talk about the general operations of git that allow us to cope with simple development needs.

Clone code

? Clone remote code

Git clone + Remote library address
? View local code status

// You can clearly present the status of the local repository // which files have been changed, which files have been submitted to the local machine // and some operation instructions. Git status

? Synchronize remote branch changes

// Pull the changes of the specified branch git fetch origin master // pull the changes of all branches git fetch // pull the changes of all branches, remove the branch that does not exist in the remote end synchronously. [recommended] git fetch-P

? Synchronize remote code changes.

// Git fetch first, and then merge. // The difference is that git pull executes git merge, git pull-r executes git rebasegit pull origin master git pull-r origin master.

The advantages and disadvantages of git merge and git rebase are described in detail later.

This section describes how to clone code and synchronize remote code changes. Next, let's take a look at some operations on the local code.

Operation commit

First, we need to clarify the concept that each commit is a complete code state and uses a commitid as the unique identifier.

Git is no longer afraid of poor memory.
Small Java entrepreneurs
What is git?
Git is a distributed code management container. The same code is stored locally and remotely. The GIT repository is mainly composed of three parts: Local Code, cache area, and commit history. This is the essence of almost all operations. But for the sake of simplicity and ease of understanding, the GIT repository does not focus on this part, if you are interested, you can find out. Let's talk about common git operations.

What general operations does git have?
Let's briefly talk about the general operations of git that allow us to cope with simple development needs.

Clone code

? Clone remote code

Git clone + Remote library address
? View local code status

// The local repository status can be clearly displayed.
// Which files have been modified and submitted to the Local Machine
// And some operation instructions.
Git status

? Synchronize remote branch changes

// Pull the changes of the specified Branch
Git fetch origin master
// Pull the changes of all branches
Git fetch
// Pull the changes of all branches and remove the branches that do not exist on the remote end. [recommended]
Git fetch-P
? Synchronize remote code changes.

// Both are first git fetch and then merge
// The difference is that git pull executes git merge and git pull-r executes git rebase.
Git pull origin master
Git pull-r origin master
The advantages and disadvantages of git merge and git rebase are described in detail later.

This section describes how to clone code and synchronize remote code changes. Next, let's take a look at some operations on the local code.

Operation commit

First, we need to clarify the concept that each commit is a complete code state and uses a commitid as the unique identifier.

From a certain point of view, git maintains a commitid tree that stores code in different States. Therefore, any modification to the code will eventually be reflected on the commit.

? New commit

// Add the file to the cache, and then submit it to the local repository git add filesgit commit-m' submit remarks'

? Undo commit

// Roll back the submission records, code does not roll back git reset b14bb52 // It will roll back all commit records and code git reset -- hard b14bb52 // roll back some code files git checkout -- files

? Merge commit and commit. In essence, merge two codes in different States.

// Git provides two methods to merge commit: git merge mastergit rebase master ''' ** what is the difference between git rebase and git merge? Merge adds a new commit to the master after two branches conflict with each other. Rebase appends the commit record on the somefeature branch to the master branch. It is worth noting that his commit has actually changed at this time .! [] (Http://i2.51cto.com/images/blog/201810/28/1723859bcd9d6581125873c45e2fd4ca.png? X-OSS-process = image/watermark, size_16, conflict, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, conflict =) Relatively speaking, git merge handles conflicts more directly, git rebase ensures clear commit records. When merging commit, a conflict usually occurs. You can globally search for special characters such as <, locate the location of the Code to be processed, and carefully analyze which part of the Code should be retained .! [] (Http://i2.51cto.com/images/blog/201810/28/3f2baaccf186da4a8593916ec18a080e.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) in team collaboration, branch is essential. So how should we operate on the branch? ** Operation Branch ** the so-called branch is actually a pointer to commitid. You can go to. Git/refs/heads to see it .! [] (Http://i2.51cto.com/images/blog/201810/28/203d808a77528a1fe65564c44125bc3d.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) generally, we recommend that the branch should at least clearly mark the function name. It is better to mark the user, such as qixiu/feature .? View branch! [] (Http://i2.51cto.com/images/blog/201810/28/1ef036a49e4188ed33419bb51ee26e66.png? X-OSS-process = image/watermark, size_16, clerk, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) the local branch and remote branch can be viewed simultaneously, with the GIT fetch-P introduced in the previous article, you can view the latest branch information immediately .? To add a local branch, create a pointer pointing to a commitid.

// Git branch qixiu/feature + git checkout qixiu/feature
// Add a new branch qixiu/feature from the current Branch
// In general, we should add branches from the master or other stable branches.
Git checkout-B qixiu/feature // create a branch
Git checkout qixiu/feature // switch Branch

? Deleting a local branch is actually removing a pointer to commitid.

// Delete the local branch. If there is any unmerged code in the local branch, it cannot be deleted.
Git branch-D qixiu/feature
// Force Delete the local branch
Git branch-D qixiu/feature

? To add a remote branch, we usually create a local branch, and then update it to the remote side to add a remote branch 'git push origin qixiu/feature '? Delete a remote branch. We also delete a remote branch by updating it to the remote end.

// Equivalent to git push origin-D qixiu/feaure
Git push origin: qixiu/feature

A brief summary of the above mentioned operations may be scattered. Here we will briefly summarize the frequently used operations:

Git status // view the local code status
Git add files // Add code to the cache
Git commit-m' remarks of submitted content '// submit code to the local repository
Git checkout-B branchname // without-B, it is a normal switch Branch
Git fetch-P // synchronize the remote branch status
Git pull-r origin branchname // fetch remote code to local, and the code is merged as rebase
Git push origin branchname // update local code to the remote end

The above commands can cope with daily operations. In a slightly complex scenario, I will introduce the basic operations. In actual projects, how should we use git for collaboration? What are the best practices of git? Git has some mature development processes, and there are two mainstream ones: the development process based on the function Branch and the gitflow development process. In comparison, I recommend the former. For complex large projects, the gitflow development process is recommended. Next, we will briefly introduce the two collaboration modes. ** Collaboration mode based on function branches ** the development process based on function branches is actually one sentence: Use branches to carry function development, and merge them to the master branch after development. Its advantage is that it can ensure that the master branch is clean and tidy, and also make the branch code logic centralized, so as to facilitate codereview. The following format is recommended for ** branch naming rules **: ownername/featurename. In this way, it is easy to know the branch coverage function and find the branch owner. It will be convenient to clean up branches in the future. ** Development process **? Cut a new branch from the master, 'git checkout-B qixiu/newfeature '? Develop some new functions, and then submit code to the local repository more frequently, so that you can save or cancel changes more flexibly. In addition, to ensure that the submitted logs are clear, we recommend that you note clearly.

Git status
Git add files // select the files to be submitted, or submit them all
Git commit-m' submit remarks'
Git push origin qixiu/newfeature

? If function development is complete, can you initiate a codereview process? If the code passes the test, merge the code to the master and then prepare to go online.

// Merge redundant versions to the master
Git checkout master
Git pull-r origin master
Git checkout qixiu/newfeature
Git rebase master // handle conflicts
Git checkout master
Git merge qixiu/newfeature
Git push origin master
// Merge the lite version into the master
Git checkout qixiu/newfeature
Git pull-r origin master // updates the master code and rebase handles conflicts.
Git push origin master // update local code to the remote end

Note: It is important not to merge code on the master to ensure the availability of the master. Make sure that the operation is performed correctly in the correct branch. Whether it is dealing with conflicts or updating remote code, please be in awe. By now, a normal function branch-based development process has been completed. Next, let's look at another development process. ** Gitflow development process ** gitflow is much more complex than the function branch-based development process mentioned above. It is more suitable for large-scale and complex projects. It defines a strict branch model around the project release process, and all development processes are centered around this strict branch model. This model defines the roles of each branch and how they communicate. Let's take a look at several agreed branches in the gitflow development process and their respective roles ?! [] (Http://i2.51cto.com/images/blog/201810/28/35de170094692927545bf83a0663e203.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk = )? Master branch: used to store online version code, which can be used to conveniently provide version numbers for the code.? Develop branch: used to integrate the feature branch.? Feature branch: The branch of a function that is cut out from the develop branch and merged back to the develop branch when the function is completed. It does not directly interact with the master branch.? Release branch: usually corresponds to an iteration. After all functions of a version are merged into the develop branch, a release branch is cut out from the develop branch. This branch does not add new requirements, so it can fix bugs and improve documents. Remember that after the code is published, it needs to be merged to the master branch and also to the develop branch.? Hotfix branch: the branch for urgent repair. It is the only branch that can be switched out from the Master. Once repaired, it can be merged into the master Branch and the develop branch. It can be seen from the functions and conventions of each branch that the process has many constraints and is not suitable for small-scale applications. Of course, gitflow has some auxiliary tools gitflow can automate these tasks, which is also helpful for large projects. The following describes the basic operations of git and the two major workflows. Next, let's take a look at some special tips for git. ** What tips does git have? ** In addition to the basic code management functions, GIT also provides some tips to highlight your skills. Git reflog. To view the operation records, I must first introduce it because it has helped my code several times! [] (Http://i2.51cto.com/images/blog/201810/28/c6e8353586ed35209f30c84095c61f25.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) Check carefully, reflog records all your git command operations, which can be of great help to restore some inexplicable scenarios or roll-back misoperations. Imagine a scenario: You use git reset -- hard commitid to roll back the local development code to a previous version, and haven't pushed it to the far end. How can you retrieve the lost code? If you use git log to view the commit log, you cannot retrieve the discarded commitid. Git reflog records the commitid of each of your operations in detail, so that you can easily restore the current operation and retrieve the lost code. Of course, if none of your lost code has been submitted, congratulations! Your code is really lost. ** Compression and submission records ** are also a very useful feature. As mentioned above, we try to maintain a high frequency of code submission during development, this prevents accidental code loss. But when we merge code, we do not want to have too many redundant commit records. When rebase merges Code, every commit will be processed, sometimes causing redundant work. Therefore, after the logs are compressed, The commit record cannot be kept clean, and the rebase code can also be used to merge the logs. So how can we compress commit records?? Use git log to find the starting commitid? Git reset commitid. Do not use the -- hard parameter? Git add again & git commit? Git push-F origin branchname, because there is a conflict, so you need to forcibly overwrite the remote branch, please be careful.? Merge to the master, and then update the remote master. There are also two ways to compress logs: git commit -- Amend: append the commit to the previous commit. Git rebase-I: Provides control over Branch commit through interactive rebase, which can clear chaotic history .! [] (Http://i2.51cto.com/images/blog/201810/28/1a31b276a6b82e2ddf7585caa73b71d1.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) in actual applications, the three types of log compression are excellent, git reset is simpler, and git rebase-I is more delicate. ** Git rebase and merge code ** the previous article briefly introduced the differences between git rebase and git merge. Frankly speaking, they have their own advantages and disadvantages. Git rebase makes your commit record clean and easy, whether online rollback or codereview. However, it is a risky operation, so be cautious when using it. Git merge operations are safer and easier, but some redundant commit records are added. Let's briefly talk about the rebase merging process and precautions. Look! [] (Http://i2.51cto.com/images/blog/201810/28/051c1cab863516abb6db9eee3bb952cd.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) There are three points to note :? How does rebase first find common ancestor nodes? The slave node removes the commit record of the pay branch and rebase it to the master branch? The commitid after rebase has actually changed, especially the third point, which often causes misoperations, so be sure to pay attention to it. Imagine what will happen if we frequently rebase master branches during the development process ?! [] (Http://i2.51cto.com/images/blog/201810/28/d29bed882ea72ebf82046b94388521fa.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) When you constantly rebase the master, in fact, your local D is changed to d', and it must be consistent with the remote pay branch. Your local branch commit record is already unsightly. In addition, do not use rebase on public branches !!!! [] (Http://i2.51cto.com/images/blog/201810/28/bb847e185eeff61c56513328789aa5a8.png? X-OSS-process = image/watermark, size_16, clerk, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, clerk =). To ensure security, the team may consider using merge. ** Pull request to facilitate codereview ** git not only provides code hosting and code development assistance, but also provides similar features for code review. After the function branch is developed, You can initiate a pull request and select the two branches to be compared! [] (Http://i2.51cto.com/images/blog/201810/28/d24658b2c8eaebd0fa1d5754ec99f77b.png? X-OSS-process = image/watermark, size_16, expires, color_ffffff, t_100, g_se, x_10, y_10, shadow_90, type_zmfuz3pozw5nagvpdgk =) it will create a pull request, develop relevant personnel to review the code. In general, the team should encourage cross-review. When public code is involved, review should be made for relevant persons. ** Git hook, git Life Cycle ** most people should have heard that git operations have their own life cycles in different life cycles, we can do some automation. Here are two simple examples :? When pre-commit is used, can we do eslint? During post-commit, we can use tools similar to Jenkins for continuous integration. Of course, there are more declaration cycles. For details, refer to git hook git submodule & git subtree, manage third-party modules these two commands are usually used to manage public third-party modules. For example, some general underlying logic, middleware, and some common business components that may change frequently. Of course, there is a difference between the two. Git submodule is mainly used to manage some public modules or underlying logic for one-way updates. Git subtree is particularly suitable for management of reusable logic that requires two-way updates. For example, some business component code that needs to be reused. In my previous practices, I also used Subtrees to manage building system logic. ** Git alias: simplify git commands ** you can simplify the GIT commands that need to be entered by configuring git alias. For example, if the previous git subtree requires a long git command, we can configure the. Git/config file. // Git stpull appfe demo/xxx // git stpush appfe demo/XXX [alias] stpull =! Git subtree pull -- prefix = $1 appfe $2 &: stpush =! Git subtree pull -- prefix = $1 appfe $2 & git subtree split -- rejoin -- prefix = $1 $2 & git subtree push -- prefix = $1 appfe $2 &&: ** what is the summary? ** This document first introduces general git operations? This includes code cloning, commit operations, and branch operations. In fact, there are not many general git operation commands. Please refer to the summary in the first part. What is the GIT development process? This section mainly introduces two mainstream development modes: lightweight function branch-based development process and gitflow development process suitable for complex projects. The two modes have their own use scenarios, for general use, the former is enough. Finally, I introduced some practical git skills? It mainly includes reflog operations, log compression, rebase precautions, codereview using pull request, and automation using git hook.

Git is no longer afraid of poor memory.