Skip to main content

How to do Git Rebase in Eclipse

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here:
One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like:

The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon).

Check out this extreme-case history: http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg

Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time.

Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit.

Git Rebase offers us 2 benefits over Git Merge:
First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For this, the Eclipse EGit Rebase Interactive tool is helpful in rewording, squashing etc. several commits into a smaller number of more logical chunks;
Second, Rebase lets us merge branches more cleanly, with fewer Merge-commits left over.

#2 is what we need in order to bring our changes from one branch onto another branch, in a way that avoids the parallel lines and merge commits in the above image.

As always in Rebasing, think locally. That is:

Do not rebase commits that exist outside your local repository

How to Rebase Branches in Eclipse:

In this example, I have 2 local branches: "dev" that matches the branch on an upstream central repository, and "Project93979", a local branch for a new feature or a bug fix. 

Now I am done and ready to merge the branch into the dev branch and be pushed upstream.

To Rebase instead of Merge in Eclipse, I follow these steps:

  • Check out me dev branch by double-clicking on it.
  • Pull from the upstream repository to make sure dev branch is up to date.
  • Check out the Project93979 branch again.
  • Right-click on the dev branch and select Rebase On.


  • If there are conflicts, do the usual manual-merge conflict-resolution work. There is one catch: If multiple commits include changes to a file that made conflicts, I need to resolve the conflict for each of those commits (in a Merge, you resolve it just once).

Eclipse will notify you of conflicts with a dialog like this (in Eclipse Mars):


  • Click OK to start the Merge Tool. Use the Merge Tool to navigate the conflicts and copy or change the source as needed to resolve the conflicts. 



  • Once the changes are completed, save the merged files and switch to the Git Staging view. The conflicting file may still have the red Conflict icon decorator in the Unstaged Changes box, but since they are resolved and saved, right-click and add them to the Index. The Conflict decorator is replaced with the Changes decorator and the Commit button is enabled.

In the above image, the Continue button is also enabled at this point. That is because Rebase is replaying the series of commits we made on this branch onto the new starting-point commit. “Continue” lets us move forward, either to the rest of the commits, or to the rest of the Rebase process.

Once the conflicts are handled, branch Project93979 has been Rebased to look how it would have had the branch been created from the very latest of the dev branch and then all the changes were made. This is the goal of Rebase and, when there are no conflicts, Git handles this very nicely.

This has only changed the Project93979 branch, not the dev branch yet. To complete the Rebase of dev, essentially merging Project93979 into dev without the Merge Commit, we must still Rebase the dev branch.


  • Check out the dev branch again. Right-click on the Project93979 branch, then select Rebase On. This should be fast and trivial, since we already resolved all of the conflicts above. It should just be what Git calls a Fast-Forward.
  • Dev branch is now ready to push upstream. Whatever commits were in the Project93979 branch should now appear in the history of the dev branch, but with no Merge-commit and no clutter of parallel lines showing branches that never really existed on the remote repository. The image below is the Eclipse Git History view, and you can see that the Project93979 branch has been brought together with the dev branch cleanly.


Labels:

Popular posts from this blog

Git Reset in Eclipse

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.
Read more

Scala Collections: A Group of groupBy() Examples

Scala provides a rich Collections API. Let's look at the useful groupBy() function. What does groupBy() do? It takes a collection, assesses each item in that collection against a discriminator function, and returns a Map data structure. Each key in the returned map is a distinct result of the discriminator function, and the key's corresponding value is another collection which contains all elements of the original one that evaluate the same way against the discriminator function. So, for example, here is a collection of Strings: val sports = Seq ("baseball", "ice hockey", "football", "basketball", "110m hurdles", "field hockey") Running it through the Scala interpreter produces this output showing our value's definition: sports: Seq[String] = List(baseball, ice hockey, football, basketball, 110m hurdles, field hockey) We can group those sports names by, say, their first letter. To do so, we need a disc...
Read more

Updating Oracle javapath symlinks on Windows

A Java-based application on my Windows 10 machine recently started prompting me to upgrade my version of Java. Since I wanted to control it myself, I declined the app's offer to upgrade for me, and downloaded and installed the latest Java 8 from Oracle. In my case, Java 1.8.0_171, 64-bit version. The upgrade went fine. But when I launched the app, it again said I needed to upgrade. Why was it still looking at the old location? I made the change using Settings, to change the JAVA_HOME environment variable to point to the location of the new upgrade. But no change, the app still insisted that I needed to upgrade. A little research into the app's execution path showed that it was using c:\ProgramData\Oracle\Java\javapath to find Java. When I looked in that folder, I found symbolic links to my old Java installation. Normally, this hidden bit of information gets updated automatically in the upgrade or installation process. I have read of cases where, when downg...
Read more

Trigger Windows Scheduled Task from Remote Computer via Jenkins

One thing I love about working in Information Technology is the opportunity - the NEED - to constantly learn new things. If a week goes by in which I have not looked up something on StackOverflow or other message boards, I start lobbying my team for more challenges. This week, I learned the power of running " SCHTASKS.exe " from a command-line script for a remote server in a Microsoft Windows environment. If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one. Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we ...
Read more