[TOC]

• In normal development, we might develop multiple features simultaneously for versioning reasons. We manage through branches. Different branches have different functions and come online at different times.

Branch merge

Git merge –squash

• Git merge — A squash is different from git merge. The latter directly merges other submitted records. The former is a consolidation of content.

• The branch name here can be remote or local

  • Origin dev: indicates the remote dev
  • Dev: indicates the local dev

• Now we have a feature developed on the dev branch. And commit to the remote repository. Now we’re going to merge into the master branch.

• The Dev and Master branches have not been merged for a long time. There may be conflicts with the merge at this point

• Dev code commits remotely

• Now let’s make the remote branch merge request on another machine

• After executing a squash we see that two files conflict. We need to resolve conflicts. We’re throughgit statusYou can also see that the two files conflictboth modified

• Conflict resolution is also very convenient, we just need to analyze the content of the two files, and then resubmit. For example, let’s analyze the file 20190423trace.txt

• We believe that only Hello ZFXX submitted by Dev is valid. Then we just have to keep him.

• And then a series of submit pushes

• After we commit, let’s first look at the logging on the master

• Then look at the dev commit record on the other machine

• We found that dev’s test or even the previous commit was not in the master. This is where a squash differs from a merge

• Squash merges and re-commits the other branches. This makes it easier for us to manage the main branch. Dev branch developers may commit as much as they like to keep a small record of the commit log. But rule definitions that don’t care about this at all for the main branch or require some submission information. Squash merges the content and then commits it once again

Pay attention to the point

• If git status is executed on the current branch, you can see the merged files in the staging area. Commit and push to remote

Git rebase [branch name]

• We first cut off a branch called rebase_dev based on the master branch

• At this point rebase_dev and master are exactly the same.

• Now we modify a file on the rebase_dev branch and commit. How about we look at the commit log

• The head node of our rebase_dev branch has reached the commit of 054DE46. This commit is the commit we just committed
• 8ad6924 this commit is based on remote master, remote head, local master. This also shows that the local master and the remote master are now the same. And the remote master is on the latest node.
• At this point we’re going to commit and push on the local master and look at the log

• At this point, the master and rebase_dev branches move forward by two steps each.

• Rebase_dev pushes two branches

git rebase

• The git rebase command actually caches the rebase_dev branch to the.git/rebase directory
• Then move the rebase_dev base point (8AD6924) to the current master head node.
• Then update the two commits in the.git/rebase file to rebase_dev, respectively. So there are conflicts when it comes to updates. If rebase_dev pushes two commits, it will update twice. Git Rebase stops operations if a conflict occurs.
• We now need to resolve the conflict and re-add the file to the cache.
• Then execute git rebase –continue

git rebase –abort

• We suddenly don’t want to rebase after the first commit. Git rebase –abort. At this point the current branch returns to its pre-Rebase state. That is, base point at 8AD6924. And its two Commit’s are still there.

• Git rebase master on the rebase_dev branch

• Resetting the base point and adding the patch stored in./git/rebase to the current branch.
• Merge the first commit patch, which involves changing trace.txt. There are three ways we can merge. Git has automatically merged for us, which is our usual form of conflict. We can also passgit am --show-current-patchView conflict details. After we have determined that the conflict is resolved, we git add to re-add or git rm to delete the file. Then performgit rebase --continueProceed to the next commit. Or performgit rebase --skipSkipping the current commit. Actually discards the commit. Or performgit rebase --abortStop the current rebase and return to the previous state

• After skip, we see that applying rebase V2 explains how the second patch is committed. There was also conflict. At this point, the first commit has already been abandoned by us. It’s not going to affect us.

• We execute git rebase –abort to stop the current base change. We looked at the source file and found no conflicts or changes by the main branch content.

• Git rebase master to merge the content.

• We went through the process and we were told the merger was a success. I just left the auto-merge information when I was processing the merge. Let’s look at the final document

• We looked at the log and found. The master log comes before rebase_dev. The rebase_dev commit ids are changed. This also means that we moved our base point to master and rebase_dev’s commmit was readded to the rebase_dev branch.

git rebase -i

• Rebase_dev and master commit (s) : rebase_dev and master commit (s)
• performgit rebase -i HEAD~4

• In the pop-up window we can find the first four rows of our commit in reverse order. There is also an explanation of the parameters below to merge the four commits into the last one. And 702 de33.

Let’s take a look at two common ones. I don’t know what I’m talking about. I’ll fix it later

• We found that four commits were merged into one. This helps us manage the commit information.

Git merge

• Git merge git merge git merge git merge git merge git merge The above comparison has been combed out. Git rebase differs from Git rebase. Git merge is suitable for primary branch operations.