The essence of Git’s instructions, really easy to understand ah

preface

Git is the most powerful code management tool in the world, but as far as I know, a large number of people are stuck in clone, commit, pull, push… If you don’t know what rebase is, you can only use merge. Catch a version rollback? Don’t ask me how I know. Just ask: “I used to be like this.” In view of these problems, today I will share the cognition and understanding of Git in the past few years, as far as possible to explain Git from the essence, help you to understand the underlying principle of Git step by step, I believe that after reading this article you can change posture, more snass to use Git various instructions.

directory

• 1. Basic concepts
  • 1.1 Advantages of Git
  • 1.2 File Status
  • 1.3 commit node
  • 1.4 the HEAD
  • 1.5 Remote Warehouse
• Branch of 2.
  • 2.1 What is a branch?
• 3. Command detail
  • 3.1 Submission
  • 3.2 Branch correlation
  • 3.3 Merging related
  • 3.4 Rollback Related
  • 3.5 Remote Correlation

1. Basic concepts

1.1 Advantages of Git

Git is a distributed code management tool. Before discussing distribution, it is necessary to mention what is a central code management repository

• Centralization: All code is stored on a central server, so commits must be networked, and each commit is brought into a central repository. Collaborative development can frequently trigger code merges, increasing the cost and cost of commits. The most typical example is SVN
• Distributed: The submission can be made locally without relying on the network, and each submission will be automatically backed up to the local server. Each developer will be able to clone a copy of the remote repository locally, along with the submission history. That stands for Git

What are the advantages of Git over SVN? For example, “barak barak wrote a lot of code, suddenly found that there is a problem, I want to go back to an hour before”, in this case the Git advantage is very obvious, the relatively small, because the cost of the commit and local will keep records of all submitted, with time can be back at any time. This is not to say that SVN can’t do this, but Git will be more elegant. Git has many advantages over central tools. I will not list them all, but you can learn about them if you are interested.

1.2 File Status

There are roughly three states of files in Git: modified, Staged, and Committed.

• Modification: Git can sense which files in the working directory have been modified and add them to the modified field
• Staging: Use the add command to commit the modified files in the working directory to the staging area for the commit
• Commit: Save the staging file commit to the Git directory permanently

1.3 commit node

For the sake of presentation, I’ll use the node name commit in this article

In Git, a node will be generated for each commit, and each node will have a hash value as a unique identifier, and a linear node chain will be formed by repeated fetching (without considering merge), as shown in Figure 1-1

Above the node is the hash calculated by SHA1

Node C2 contains content submitted by C1, and node C3 contains content submitted by C1 and C2

1.4 the HEAD

HEAD is a very important Git concept. You can call it a pointer or a reference. It can point to any node, and it always points to the current working directory.

Using figure 1-1 as an example, if HEAD points to C2, then the working directory corresponds to the C2 node. We’ll talk about how to move the HEAD point, but don’t worry about it.

HEAD can also point to a branch, indirectly pointing to the node to which the branch refers

1.5 Remote Warehouse

Although Git keeps the code and history locally, it ultimately commits to a remote repository on the server. Using the Clone command, you can download the code from the remote repository to the local, and synchronize the commit history, branch, HEAD, and other states to the local. However, these states are not updated in real time, and need to be manually pulled from the remote repository. When and how to pull will be discussed in the following sections.

With the remote repository as an intermediary, you can collaborate with your colleagues to develop new features and submit them to the remote repository. You can also pull your colleagues’ code from the remote repository.

Pay attention to the point

Since you and your colleagues will be benchmarking against the code in the remote repository, always ensure that the code in the remote repository is of good quality, and never submit code to the remote repository that has not been inspected and tested

Branch of 2.

2.1 What is a branch?

Branch is also an important concept in Git. When a branch points to a node, the contents of the current node are the contents of the branch. The concept of branch is very close to HEAD and can also be regarded as a pointer or reference. Branches are usually established based on functionality or version

So what’s the use of a branch?

• Here’s an example: Your App has gone through a lot and finally releasedv1.0Version, due to urgent demandv1.0It’s been non-stop since we got onlinev1.1Just as you were developing, QA said that users had reported some bugs that needed to be fixed and then redistributed and fixedv1.0It must be based onv1.0But you’ve already developed some of itv1.1How to make at this time?

