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.
If the unwanted commit has not yet been pushed upstream, try this:
Make a backup copy of the work-in-progress file, because these steps will reset it to the last committed version before your commit.
Go to your History view, you should see the 2 commits of which we only want 1.
On the History view, highlight the commit BEFORE them in the history. Right-click and select Rebase Interactive.
In the Rebase Interactive view, highlight the bad commit and click on “Skip” It should change the Action scheduled for that commit.
Click “Start” and Eclipse will perform a rebase, skipping the bad commit (essentially deleting it from your local – with all your in-progress changes).
In your history view you should have just the one, desired commit. Push it upstream.
Put your in-progress changes back in place from your backup of the file.
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 3rd 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 to do a pull so that I could push the 2
needed files, I was forced to commit my changes to the 3rd file or
lose them. I didn’t want to lose them, so I committed them.
But I need to push the 2 good files and I don’t want to break
things by pushing the 3rd not-yet-ready file.
What do I do?????
(end email excerpt)
I can see from the scenario that my colleague had not been doing her development in a Feature Branch, but rather was doing all her work on her local main dev branch. So my follow-up with her included (once again) stressing local feature branches off the dev branch as a recommended practice.
Then, when something like this comes up, you can stash the in-progress changes in the branch, check out the dev branch to change/commit/push, and then check out the feature branch again and restore the stash.
That advice can help my colleague avoid the issue in the future. But how to get out of the present bind? I told her something like the following:
I can see from the scenario that my colleague had not been doing her development in a Feature Branch, but rather was doing all her work on her local main dev branch. So my follow-up with her included (once again) stressing local feature branches off the dev branch as a recommended practice.
Then, when something like this comes up, you can stash the in-progress changes in the branch, check out the dev branch to change/commit/push, and then check out the feature branch again and restore the stash.
That advice can help my colleague avoid the issue in the future. But how to get out of the present bind? I told her something like the following:
If you have already pushed the
unwanted commit upstream, consider it to be “set in stone” and you should proceed like any
other bug fix. Since the unwanted commit likely broke the build, you should give your full attention to fixing or restoring it to a compiling / running state.
If the unwanted commit has not yet been pushed upstream, try this:
Make a backup copy of the work-in-progress file, because these steps will reset it to the last committed version before your commit.
Go to your History view, you should see the 2 commits of which we only want 1.
On the History view, highlight the commit BEFORE them in the history. Right-click and select Rebase Interactive.
In the Rebase Interactive view, highlight the bad commit and click on “Skip” It should change the Action scheduled for that commit.
Click “Start” and Eclipse will perform a rebase, skipping the bad commit (essentially deleting it from your local – with all your in-progress changes).
In your history view you should have just the one, desired commit. Push it upstream.
Put your in-progress changes back in place from your backup of the file.
For further reading, check out some of these links: