|
|
|
|
|
|
by Stratoscope
2377 days ago
|
|
|
If you have to use the command line, those "gosh darn it git" sites have some good recipes. Because if the problem is "I accidentally committed to the wrong branch!" who is going to remember all this off the top of their head: # undo the last commit, but leave the changes available
git reset HEAD~ --soft
git stash
# move to the correct branch
git checkout name-of-the-correct-branch
git stash pop
git add . # or add individual files
git commit -m "your message here";
# now your changes are on the correct branch
Or you can use a powerful GUI like SmartGit. Then you don't have to memorize anything or look up a recipe. For the situation above, you simply drag your branch markers to where you want them in the log. Done!Similarly, for situations where you would look up hashes in the reflog, just click the Recyclable Commits checkbox, and everything in the reflog shows up as ordinary commits in the same commit tree as everything else. You can even see diffs between the reflog commits and your regular commits without having to do any temporary checkouts. I know many developers like the command line and don't want to consider using a GUI. But I encourage you to give SmartGit a try. It works in conjunction with the command line, so you you're not locked into the GUI, you can use either one whenever you want. |
|
|
Git reset changes the ref HEAD is pointing at. So in this case HEAD is pointing to the branch you've accidentally committed to. Running `git reset HEAD- --soft` simply moves the branch to point to one commit previous. The soft flag tells git reset to not touch any actual files while doing this, so your changes stay untouched. This is really the most complex part. After this all that's happening is re-committing the same changes to the correct branch. The git stash is even optional if the changes don't conflict with any changes done by the checkout.
You're right, memorizing a list of commands like that is a fools errand. What's not a fools errand is understanding the underlying data structure of git and how various commands act on it. Which is all documented in the official docs by the way, using a writing style that's rather readable in my opinion. Switching to a GUI wholesale is throwing out the baby with the bathwater. Using a GUI tool still requires knowing how git works to be effective.
Of course you might still argue that it's too much typing, which is probably true. Good thing git aliases got invented so even though I can recall the entire command list you mentioned from memory I'd still in practice simply run "git uncommit" since I've had that alias defined for about forever now.
This comment isn't aimed at anyone in particular and especially not at the parent comment. The parent comment just hit my grumpy button I think ;-)