The above problem can be solved elegantly by introducing the concept of branching, as shown in Figure 2-1

• So let’s look at the diagram on the leftC2The node isv1.0Version code, after going online atC2Create a new branch based onFt - 1.0 -
• Look at the diagram on the rightv1.0It will be available atmasterBranch developmentv1.1Content to be submitted after receiving feedback from QA studentsv1.1Code generation nodeC3And then switch toFt - 1.0 -The branch does bug fixes and commits the code generation node when the fixes are completeC4And then switch tomasterBranch and mergeFt - 1.0 -Branch, so we’ve solved the problem

In addition, branches can also be used to do a lot of things. For example, if there is a requirement that is uncertain whether to go online, it must be done first. At this time, you can create a separate branch to develop this function, and when it needs to go online, you can directly merge it into the main branch. Branches apply to a lot of scenarios are not a list.

Pay attention to the point

When a branch is created on a node, the code corresponding to the node is not copied, but the new branch is pointed to the node, thus greatly reducing the space overhead. It’s important to remember that whether it’s a HEAD or a branch they’re just references, they’re very light

3. Command detail

3.1 Submission

As mentioned earlier, to commit code, you must first add it to the temporary store, which is done with Git using the add command

To add a file to the staging area:

Git add file pathCopy the code

Add all files to staging area:

git add .
Copy the code

Git also provides commands to undo workspaces and staging areas

Undo workspace changes:

Git checkout -- file nameCopy the code

To clear the staging area:

Git reset HEAD NameCopy the code

Commit:

After adding the changed files to the staging area, you can submit. After submitting, a new submission node will be generated. The specific command is as follows:

Git commit -m "Description of this object"Copy the code

3.2 Branch correlation

Create a branch

When you create a branch, the branch will point to the same node as the HEAD.

Git Branch NameCopy the code

Switch branch

When the branch is switched, by default HEAD points to the current branch, that is, HEAD indirectly points to the node to which the current branch points

Git Checkout branch nameCopy the code

You can also create a branch and immediately switch, using the following command:

Git checkout -b Branch nameCopy the code

Delete the branch

To keep warehouse branches concise, a branch should be removed when it has done its job. For example, as mentioned earlier, open a branch to complete a function, when the function is merged into the main branch should be deleted in time.

The delete command is as follows:

Git branch -d Specifies the name of a branchCopy the code

3.3 Merging related

The merge command is the hardest to master and the most important. Merge, rebase, and Cherry-pick are three common merge commands

merge

Merge is the most common merge command that merges code from a branch or node into the current branch. The command is as follows:

Git merge branch name/node hashCopy the code

If the branch to be merged is completely ahead of the current branch, as shown in Figure 3-1

Because branch FT-1 is completely ahead of branch FT-2, that is, ft-1 completely contains FT-2, ft-2 triggers a fast forward after “Git merge ft-1”. In this case, the two branches point to the same node, which is the ideal state. But in actual development, we often encounter the following situation: Figure 3-2(left)

In this case, it cannot be directly closed. When FT-2 executes “git merge ft-1”, Git will merge nodes C3 and C4 to generate a new node C5, and finally point FT-2 to C5, as shown in Figure 3-2(right).

Note:

If C3 and C4 modify the same code in the same file at the same time, the merge will make an error, because Git does not know which node should be used as the standard, so we need to manually merge the code at this time

rebase

Rebase is also a merge instruction. The command line looks like this:

Git rebase branch name/node hashCopy the code

Unlike merge, rebase merge does not appear to produce new nodes (in fact, it does, only a copy is made). Instead, the nodes to be merged are added directly, as shown in Figure 3-3

When git rebase master is executed in ft-1.0 on the left diagram, the C4 node will be copied to the back of C3, namely C4′. C4 corresponds to C4′, but the hash value is different.

Rebase is more linear and clean than merge commit history, making parallel development processes look serial and more intuitive. Now that rebase is so good, can we get rid of merge? Not really. Here are some of the pros and cons of merging and rebase:

Merge advantages and disadvantages:

• Advantages: Each node is arranged strictly by time. When a merge conflicts, you only need to resolve the conflict between the nodes to which the two branches point
• Disadvantages: There is a high probability that a new node union will be generated when merging two branchesyOver time, history will become a mess

