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
The Short Answer
As long as you're doing a fast-forward merge, then you can simply use
Examples:
While Amber's answer will also work in fast-forward cases, using
git fetch
in this way instead is a little safer than just force-moving the branch reference, sincegit fetch
will automatically prevent accidental non-fast-forwards as long as you don't use+
in the refspec.The Long Answer
You cannot merge a branch B into branch A without checking out A first if it would result in a non-fast-forward merge. This is because a working copy is needed to resolve any potential conflicts.
However, in the case of fast-forward merges, this is possible, because such merges can never result in conflicts, by definition. To do this without checking out a branch first, you can use
git fetch
with a refspec.Here's an example of updating
master
(disallowing non-fast-forward changes) if you have another branchfeature
checked out:This use-case is so common, that you'll probably want to make an alias for it in your git configuration file, like this one:
What this alias does is the following:
git checkout HEAD
: this puts your working copy into a detached-head state. This is useful if you want to updatemaster
while you happen to have it checked-out. I think it was necessary to do with because otherwise the branch reference formaster
won't move, but I don't remember if that's really right off-the-top of my head.git fetch upstream master:master
: this fast-forwards your localmaster
to the same place asupstream/master
.git checkout -
checks out your previously checked-out branch (that's what the-
does in this case).The syntax of
git fetch
for (non-)fast-forward mergesIf you want the
fetch
command to fail if the update is non-fast-forward, then you simply use a refspec of the formIf you want to allow non-fast-forward updates, then you add a
+
to the front of the refspec:Note that you can pass your local repo as the "remote" parameter using
.
:The Documentation
From the
git fetch
documentation that explains this syntax (emphasis mine):See Also
Git checkout and merge without touching working tree
Merging without changing the working directory