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

Git can include many files in a single commit. You can modify, add, or delete multiple files, then commit the new state of the working directory. What if we deleted multiple files, and now we need to recover in Git some but not all of what has been deleted? Since Git tracks the state of our repository as a series of snapshots (aka Commits) in time, we can recover the file by looking at a past snapshot / commit and “checking out” the resource(s) we must recover. For example: Let's say that a few days ago I deleted several files from the Git repository. I deleted them on my local, committed the change, and pushed to the server. Other developers have done many other commits since then. Now, it turns out one of the files is needed after all, but the others should remain deleted. How to get the one file back? I will show some Git command-line steps to retrieve it. There are other ways, using your IDE, File Explorer, Tortoise or your UI of choice. But the command-l...

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.

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