![](https://hackernoon.com/hn-images/1*CmeNhESv2VdJgrei0z3z_Q.png)

Rewriting history without a time machine
----------------------------------------

Like **Vim vs Emacs**, **Merging vs Rebasing** is an endless debate. Both have pros and cons but to the question of whether merging or rebasing is better: hopefully you’ll see that it’s not that simple. [Git](https://hackernoon.com/tagged/git) is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different. If you know how both of these things work, it’s up to you to decide which one is best for your particular situation.

### Why do I need to rebase?

From a content perspective, rebasing really is just moving a branch from one commit to another. But internally, Git accomplishes this by creating new commits and applying them to the specified base — it’s literally **rewriting** your project history. The general process can be visualised as the following:

![](https://hackernoon.com/hn-images/1*bK_5KgdG7RkcJDgFcPbZ0w.png)

When a feature branch’s development is complete, [rebase](https://hackernoon.com/tagged/rebase)/[squash](http://git-scm.com/book/en/Git-Tools-Rewriting-History) all the work down to the minimum number of meaningful commits and avoid creating a merge commit. This way code history remains flat and readable. Clean, clear commit messages are as much part of the documentation of your code base as code comments. For this reason, it’s important not to pollute history with 50 single-line commits that partially cancel each other out for a single feature or bug fix.

### Git rebase interactive

Interactive rebasing gives you the opportunity to alter commits as they are moved to the new branch. This is even more powerful than an automated rebase, since it offers complete control over the branch’s commit history. Typically, this is used to clean up a messy history before merging a feature branch into `develop`. It lets you clean up history by removing, splitting, and altering an existing series of commits. It’s like `git commit --amend` on steroids.

To begin an interactive rebasing session, pass the `i` option to the `git rebase` command:

    git checkout featuregit rebase -i origin/develop

This will open a text editor listing all of the commits that are about to be moved:

![](https://hackernoon.com/hn-images/1*5YPa45EbA2oX0ZWcqnIz0w.png)

This listing defines exactly what the branch will look like after the rebase is performed. By changing the `pick` command and/or **re-ordering the entries** (such a cool feature), you can make the branch’s history look like whatever you want. For example, if the #2 commit fixes a small problem in the #1 commit, you can condense them into a single commit with the `fixup` command (or **f** for short):

![](https://hackernoon.com/hn-images/1*Oy1cS6_OQGMCgBoNBFxEBQ.png)

When you save and close the file, Git will perform the rebase according to your instructions.

Most developers like to use an interactive rebase to polish a feature branch before merging it into the main code base. This gives them the opportunity to squash insignificant commits, delete obsolete ones, and make sure everything else is in order before committing to the “official” project history. To everybody else, it will look like the entire feature was developed in a single series of well-planned commits.

### Squashing

Eliminating insignificant commits makes your feature’s history much easier to understand. This is something that `git merge` simply cannot do.

There are [several](http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git) ways to squash commits, the following are the ones I use the most.

#### By using the the interactive rebasing

git rebase -i **HEAD~3**

![](https://hackernoon.com/hn-images/1*CVhq05aSXNT6x6ykn0UYtQ.png)

It’s HEAD~3 because it is the number of commits in this branch

If you are not sure about the amount of commits the branch has, you can perform a `git log --oneline` get the hash of the commit before you started working on this feature and do a:

git rebase -i **3598fe2**

![](https://hackernoon.com/hn-images/1*pT0HHQc9PvXdG37Lj3zObA.png)

If you lost track of how many commits are in your branch you can create an alias in your `.gitconfig`:

    [alias]    count = 

Running `git count **develop**` will tell you the number of commits you have diverged from **develop**, note that it can be used with any branch name.

#### Or by reseting “X” number of commits

    git reset --soft HEAD~X

After this command, your last X commit changes will be unstaged so you’ll need to create a new commit to override them.

    git add .git commit -am "Feature Z is completed"

This way is great when you open a pull request and someone tells you to fix something, you can just go back “1” commit, fix what you need to fix and force push it.

### Force pushing

Now that we’ve rewritten history locally we need to override the remote by force pushing it to upstream.

    git push origin feature_branch --force

![](https://hackernoon.com/hn-images/1*MOJPqQhY-JokxSXhExq5dw.jpeg)

Git’s `push --force` is **destructive** because it **overwrites the remote repository** with whatever you have locally, **possibly** overwriting any changes that a team member has pushed in the meantime, so **be super cautious about this**.

### `--force-with-lease` , --force less known little brother

This option allows you to force push without the risk of unintentionally overwriting someone else’s work. It will only allow you to force-push if no-one else has pushed changes up to the remote in the meantime. If there are new remote commits, `--force-with-lease` will fail, prompting us to fetch first.

If you intend to use it often, create an alias in your `.gitconfig`:

    [alias]    pf = push --force-with-lease

![](https://hackernoon.com/hn-images/1*0EdMU24k3NtPwkqOf0kQPw.png)

_computer says no_

### In the end…

The main decision revolves around this: **Do you value more a clean, linear history? Or the traceability of your branches?** In the first case go for a **rebase** policy, in the later go for a **merge** one.

### Thanks

… for getting this far! I would love to know what do you think and if you do something in a different way. Also it would be awesome if you click the little ❤️ and share the article so more people would benefit from it.

If you are interested in more tech related topics, please check my other articles, follow me on [Twitter](https://twitter.com/cesarmcferreira) or check my [GitHub](https://github.com/cesarferreira/) projects.

### Sources

[**Git - The Command Line**  
_Translations started for Azərbaycan dil, Беларуская, Català, Esperanto, Español (Nicaragua), فارسی, हिन्दी, Magyar…_git-scm.com](https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line "https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line")[](https://git-scm.com/book/en/v2/Getting-Started-The-Command-Line)

[**Merging vs. Rebasing**  
_Compare git rebase with the git merge command and identify all of the potential opportunities to incorporate rebasing…_www.atlassian.com](https://www.atlassian.com/git/tutorials/merging-vs-rebasing/ "https://www.atlassian.com/git/tutorials/merging-vs-rebasing/")[](https://www.atlassian.com/git/tutorials/merging-vs-rebasing/)

[**Gitflow Workflow**  
_The Gitflow Workflow streamlines the release cycle by using isolated branches for feature development, release…_www.atlassian.com](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow "https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow")[](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)

[**Git - Rewriting History | Atlassian Git Tutorial**  
_Common use cases for overwriting committed snapshots in Git. History rewriting commands: git commit--amend, git rebase…_www.atlassian.com](https://www.atlassian.com/git/tutorials/rewriting-history "https://www.atlassian.com/git/tutorials/rewriting-history")[](https://www.atlassian.com/git/tutorials/rewriting-history)

[**\--force considered harmful; understanding git's --force-with-lease - Atlassian Developers**  
_Git's push --force is destructive because it unconditionally overwrites the remote repository with whatever you have…_developer.atlassian.com](https://developer.atlassian.com/blog/2015/04/force-with-lease/ "https://developer.atlassian.com/blog/2015/04/force-with-lease/")[](https://developer.atlassian.com/blog/2015/04/force-with-lease/)

[**Git - Rebasing**  
_Now, to the question of whether merging or rebasing is better: hopefully you'll see that it's not that simple. Git is a…_git-scm.com](https://git-scm.com/book/en/v2/Git-Branching-Rebasing "https://git-scm.com/book/en/v2/Git-Branching-Rebasing")[](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)

[**Git team workflows: merge or rebase?**  
_Atlassian Git Tutorial_www.atlassian.com](https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ "https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/")[](https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/)

[**Force push with care**  
_A gentler git push --force ._robots.thoughtbot.com](https://robots.thoughtbot.com/git-push-force-with-lease "https://robots.thoughtbot.com/git-push-force-with-lease")[](https://robots.thoughtbot.com/git-push-force-with-lease)

[**Bash Shortcuts to Enhance Your Git Workflow**  
_The more you work with Git, the faster you’ll learn its workflows._medium.freecodecamp.com](https://medium.freecodecamp.com/bash-shortcuts-to-enhance-your-git-workflow-5107d64ea0ff "https://medium.freecodecamp.com/bash-shortcuts-to-enhance-your-git-workflow-5107d64ea0ff")[](https://medium.freecodecamp.com/bash-shortcuts-to-enhance-your-git-workflow-5107d64ea0ff)

ATLASSIAN

Fetch

Super

Twitter

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Mastering Git — Why Rebase is amazing

Too Long; Didn't Read

Companies Mentioned

@cesarmcferreira

RELATED STORIES