Skip to main content

Multiple Remote Git Repositories and Branches in Eclipse

Sometimes, when using Git repositories and the Eclipse IDE, we want to access other remote repositories within the one we are currently using.

One example, which I will use as the scenario for the steps below: a team converted existing code and its history to Git from another source-control management tool, with separate repositories for closely related but distinct release points. When they need to make a fix to a past release, on the past release's "hotfix" branch, they want to do as little work as possible to bring that fix into the current cutting-edge "dev" branch of their main repository.

Other writers have offered How-To's for the git command-line steps to do so. What I will do is to show how the setup and configuration can be done within the Eclipse IDE (I used Mars for the screen-shots).


You can use Eclipse to set up one repository with branches from another remote repository. This opens possibilities such as using Git's Cherry-pick feature between the dev branch and another repository’s hotfix branch.

First, add the Past-Release repository as a Remote for your local copy of the main repository:
  • in Git Repositories view, expand the main repository and right-click on Remotes
  • select Create Remote
  • give it a name that is meaningful to you, it does not have to match the name of the Remote repository
  • select "Configure fetch" - we will handle the Push later



  • click OK
  • on the Configure Fetch dialog, enter the Remote URI
  • click Save and Fetch



The result should be new entries under Remotes and under Branches - Remote Tracking for your local Repository:

Next, create a new Local branch for the hotfix branch of the Remote:
  • right-click on the repository or the Branches and select Switch to.. New Branch
  • in the dialog, click the Select button and choose the "hotfix" branch of your new Remote Tracking repository as the Source for this new branch. Click OK


  • give the new branch a meaningful name, it does not have to be "hotfix" if you prefer something like "1602_hotfix" or another name
  • check "Configure upstream for push and pull" and select "Rebase commits of local branch onto upstream"
  • to work on this branch right away, check "Checkout new branch"


Now you can make changes directly on this new local branch, or cherry-pick commits between branches, since you now have the hotfix branch in the same local repository as the dev branch.

Once you have made and saved changes on your local hotfix branch, be sure to select “Commit” in the Git staging area, not "Commit and Push" – we want to do a quick double-check of our settings before we Push.

When a hotfix Commit is ready to Push:
  • right-click and select "Push Branch..."
  • verify that Source is your local branch and correct commit, and that Destination is the Remote repository with Branch = "hotfix"
  • click "Next"



  • on the Push Confirmation dialog, select "Cancel push if ... changes on remote" (if you hate pop-ups, also check "Show dialog...")
  • click "Finish"


The result should be that the upstream release repository receives the hotfix changes, without needing to make the changes multiple times or doing any copy-pasting.

Remember:
Be careful with your own scenarios that mix the dev branch and hotfix branches - they should not be Merged or Rebased with each other. While the repositories in this scenario have a common history to a point, they have diverged since, and attempting to merge them will produce many conflicts or other questionable results.

Labels:

Popular posts from this blog

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
Read more

Java 8: Rewrite For-loops using Stream API

Java 8 Tip: Anytime you write a Java For-loop, ask yourself if you can rewrite it with the Streams API. Now that I have moved to Java 8 in my work and home development, whenever I want to use a For-loop, I write it and then see if I can rewrite it using the Stream API. For example: I have an object called myThing, some Collection-like data structure which contains an arbitrary number of Fields. Something has happened, and I want to set all of the fields to some common state, in my case "Hidden"
Read more

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

Code Coverage in C#.NET Unit Tests - Setting up OpenCover

The purpose of this post is to be a brain-dump for how we set up and used OpenCover and ReportGenerator command-line tools for code coverage analysis and reporting in our projects. The documentation made some assumptions that took some digging to fully understand, so to save my (and maybe others') time and effort in the future, here are my notes. Our project, which I will call CEP for short, includes a handful of sub-projects within the same solution. They are a mix of Web APIs, ASP MVC applications and Class libraries. For Unit Tests, we chose to write them using the MSTest framework, along with the Moq mocking framework. As the various sub-projects evolved, we needed to know more about the coverage of our automated tests. What classes, methods and instructions had tests exercising them, and what ones did not? Code Coverage tools are conveniently built-in for Visual Studio 2017 Enterprise Edition, but not for our Professional Edition installations. Much less for any Commun
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