Skip to main content

git-rebase

Absolutely! Understanding how to use git rebase interactively is a powerful tool for managing your commit history. Let’s break it down step by step with examples.

What is Git Rebase?​

git rebase allows you to take a series of commits from one branch and apply them onto another branch. This is useful for maintaining a clean commit history. Interactive rebasing (git rebase -i) enables you to modify commits as you replay them.

When to Use Interactive Rebase​

  1. Cleaning Up Commit History: If you have a series of small, incremental commits that you want to squash into one or two meaningful commits.
  2. Reordering Commits: If you want to change the order of your commits.
  3. Editing Commit Messages: If you need to correct or clarify commit messages.
  4. Removing Commits: If you want to discard certain commits from your history.

Basic Command​

To start an interactive rebase, you would use:

git rebase -i HEAD~n

Here, n is the number of commits you want to include in the rebase.

Example Scenario​

Let’s assume you have the following commit history:

A -- B -- C -- D -- E (feature/large-pr)

Where:

  • A = Initial commit
  • B = Added SSR changes
  • C = Added animation changes
  • D = SEO improvements
  • E = A11y updates

You want to squash commits B, C, D, and E into one commit.

Step 1: Start the Interactive Rebase​

Run the following command:

git rebase -i HEAD~4

This will open an editor with a list of the last four commits.

Step 2: Modify the Commit List​

You’ll see something like this:

pick <hash> B Added SSR changes
pick <hash> C Added animation changes
pick <hash> D SEO improvements
pick <hash> E A11y updates

To squash commits into the first one (B), change it to:

pick <hash> B Added SSR changes
squash <hash> C Added animation changes
squash <hash> D SEO improvements
squash <hash> E A11y updates

Step 3: Save and Close the Editor​

After saving and closing the editor, Git will apply the changes and prompt you to create a new commit message. You can combine messages or create a new one.

Step 4: Resolve Conflicts (if any)​

If there are conflicts, Git will pause the rebase and inform you. You can resolve conflicts in the affected files. After resolving, you would:

git add <resolved-files>
git rebase --continue

Repeat this until all conflicts are resolved.

Step 5: Complete the Rebase​

Once you’ve finished resolving any conflicts and saved your commit message, the rebase will complete. Your commit history will now look like this:

A -- B' (squashed commit)

Step 6: Push Changes​

If you’ve already pushed the original branch, you’ll need to force push the changes:

git push origin feature/large-pr --force

Important Notes:​

  • Rebasing rewrites history: Be cautious when rebasing commits that have been shared with others.
  • Always ensure you have a backup: Before starting a rebase, especially an interactive one, it’s a good practice to create a backup branch.
  • Use git log to verify your history after the rebase.

Tutorial #2​

git checkout --theirs <file/path/dist/styles.css>

Cherry-pick, Rebase, Merge​

  • Both Rebase and Merge are useful in Git. One is not better than the other.
  • A git cherry-pick is essentially just a git merge. and a git rebase is essentially just a git cherry-pick
  • In the case of a merge you will have a merge commit. In the case of a rebase there is no extra commit like a merge commit.

One best practice is to use the commands at different points. Use rebase when you are updating your local code repository with the latest code from the remote repository. Use merge when you are dealing with pull requests to merge the Feature branch back with the Release or Master branch.

Using Rebase alters the commit history ( it makes it neater). But that being said, altering the commit history has it’s risks. So ensure you never use rebase on a code that is there in the remote repository. Always use rebase only to alter the commit history of your local repo code.

If rebase is done to a remote repository it can create a lot of confusion since other developers will not recognise the new history.

Also if rebase is done on the remote repository, it can create issues when other developers try to pull the latest code from remote repository. Always use rebase only for the local repository

GIT Rebase Steps​

  1. pull develop
  2. git rebase HEAD~2 -i (interactive)
  3. pick/squash
  4. rebase develop
  5. push -f

Alternate: Rebase Steps​

  1. git checkout -b 'namespace/your-branch-name'
  2. npm run commit
  3. git rebase develop

When finished with your branch​

  1. git checkout develop
  2. git fetch --all
  3. git pull

rebase your branch​

  1. git checkout 'namespace/branchName'
  2. git rebase develop

How to skip a particular file from rebasing​

  1. git checkout --theirs file.name.js
  2. followed by git add blah.jsto resolve
  3. then git rebase --continue