Git rebase git rebase git rebase Git rebase Git rebase Git rebase Git rebase Git rebase has been used since last year, when nearly 20 branches were iterated at the same time and a large number of projects were developed and committed. I came across git rebase by accident.

  • git merge: Recommended when you need to retain detailed merge information, especially if branches need to be merged intomasterbranch
  • git rebase: When you find yourself changing a feature, you do it frequentlygit commitWhen submitting, it is found that too much submission information is not necessary to use, and it can also be considered to use if there are many branches and contents

Create a new branch named “feature/mywork” to describe the origin/master branch

git rebase

$ git checkout -b feature/mywork
Copy the code

Now make some changes to the branch feature/mywork and generate two Commits

$ vim README.md
$ git commit -am "xxxA"

$ vim CHANGELOG.md
$ git commit -am "xxxB".Copy the code

At the same time, there are some people inmasterSome changes were made to the branch, such as merging the Release branch code for distribution. That meansmasterandfeature/myworkThese two branches are going their own way, they’re bifurcating.

You can use the pull command to pull changes from the master branch and merge them with your changes. The result looks like a new merge commit:

git merge

At this point, the feature/ Mywork branch history seems to have been bifurcated, and this is just two branches. Imagine a large project with 20 branches, iterating over some functional modules or modifying the same code block at the same time. What would the branch tree look like? Could that have prevented this? The answer is yes, if you want the feature/mywork branch history to look like it hasn’t been merged, use Git rebase

$ git checkout feature/mywork
$ git rebase master
Copy the code

Let’s take a look at the effect:

Explanation: Git rebase cancels every commit in the feature/mywork branch, temporarily saves it as a patch, and updates the feature/mywork branch to the latest master branch. Finally, the saved patches are applied to the feature/ Mywork branch.

When the feature/ Mywork branch is updated, it points to these newly created commits, and the old ones are discarded. If you run the pruning garbage collection command, these discarded commits are deleted.

Now we can look at the history difference between merging and rebase:

Resolving CONFLICT

In the process of rebase, conflicts may arise. In this case, Git stops rebase and lets you resolve the conflict; After resolving the conflict, update the index of the contents with git add. Then, you don’t need to commit with git.

$ git rebase --continue
Copy the code

Git will then continue to apply the remaining patches.

At any time, you can terminate the rebase action and the feature/ Mywork branch will return to the state before rebase started.

$ git rebase --abort
Copy the code

Git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase –continue git rebase — For example, JetBrains IDE series have good support for VCS, and the latest version directly changes VCS to Git, taking IntelliJ IDEA as an example:

Merge/Rebase, push, etc. Git Commit Template provides perfect coding.

What if git Rebase resolves the conflict and cannot push?

If you have experience with Git rebase, you will feel relieved when you resolve a bunch of conflicts, and then reject when you push. Git push –force git push –force git push –force git push –force git push –force

  • Once in the production process, I encountered a forced push after rebase. Other students in the same branch made an error when pulling the code, and forced coverage was not good either. Git push –force is not recommended unless there is a good reason to force it
  • There will berecommended--force-with-leaseParameter, which allows us to push more safelyGit version 1.8.5 began to provide this parameter, intended to resolvegit push --forceSecurity problems caused by commands. If you don’t get a sense of the danger, check out this story:If you use Git’s -f parameter to push your repository, you are killing yourself!

–force-with-lease Git push –force-with-lease Git push –force-with-lease git push –force-with-lease

Force-with-lease is more secure than force.

conclusion

Like Git merge, git rebase is used to merge changes made in one branch into another branch. As shown in the Chinese picture, the main features are as follows:

  • Changes where the current branch is pulled from the master branch

  • There is no redundant merge history record, and the commit sequence after the merge may not be arranged according to the commit time of the commit. The SHA value of a commit may change, as shown in the following figure:

    • Unmerge compare after push before master branch

    • After the master branch has code update, rebase operation is performed on the current branch, push compare

      For the same commit, the SHA value changes after the rebase operation, similar to C5 and C5 ‘, C6 and C6 ‘, essentially new commit.

  • Conflicts in the same place can be resolved multiple times.

Normally all submissions on the feature/ Mywork branch are merged into the Master branch, but this information is not necessary for us, we usually just need to know what new features are merged into the Masetr branch. Git rebase is an interactive mode in which you pass in the -i parameter and specify which commits to process. For example:

$ git rebase -i HEAD~6
Copy the code

The above command specifies the last six commits for the current branch, and you will see a prompt:

#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c 
      
        to reword the commit message.
      
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
Copy the code

You can use a squash to merge all commits into a single commit. After you edit and save the commit, you will be prompted to edit the commit. You will find that there is only one commit.