A Better Way to Git Rebase

A well known principle of git commit is “commit early and commit often”. But, what this rule of thumb doesn’t say is that it’s for local dev only, not for the final repo. Think about this situation, you’ve been working on a component for days. During that time you made a series of commits that looked like this:

Locally this makes perfect sense, and is a very detailed trace of your work in progress. However, imagine what it looks like in the repo? It’ll be a total MESS. You don’t need this level of detailed tracking in there, and they decrease log readability significantly. All you need is one commit that says “feat(Form): implemented Form component, updated documentations.” This is especially true when it comes to teamworks. That’s why you’re usually required to squash your commits before pushing.

Another added benefit is that after squashing the commits, you only need to resolve potential conflicts once during rebasing instead of multiple times, once for each commit that contains conflicts, which saves time and reduces confusion.

When you use hard mode,

With mixed, which is the default mode,

For our purpose reset soft is the clear winner. It merely returns all changes to the staging area and leave them for you to decide what to do. In this case, we can simply submit everything again as a single commit.

In the above example, you can either use HEAD~n to reset a number of commits from the current tip down, or you can use the hash of the commit to which you want to reset. For instance:

I want to reset my local commits to where upstream and origin is, i.e. hash e7293f7, then the following command will suffice:

Immediately you’ll see that all changes after e7293f7 appeared in the staging area, and hash e7293f7 became the new tip.

There’re two ways of doing it, either remotely or locally. But, first you need to understand the relations between local, origin and upstream, and I quote:

As you can see from the quote and diagram above, there’s no upstream to start with. So we need to add one with the following commands:

Afterwards, you can fetch from upstream (original repo) in order to keep the local clone up-to-date. When your commits are ready, push to origin (forked version) first, then from there pull request into the original repo (upstream). The following commands rebase the local branch onto the master branch on upstream:

Or pull from master branch on origin first then rebase locally.

If there’re no conflicts, then you’re in luck. Otherwise, resolve the conflicts and keep going with git rebase --continue. In a lot of cases, you can simply use git rebase --skip to skip the conflicts and get right to the end. Because a lot of them are not actually conflicts, but transitions in-between the starting and final states of the code that just show up as conflicts, when there’s no need to resolve them.

When pushing the commits, you need to use [--force | -f] option to forcefully rewrite repo history. Otherwise you’ll be prompted that your code is has diverged from the repo, and you need to do a git pull first, which you shouldn’t do as it beats the entire purpose of what you just did.

Now, you should have a clean and concise commit log for your pull requests.

Related posts:

In the run up to Clearleft’s Leading Design conference in London this October, the team caught up with Peter Merholz to discuss his background, experience and thoughts on the subject of Design…

Total deepened its foray into power and gas retail, underlining a strategy shift among European oil majors as the global transition to cleaner energy gathers pace. The French company agreed to buy…

This is the product creation journey of Convergente: an educational book-series conceived with a design systems methodology and an aesthetic multiverse embedded into it.