How to rebase GitHub branches and commits example

Rebase GitHub branches and commits tutorial

Developers should be aware of a few caveats when they rebase GitHub repositories, especially when they work on a protected branch like master. In this tutorial on how to rebase GitHub, we will clone a repository that has both a master and a feature branch, rebase those branches and demonstrate some of the challenges associated with a push of a rebased GitHub repo to the server.

The first image below is the branch diagram of the GitHub repository used in this example. The tip of the feature branch has two files that master does not: d.txt and e.txt.

In corollary, the master branch has a file named c.txt which the feature branch does not have. At the end of this example, both branches will be completely in sync with local copies of each file.

Rebase GitHub branch onto master

All GitHub rebase operations occur on a developer’s local machine. The changes are then pushed back to the GitHub server. The following commands pull from GitHub and then rebase onto master the feature branch:

https://github.com/potemcam/rebase-github.git
cd rebase-github
git checkout feature
git log --graph --oneline --branches
git rebase master feature
git log --graph --oneline --branches
rebase GitHub repo example

The GitHub rebase example starts with a master and feature branch.

Compare the git log –graph output before and after the rebase of GitHub branches. Developers will notice how the commit history has gone from branched to linear. The image below also shows how commits D and E have been given new hash IDs. With a Git rebase, the original commits are discarded, and new commits are created as the commit history is reapplied on top of the rebased branch.

github branch rebase

Contrast the Git log graph before and after the GitHub rebase.

GitHub rebase rejected

If a developer were to immediately attempt to push this rebased Git or GitHub repo back to the server, it would be rejected with the following message:

error: failed to push some refs to ‘https://github.com/cameronmcnz/rebase-github.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.

GitHub doesn’t like it when a rebase changes branch points or deletes commit. The only way to compel GitHub not to reject the rebase is to use the –force switch on the git push.

git push origin --force

Rebase GitHub master onto branch

If developers inspect the master and feature branches, they will notice that master is still missing a few files, while feature has a copy of every single one. If we were to now rebase master onto the develop branch, the master would acquire the missing d.txt and e.txt files. The git rebase command to achieve this is:

git rebase feature master
rebased GitHub master

We must rebase GitHub master onto the feature branch to bring the master and feature branch into complete sync.

After this second rebase, both the master and feature branch point at the same commit, and their files will be completely in sync.

master GitHub rebase

The rebased GitHub branches are now in sync.

GitHub push rejected

Locally, our Git repository looks great. However, most DVCS tools consider the idea of a rebase of master onto another branch to be detestable. For the most part, developers can rebase branches onto master, but they shouldn’t rebase master onto another branch because it has the potential to cause serious problems with other GitHub users.

If the administrator assigned master branch permissions, the push to master after a rebase will likely be rejected even if the –force command is used. If this is the situation, the only way to push the rebase of a GitHub master branch is to issue a pull request and have an administrator with elevated permissions perform the merge. If branch permissions don’t exist, the –force switch on the push will be sufficient to have your GitHub rebase accepted.

The ability to manipulate the repository’s commit history and clean up Git is one of the most advanced features of the Git tool, and it should be used sparingly. Developers need to always take care when they rebase GitHub branches and push those changes back to the server.

You can find the repository used in this GitHub rebase example on GitHub.