SJGP Software

This post describes the real-world scenario, then offers the steps to solve the issue at the bottom. If you are in a hurry, jump to the end of the post to see the steps in Eclipse, without my self-indulgent story-telling! A few months ago, my team switched from the ancient Visual SourceSafe to Git. While we tried to minimize the process impact, the change-over was such a big shift in thinking that, months later, I still field several questions a week. Here is a recent trouble-shooting sample: a colleague got caught in mid-task with an urgent fix, and mucked up some commits in her local repository. Her question: how can only the fix-commit be pushed. Email excerpt: Hey Steve! Okay - so I have 2 files that I need to push to repository X for a high priority fix for tomorrow. I have a 3 rd file that I was in the middle of changing when I had to interrupt to get the high priority one fixed and in.  It is currently in a state of flux and full of errors. But when I went...

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).

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 ...

Note: I led the project to convert a team's Source Control Management tool and processes from Microsoft Visual SourceSafe to Git. This is an edited version of a How-To document I wrote and distributed in response to some questions about Merge vs Rebase in Eclipse. As you know, I’ve been recommending using local Git branches to separate your projects. By that, I mean create a branch from the Dev branch, make your changes and commit them as often as necessary to your local branch, switch branches when you need to switch projects, etc. One side-effect of using local branches is that when you bring your work into the main Dev branch, it leaves a new commit, a Merge commit. This means that, even though we do not have feature branches on the server, we can still wind up with a history that looks like this on the server: We wind up with the clutter of parallel lines showing the life spans of our local branches, and extra commits (nine in the above screen-shot, marked by the...