Advantages and disadvantages of Rebase:

• Advantage: It makes the submission history look more linear and clean
• Cons: While the commit looks linear, it’s not really chronological, as in Figure 3-3, regardlessC4Before or afterC3Submitting it will end up inC3behind And when merges collide, there are theoretically several nodesrebaseIt is possible to handle several conflicts by reaching the target branch

The author disagrees with some views that only rebase is used on the network. If rebase is used for the combination of different branches, conflicts may need to be repeatedly resolved, so the gains outweigh the losses. However, if it is local to remote and corresponds to the same branch, rebase is preferred. Therefore, my view is to use merge and rebase properly according to different scenarios. If you think merge and Rebase are ok, then use Rebase first

cherry-pick

Different from merge and Rebase, cherry-pick can select several nodes to merge, as shown in Figure 3-4

The command line:

Git cherry-pick node hashCopy the code

If the current branch is master, git cherry-pick C3 and C4 will directly grab C3 and C4 nodes and put them behind, corresponding to C3′ and C4′.

3.4 Rollback Related

The separation of the HEAD

By default, HEAD points to a branch, but you can remove the HEAD from the branch and directly point to a node.

Git checkout node hash // Can also be directly detached from the branch to point to the current node git checkout --detachCopy the code

Git also provides a relative reference to the first N nodes in a particular location (branch /HEAD), as follows:

Git checkout branch name /HEAD^Copy the code

Git checkout branch name ~ NCopy the code

What’s the use of separating the HEAD from the pointing node? For example, if the development process finds a problem with the previous submission, you can point the HEAD to the corresponding node and submit it after the modification. You don’t want to create a new node. Just add a –amend.

git commit --amend
Copy the code

The fallback

The fallback scenario is very common in normal development. For example, you write a lot of code and commit, and then you find that there is something wrong with the code, so you want to return the code to the previous commit. This scenario can be solved by using the reset command.

// Set git reset HEAD~NCopy the code

Reset is similar to a relative reference, except that reset rolls back both the branch and HEAD.

3.5 Remote Correlation

Git/Git/Git/Git/Git/Git/Git/Git/Git/Git/Git

Git Clone warehouse addressCopy the code

As I mentioned in the previous section, Clone does not just copy code. It also removes the remote repository reference (branch /HEAD) and saves it locally, as shown in Figure 3-5:

Where Origin/Master and Origin/FT-1 are branches of the remote repository, and these reference states of the remote repository will not be updated to the local in real time. For example, if the origin/master branch of the remote repository adds a commit, the local will not be aware of it. So the local Origin /master branch still points to the C4 node. We can manually update the remote repository status with the fetch command

Tip:

Not exist on the server to be called a remote repository, you can also clone the local repository as a remote, of course in the actual development we can not use the local repository as a public repository, said this is simply to help you understand more clearly distributed

fetch

In general, the fetch command is a download operation that downloads the status of the new node and reference (branch /HEAD) to the local. The fetch command is as follows:

Git fetch Remote repository address/branch nameCopy the code

pull

The pull command pulls code from a reference in the remote repository, as follows:

Git pull Remote branch nameCopy the code

In fact, the essence of pull is fetch+merge, which first updates all the state of the remote repository to the local, and then merges. When the merge is complete, the local branch points to the latest node

In addition, rebase can also be used to merge the pull command. The specific command is as follows:

Git pull --rebase remote branch nameCopy the code

push

The push command can push a local submission to a remote location. The specific commands are as follows:

Git push remote branch nameCopy the code

Direct push may fail because there may be conflicts. Therefore, pull is often used before push. If there is a conflict, it is resolved locally. After a successful push, the local remote branch reference is updated and points to the same node as the local branch

From what has been discussed above

• Whether it’sHEADorbranchThey’re all justreferenceJust,reference+nodeIs the key to Git’s distribution
• mergeCompared to therebaseThere’s a more specific history of time, andrebaseIt makes the commit more linear and should be used first
• By moving theHEADYou can view the code for each commit
• cloneorfetchWill be all of the remote warehousesubmit,referenceKeep a local copy
• pullIs the essence offetch+merge, can also join--rebaseMerge in rebase mode

The drawing of the article is a little low, the whole PPT, do you know that there is a better free drawing tools? Thanks in advance