Merge, update, and pull Git branches without using checkouts
The Short Answer
As long as you're doing a fast-forward merge, then you can simply use
git fetch <remote> <sourceBranch>:<destinationBranch>Examples:
# Merge local branch foo into local branch master,# without having to checkout master first.# Here `.` means to use the local repository as the "remote":git fetch . foo:master# Merge remote branch origin/foo into local branch foo,# without having to checkout foo first:git fetch origin foo:fooWhile 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, since git 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 branch feature checked out:
git fetch upstream master:masterThis use-case is so common, that you'll probably want to make an alias for it in your git configuration file, like this one:
[alias] sync = !sh -c 'git checkout --quiet HEAD; git fetch upstream master:master; git checkout --quiet -'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 updatemasterwhile you happen to have it checked-out. I think it was necessary to do with because otherwise the branch reference formasterwon'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 localmasterto 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 merges
If you want the fetch command to fail if the update is non-fast-forward, then you simply use a refspec of the form
git fetch <remote> <remoteBranch>:<localBranch>If you want to allow non-fast-forward updates, then you add a + to the front of the refspec:
git fetch <remote> +<remoteBranch>:<localBranch>Note that you can pass your local repo as the "remote" parameter using .:
git fetch . <sourceBranch>:<destinationBranch>The Documentation
From the git fetch documentation that explains this syntax (emphasis mine):
<refspec>The format of a
<refspec>parameter is an optional plus+, followed by the source ref<src>, followed by a colon:, followed by the destination ref<dst>.The remote ref that matches
<src>is fetched, and if<dst>is not empty string, the local ref that matches it is fast-forwarded using<src>. If the optional plus+is used, the local ref is updated even if it does not result in a fast-forward update.
See Also
No, there is not. A checkout of the target branch is necessary to allow you to resolve conflicts, among other things (if Git is unable to automatically merge them).
However, if the merge is one that would be fast-forward, you don't need to check out the target branch, because you don't actually need to merge anything - all you have to do is update the branch to point to the new head ref. You can do this with git branch -f:
git branch -f branch-b branch-aWill update branch-b to point to the head of branch-a.
The -f option stands for --force, which means you must be careful when using it.
Don't use it unless you are absolutely sure the merge will be fast-forward.
As Amber said, fast-forward merges are the only case in which you could conceivably do this. Any other merge conceivably needs to go through the whole three-way merge, applying patches, resolving conflicts deal - and that means there need to be files around.
I happen to have a script around I use for exactly this: doing fast-forward merges without touching the work tree (unless you're merging into HEAD). It's a little long, because it's at least a bit robust - it checks to make sure that the merge would be a fast-forward, then performs it without checking out the branch, but producing the same results as if you had - you see the diff --stat summary of changes, and the entry in the reflog is exactly like a fast forward merge, instead of the "reset" one you get if you use branch -f. If you name it git-merge-ff and drop it in your bin directory, you can call it as a git command: git merge-ff.
#!/bin/bash_usage() { echo "Usage: git merge-ff <branch> <committish-to-merge>" 1>&2 exit 1}_merge_ff() { branch="$1" commit="$2" branch_orig_hash="$(git show-ref -s --verify refs/heads/$branch 2> /dev/null)" if [ $? -ne 0 ]; then echo "Error: unknown branch $branch" 1>&2 _usage fi commit_orig_hash="$(git rev-parse --verify $commit 2> /dev/null)" if [ $? -ne 0 ]; then echo "Error: unknown revision $commit" 1>&2 _usage fi if [ "$(git symbolic-ref HEAD)" = "refs/heads/$branch" ]; then git merge $quiet --ff-only "$commit" else if [ "$(git merge-base $branch_orig_hash $commit_orig_hash)" != "$branch_orig_hash" ]; then echo "Error: merging $commit into $branch would not be a fast-forward" 1>&2 exit 1 fi echo "Updating ${branch_orig_hash:0:7}..${commit_orig_hash:0:7}" if git update-ref -m "merge $commit: Fast forward" "refs/heads/$branch" "$commit_orig_hash" "$branch_orig_hash"; then if [ -z $quiet ]; then echo "Fast forward" git diff --stat "$branch@{1}" "$branch" fi else echo "Error: fast forward using update-ref failed" 1>&2 fi fi}while getopts "q" opt; do case $opt in q ) quiet="-q";; * ) ;; esacdoneshift $((OPTIND-1))case $# in 2 ) _merge_ff "$1" "$2";; * ) _usageesacP.S. If anyone sees any issues with that script, please comment! It was a write-and-forget job, but I'd be happy to improve it.