Thoroughly Understand Git-Rebase. Avoid changing your application’s… | by Dwen | Jul, 2022

Avoid changing your application’s history

Photo by Workperch on Unsplash

I’ve been using Git for a few years, but I’ve always just been familiar with some common operations. It is rarely used for Git Rebase, until this time, it has to be used.

I glanced at the code changes during the online build process and suddenly found that there were as many as 62 commits. Let’s see what was submitted:

1*1 jMopxqmB2ZtA9 E9LTHw

Let’s not talk about the git commit specification here; so many useless commits are very uncomfortable.

The following will eventually cause problems:

  • Bad for code review. Imagine that you are going to do a code review, and the result is a small feature that has been submitted more than 60 times. Will there be some crashes?
  • Branch contamination. Your project is full of useless commit records. If there is an urgent problem on the line one day, you need to roll back the code, but you find that a large number of commits need to be read one by one.

Follow the project specification to improve the efficiency of team collaboration, not arbitrary.

Based on the problems mentioned above, it is not difficult for us to think of each time a function is developed or multiple commits are merged.

At this time, you need to use git rebase. This command is not too difficult, and it may be due to unfamiliarity, so let’s learn it through examples.

  1. Let’s merge the last four commit records and execute.
git rebase -i HEAD~4

2. At this time, it will automatically enter the vi editing mode.

s cacc52da add: qrcode
s f072ef48 update: indexeddb hack
s 4e84901a feat: add indexedDB floder
s 8f33126c feat: add test2.js

# Rebase 5f2452b2..8f33126c onto 5f2452b2 (4 commands)
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
# 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.

There are a few commands to be aware of, and here they are:

  • p, pick = use commit.
  • r, reword = use commit, but edit the commit message.
  • e, edit = use commit, but stop for amending.
  • s, squash = use commit, but meld into previous commit.
  • f, fixup = like “squash”, but discard this commit’s log message.
  • x, exec = run command (the rest of the line) using shell.
  • d, drop = remove commit.

Modify your commit history as follows:

s cacc52da add: qrcode
s f072ef48 update: indexeddb hack
s 4e84901a feat: add indexedDB floder
p 8f33126c feat: add test2.js

3. If you encounter this error when saving:

error: cannot 'squash' without a previous commit

Be careful not to merge previously committed things, that is, records that have been committed to the remote branch.

4. Don’t be nervous if you exit the vi window abnormally.

git rebase --edit-todo

At this time, we will always be in this editing mode, we can go back to continue editing, and save it after modification.

git rebase --continue

5. View the results.

git log

Three commits were merged into one, reducing useless commit information.

1*FHJecl sQ33mL4duuU4gqw
  1. We first cut a feature1 branch from the master branch for development.
git:(master) git checkout -b feature1
image by author

2. At this time, your colleague has completed a hotfix and merged it into the master branch. At this time, master is ahead of your feature1 branch.

1*cuYZPNos6qhRvzwhAS89 g
image by author

3. Coincidentally, we want to synchronize the changes of the master branch. We thought of mergeand execution first.

git:(feature1) git merge master
1*EGY5SJqm2QkN3k6wd cvbw
image by author

The green point in the figure is the result after we merge, and execute the following:

git:(feature1) git log

Some merge information will be found in the record, but we feel that this pollutes the commit record, and we want to maintain a clean commit, what should we do? This is where git rebase comes in handy.

4. Let’s try git rebase. First, roll back to the colleague’s hotfix, and then merge the master .

1*cuYZPNos6qhRvzwhAS89 g

5. Use rebase to see the result later.

git:(feature1) git rebase master

What does rebase do?

  • First, Git will cancel every commit in the feature1 branch.
  • Second, temporarily save the above operations as a patch file, which is stored in the .git/rebase directory.
  • Then, update the feature1 branch to the latest master branch.
  • Finally, apply the patch file saved above to the feature1 branch.
1*2Yv0mp EMWNRCWe5XwmDgg
image by author

From the commit record, we can see that the feature1 branch is based on the hotfix merged master, which naturally becomes the most advanced branch, and there is no merge commit record. Do you feel very comfortable?

6. In the process of rebase, there may be conflicts. In this case, Git will stop the rebase and let you resolve the conflict. After resolving conflicts, use the git add command to update these.

Note that you don’t need to execute git-commit, just execute continue.

git rebase --continue

This way Git will continue to apply the remaining patch files.

7. At any time, we can use the —- abort parameter to abort the rebase action, and the branch will return to the state before the rebase started.

git rebase —abort

The value of git rebase is to rebase a branch.

1. When we are developing on an outdated branch, execute rebase to synchronize the latest changes of the master branch.

2. If we want to start a parallel job that has been sitting for a long time, and now there is time to continue this, it is obvious that this branch is behind. At this time, you need to start working on the latest benchmark, so rebase is the most suitable choice.

According to the above, git-rebase is perfect and solves our two problems:

1. Merge commit records to keep branches clean.

2. Compared with merge, it will reduce the records of branch merge.

If you submitted the code to the remote, it will look like this before submitting:


After the commit, the remote branch looks like this:

1*2Yv0mp EMWNRCWe5XwmDgg

At this time, your colleague is also developing on feature1, and their branch still looks like this:

Then when they pull the remote master, they will lose the commit record. That’s why we often hear people say git rebase is a dangerous command because it changes history. We should use it with caution.

As long as all the history of commits on your branch that need to be rebased has not been pushed, it is safe to use git rebase.

News Credit

%d bloggers like this: