1. The two ways and differences of git pull project

1. Method:

Http: The clone project through http does not need to manually bind ssh on git, but only needs to enter the account number and password when cloning;
SSH: Clone the project through ssh, you need to manually bind the ssh key

2. Difference

The Http method is suitable for anonymous access, suitable for open source projects, and can be easily cloned and read by others (but without push permission);
The Ssh method is suitable for internal project development, as long as the SSH key is configured, the clone and push operations can be freely realized.

2. The difference between git rebase and git merge

The git rebase and git merge commands deal with the same problem. Both commands are used to integrate changes from one branch into another branch-it's just that they do the same thing in different ways.

Now, suppose a new commit on the master branch is related to the feature you're working on. To merge new commits into your feature branch, you have two options: merge or rebase.

2.1、merge

The principle of merge is to find the ancestor commits of these two branches, and perform a three-way comparison and merge on
the latest commits of the two branches . Three commits are compared:

Comparing commit6 and commit2, if the hash value of the file is different, and comparing commit5 and commit2 at the same time, and finding the same, it means that only commit6 has modified the file. In this case, it will be merged directly without prompting

Comparing commit6 and commit2, if the hash value of the file is different, and comparing commit5 and commit2 at the same time, the hash value is different, indicating that both branches have modified the same file, a conflict will be prompted, and we need to manually merge

After the final merge, a new commit7 will be generated.

2.1.1. Summary

Using merge is a good idea because it is a non-destructive operation. Existing branches will not be changed in any way. This avoids potential pitfalls created by rebase operations (discussed below).

On the other hand, this also means that every time the develop branch needs to merge upstream changes, it will produce an additional merge commit. This can seriously pollute your develop branch history if master commits are very active. While this problem can be mitigated with the advanced option git log , it can make it difficult for other developers to understand the project's history.

2.2、fox

This develop moves the entire branch to master the front of the branch, effectively integrating master the commits on all branches. However, unlike merge commits, rebase rewrites the project history by creating brand new commits for each commit in the original branch.

The main benefit of rebase is a cleaner project history. First, it eliminates unnecessary merge commits required by git merge; second, as you can see in the image above, rebase produces a perfectly linear project history, and you can have no forks on the develop branch The case goes all the way back to the project's initial commit. This makes it easier to navigate and view projects with the commands git log, git bisect and gitk.

However, for such a commit history, we need to weigh its "safety" and "traceability". If you don't follow [the golden rules of Rebase], rewriting the project history can be disastrous for your collaborative workflow. Also, rebasing loses the context of the merge commit, so you can't see when upstream changes were merged into develop.

3. Summary of advantages and disadvantages of merge and rebase

rebase: After the merge, the branch map looks good, with a single line, but if there is a conflict during the merge process, it will be more troublesome (during the rebase process, if a commit has a conflict, the next commit is also very likely to have a conflict, and a rebase may have to resolve multiple conflicts) ;
merge: After the merge, the branch map is not good-looking, and a bunch of lines are intertwined, but if there is a conflict in the merge, you only need to solve it once;
In general, if the common ancestor branch of the merged branch differs by one or two or two or three commits, use rebase. After all, rebase looks good after merging, and the branch map is clear. If there are many commits different from the common ancestor branch, it means that rebase is possible. If there are multiple conflicts, merging will be very troublesome. At this time, use merge

Problems with git pull project