The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard
option).
Suppose the old commit was HEAD@{2}
in the ref log:
git reset --hard HEAD@{2}
In Windows, you may need to quote the reference:
git reset --hard "HEAD@{2}"
You can check the history of the candidate old head by just doing a git log HEAD@{2}
(Windows: git log "HEAD@{2}"
).
If you've not disabled per branch reflogs you should be able to simply do git reflog branchname@{1}
as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven't verified this recently.
Per default, all reflogs are activated for non-bare repositories:
[core]
logAllRefUpdates = true
Try: git mergetool
It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.
As per Josh Glover's comment:
The command
doesn't necessarily open a GUI unless you install one. Running git mergetool
for me resulted in vimdiff
being used. You can install
one of the following tools to use it instead: meld
, opendiff
,
kdiff3
, tkdiff
, xxdiff
, tortoisemerge
, gvimdiff
, diffuse
,
ecmerge
, p4merge
, araxis
, vimdiff
, emerge
.
Below is the sample procedure to use vimdiff
for resolve merge conflicts. Based on this link
Step 1: Run following commands in your terminal
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false
This will set vimdiff as the default merge tool.
Step 2: Run following command in terminal
git mergetool
Step 3: You will see a vimdiff display in following format
╔═══════╦══════╦════════╗
║ ║ ║ ║
║ LOCAL ║ BASE ║ REMOTE ║
║ ║ ║ ║
╠═══════╩══════╩════════╣
║ ║
║ MERGED ║
║ ║
╚═══════════════════════╝
These 4 views are
LOCAL – this is file from the current branch
BASE – common ancestor, how file looked before both changes
REMOTE – file you are merging into your branch
MERGED – merge result, this is what gets saved in the repo
You can navigate among these views using ctrl+w. You can directly reach MERGED view using ctrl+w followed by j.
More information about vimdiff navigation is here and here.
Step 4. You could edit the MERGED view the following way
If you want to get changes from REMOTE
:diffg RE
If you want to get changes from BASE
:diffg BA
If you want to get changes from LOCAL
:diffg LO
Step 5. Save, Exit, Commit and Clean up
:wqa
save and exit from vi
git commit -m "message"
git clean
Remove extra files (e.g. *.orig) created by diff tool.
Best Answer
Both
rebase
(andcherry-pick
) andmerge
have their advantages and disadvantages. I argue formerge
here, but it's worth understanding both. (Look here for an alternate, well-argued answer enumerating cases whererebase
is preferred.)merge
is preferred overcherry-pick
andrebase
for a couple of reasons.merge
workflow fairly easily.rebase
tends to be considered more advanced. It's best to understand both, but people who do not want to be experts in version control (which in my experience has included many colleagues who are damn good at what they do, but don't want to spend the extra time) have an easier time just merging.Even with a merge-heavy workflow
rebase
andcherry-pick
are still useful for particular cases:merge
is cluttered history.rebase
prevents a long series of commits from being scattered about in your history, as they would be if you periodically merged in others' changes. That is in fact its main purpose as I use it. What you want to be very careful of, is never torebase
code that you have shared with other repositories. Once a commit ispush
ed someone else might have committed on top of it, and rebasing will at best cause the kind of duplication discussed above. At worst you can end up with a very confused repository and subtle errors it will take you a long time to ferret out.cherry-pick
is useful for sampling out a small subset of changes from a topic branch you've basically decided to discard, but realized there are a couple of useful pieces on.As for preferring merging many changes over one: it's just a lot simpler. It can get very tedious to do merges of individual changesets once you start having a lot of them. The merge resolution in git (and in Mercurial, and in Bazaar) is very very good. You won't run into major problems merging even long branches most of the time. I generally merge everything all at once and only if I get a large number of conflicts do I back up and re-run the merge piecemeal. Even then I do it in large chunks. As a very real example I had a colleague who had 3 months worth of changes to merge, and got some 9000 conflicts in 250000 line code-base. What we did to fix is do the merge one month's worth at a time: conflicts do not build up linearly, and doing it in pieces results in far fewer than 9000 conflicts. It was still a lot of work, but not as much as trying to do it one commit at a time.