Merge, update, and pull Git branches without using checkouts

Question

I work on a project that has 2 branches, A and B. I typically work on branch A, and merge stuff from branch B. For the merging, I would typically do:

git merge origin/branchB

However, I would also like to keep a local copy of branch B, as I may occasionally check out the branch without first merging with my branch A. For this, I would do:

git checkout branchB
git pull
git checkout branchA

Is there a way to do the above in one command, and without having to switch branch back and forth? Should I be using git update-ref for that? How?

Ploughman

related: #1403493 and #3409032 – Aarika

Jakub's answer to the first linked question explains why this is in general impossible. Another (a posteriori) explanation is that you can't merge in a bare repo, so clearly it requires the work tree. – Aarika

@Eric: The common reasons are that checkouts are time-consuming for large repos, and that they update timestamps even if you return to the same version, so make thinks everything needs to be rebuild. – Aarika

The second question I linked is asking about an unusual case - merges which could be fast-forwards, but which the OP wanted to merge using the --no-ff option, which causes a merge commit to be recorded anyway. Should you be interested in that, my answer there shows how you could do that - not quite as robust as my posted answer here, but the strengths of the two could certainly be combined. – Aarika

See also Merging without changing the working directory. – Superincumbent

Answer 1

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:foo

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, 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:master

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:

[alias]
    sync = !sh -c 'git checkout --quiet HEAD; git fetch upstream master:master; git checkout --quiet -'

What this alias does is the following:

1. git checkout HEAD: this puts your working copy into a detached-head state. This is useful if you want to update master while you happen to have it checked-out. I think it was necessary to do with because otherwise the branch reference for master won't move, but I don't remember if that's really right off-the-top of my head.

2. git fetch upstream master:master: this fast-forwards your local master to the same place as upstream/master.

3. 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

1. Git checkout and merge without touching working tree

2. Merging without changing the working directory

Superincumbent

git checkout --quiet HEAD is git checkout --quiet --detach as of Git 1.7.5. – Chloras

Great answer, +1, helped me a lot! Two errata though: Command sh doesn't like semicolon to separate commands; use && instead. Also in #2, "git fetch upstream... as origin/master" should be "as upstream/master". – Imbroglio

I found I had to do: git fetch . origin/foo:foo to update my local foo to my local origin/foo – Laskowski

Whole sync alias should be enclosed in double quotes – Hurling

Is there a reason the "git checkout HEAD --quiet" and "git checkout --quiet -" parts are included in the long answer, but not the short answer? I guess it's because the script may be run when you have master checked out, even though you could just do a git pull? – Overrate

git fetch upstream master:master is so awesome! Because I don't have to do checkouts first and checking out in my repository is a costly action. – Unapt

why is 'fetch' the command to do 'merge' here... it simply doesn't make sense; If 'pull' is 'fetch' followed by 'merge', there must be a more logical 'merge --ff-only' equivalent which would update 'branch' from 'origin/branch' locally, given that a 'fetch' has already been run. – Dina

Adding flag -u ensures the command succeeds even if you have the given branch checked out. git fetch -u origin master:master. Otherwise fails with fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository – Rothberg

@pkamb: that's what the git checkout --quiet --detach is for, to detach HEAD so that you can fetch into what was, but is no longer, the current branch. Do not add -u to the fetch command unless you are sure you know what you are doing! – Tonie

What's the difference between git fetch . origin/foo:foo and git pull then? – Reclusion

@Reclusion I'm sure of one difference which is that git pull can causes a merge if your local foo has diverted from origin/foo – Tejeda

In your 2nd example, this: Merge remote branch origin/foo into local branch foo, should actually say this, no? Merge remote branch origin/foo into local remote-tracking branch origin/foo, as well as into local branch foo. – Stripper

The + option is dangerous, it could erase local changes and replace them with the remote. The proper way of dealing with this is to use a plain fetch and merge form the remote tracking branch: git fetch && git merge origin/branchB. If needed you can update your local branch with a git pull later. – Evincive

How to fast forward all remote tracking branches after git fetch -ap without specifying remote, branch names, checking out? Current branch should be also fast forwarded if working directory is clean. Warning message otherwise. – Terraqueous

Is it need to use git push origin master after git fetch . foo:master? Is there any way to directly push with using 1st command? – Carport

It looks like git has issues with expanding command args ($1), at least in my case (git 2.39.2, zsh 2.9, macOS 13.4). Here's the alias I originally tried: !git switch --detach; git fetch origin $1:$1; git switch - When I run git sync master, it actually expands this to git switch --detach; git fetch origin master:master; git switch - master (note the extra master at the end), which was leading to fatal: only one reference expected error in the last command. I ended up with this syntax: '!git switch --quiet --detach; git fetch origin $1:$1; git switch --quiet -; :' – Rhombus

Answer 2

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-a

Will update branch-b to point to the head of branch-a.

The -f option stands for --force, which means branch-b will be overwritten.

Caution: A safer option is using git fetch which will only allow a fast-forward.

This method can be used like so:

git branch -f branch-b branch-b@{Upstream}

or shorter

git branch -f branch-b branch-b@{U}

To force update a branch, without checking it out (say if they have diverged after rebase)

Mcbee

Just be very careful not to do that unless you've made absolutely sure the merge would be a fast-forward! Don't want to realize later you've misplaced commits. – Aarika

@FuadSaud Not exactly. git reset only works on the currently checked-out branch. – Mcbee

The same result (fast-forwarding) is achieved by git fetch upstream branch-b:branch-b (taken from this answer). – Loner

To expand on @Oliver's comment, you can also do git fetch <remote> B:A, where B and A are completely different branches, but B can be fast-forward merged into A. You can also pass your local repository as the "remote" using . as the remote alias: git fetch . B:A. – Superincumbent

I know this is old but: is it possible to make sure that a merge would be a fast forward without a checkout of the target branch? Even if it is possible, there could be race conditions? That is, merge would have been a ff when I checked but by the time I actually update the head ref it is no longer the case. – Michi

The OP's question makes it fairly clear that the merge will indeed be fast-forward. Regardless, branch -f could be dangerous, as you point out. So don't use it! Use fetch origin branchB:branchB, which will fail safely if the merge isn't fast-forward. – Giacometti

I can't agree with the suggestion of using --force for something that is done daily. – Lully

In case you've run into a problem by (force) moving branches, use git reflog to find any lost commits. – Tamaratamarack

This is dangerous and unneeded as the OP only wishes to merge the remote tracking branch. All he is missing is a simple and safe git fetch – Evincive

In my case, I had accidentally committed on my local PROD branch before switching to my feature experimental branch. So all the commits on my local PROD were safe, but my local did not (and will not) go onto origin/PROD. So I needed to reset my branch, without switching to that branch. git branch -f PROD origin/PROD works where git branch -C PROD origin/PROD does not (-C does wonky stuff, creates a branch called 'origin/Prod', or in the reverse, looks for a local branch called 'origin/PROD', while -f makes it act like switch -C). – Mcburney

@Aarika you can git branch -f branch branch@{1} to reset it back to the last tip – Paucker

Answer 3

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";;
        * ) ;;
    esac
done
shift $((OPTIND-1))

case $# in
    2 ) _merge_ff "$1" "$2";;
    * ) _usage
esac

P.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.

Aarika

you might be interested in https://mcmap.net/q/54875/-how-do-i-fast-forward-other-tracking-branches-in-git for comparison – Brazilin

@PhilipOakley From a quick look, that at the core does exactly the same thing as mine. But mine isn't hardcoded to a single pair of branches, it has a lot more error handling, it simulates the output of git-merge, and it does what you mean if you call it while you're actually on the branch. – Aarika

I do have yours in my \bin directory ;-) I'd just forgotten about it and was looking around, saw that script and it prompted my recall! My copy does have this link and # or git branch -f localbranch remote/remotebranch to remind me of the source and the options. Gave your comment on the other link a +1. – Brazilin

+1, can also default to "$branch@{u}" as the committish to merge to get the upstream branch (from kernel.org/pub/software/scm/git/docs/gitrevisions.html) – Intransigent

Thanks for the nice script (still relevant 8 years later)! I've made 2 minor improvements: use git show-ref --abbrev ... instead of hardcoding 0:7 as modern versions of Git use longer SHA-1 prefixes by default, so it makes the output more consistent; and also check that $branch_orig_hash != $commit_orig_hash to avoid misleading reflog entry and diff output if there are actually no changes at all. – Salvo

Answer 4

You can only do this if the merge is a fast-forward. If it's not, then git needs to have the files checked out so it can merge them!

To do it for a fast-forward only:

git fetch <branch that would be pulled for branchB>
git update-ref -m "merge <commit>: Fast forward" refs/heads/<branch> <commit>

where <commit> is the fetched commit, the one you want to fast-forward to. This is basically like using git branch -f to move the branch, except it also records it in the reflog as if you actually did the merge.

Please, please, please don't do this for something that's not a fast-forward, or you'll just be resetting your branch to the other commit. (To check, see if git merge-base <branch> <commit> gives the branch's SHA1.)

Aarika

Is there a way to make it fail if it can't fast forward? – Unionist

@Unionist you can use git merge-base --is-ancestor <A> <B> . "B" being the thing that needs to be merged into "A". Example would be A=master and B=develop, making sure develop is fast-forwardable into master. Note: It exist with 0 if its not ff-able, exists with 1 if it is. – Tevet

Not documented in git-scm, but it is on kernal.org. kernel.org/pub/software/scm/git/docs/git-merge-base.html – Tevet

Made a quick gist to wrap up what im talking about (didn't actually test it, but should get you mostly there). gist.github.com/eddiemoya/ad4285b2d8a6bdabf432 ---- as a side note, I had most of this handy, I've got a script that checks for ff and if not lets you rebase the desired branch first - then ff merges - all without checking anything out. – Tevet

Answer 5

In your case you can use

git fetch origin branchB:branchB

which does what you want (assuming the merge is fast-forward). If the branch can't be updated because it requires a non-fast-forward merge, then this fails safely with a message.

This form of fetch has some more useful options too:

git fetch <remote> <sourceBranch>:<destinationBranch>

Note that <remote> can be a local repository, and <sourceBranch> can be a tracking branch. So you can update a local branch, even if it's not checked out, without accessing the network.

Currently, my upstream server access is via a slow VPN, so I periodically connect, git fetch to update all remotes, and then disconnect. Then if, say, the remote master has changed, I can do

git fetch . remotes/origin/master:master

to safely bring my local master up to date, even if I currently have some other branch checked out. No network access required.

Giacometti

Answer 6

Another, admittedly pretty brute way is to just re-create the branch:

git fetch remote
git branch -f localbranch remote/remotebranch

This throws away the local outdated branch and re-creates one with the same name, so use with care ...

Zoila

I just saw now that the original answer already mentions branch -f ... Still, I don't see an advantage in having the merge in the reflog for the use case originally described. – Zoila

Answer 7

You can clone the repo and do the merge in the new repo. On the same filesystem, this will hardlink rather than copy most of the data. Finish by pulling the results into the original repo.

Correspond

Answer 8

Enter git-forward-merge:

Without needing to checkout destination, git-forward-merge <source> <destination> merges source into destination branch.

https://github.com/schuyler1d/git-forward-merge

Only works for automatic merges, if there are conflicts you need to use the regular merge.

Pembrook

I think this is better than git fetch <remote> <source>:<destination>, because a fast forward is an operation of merge not fetch and it is easier to write. Bad thing though, it is not in the default git. – Needlewoman

Answer 9

There is something I am missing from the question, why would you need to checkout the local branchB if you have no intent on working on it? In your example you just want to update the local branchB while on remaining on branchA?

I originally assumed you were doing so to fetch origin/branchB, which you can already do with git fetch, so this answer is really based on this. There is no need to pull branchB until you need to work on it, and you can always fetch origin when you need to merge from origin/branchB.

If you want to keep track of where branchB is at at a point in time, you can create a tag or another branch from the latest fetch of origin/branchB.

So all you should need ever need to merge from origin/branchB:

git fetch
git merge origin/branchB

Then next time you need to work on branchB:

git checkout branchB
git pull

At this point you will get an updated local copy. While there are ways to do it without checking out, this is the rarely useful and can be unsafe in some cases. There are existing answers covering this.

Detailed answer:

git pull does a fetch + merge. It's roughly the the same the two commands below, where <remote> is usually origin (default), and the remote tracking branch starts with <remote>/ followed by the remote branch name:

git fetch [<remote>]
git merge @{u}

The @{u} notation is the configured remote tracking branch for the current branch. If branchB tracks origin/branchB then @{u} from branchB is the same as typing origin/branchB (see git rev-parse --help for more info).

Since you already merge with origin/branchB, all that is missing is the git fetch (which can run from any branch) to update that remote-tracking branch.

Note though that if there was any merge created while pulling into local branchB, you should rather merge branchB into branchA after having done a pull from branchB (and eventually push the changes back to orign/branchB, but as long as they're fast-forward they would remain the same).

Keep in mind the local branchB will not be updated until you switch to it and do an actual pull, however as long as there are no local commits added to this branch it will just remain a fast-forward to the remote branch.

Evincive

No, the OP asks to merge upstream origin/branchB into his local branchB while having checked out branchA locally. – Snowberry

@HolgerBöhnke you're right, I misread this, yet at the same time I cannot make much sends of the OP question then. Why would he want to checkout branchB if there is no intend to work on it? I feel it's missing something... He doesn't need to checkout the local branchB to merge with origin/branchB, thich is what I assumed the issue was. In any case I will clarify my answer, thanks. – Evincive

You are right. If you don't work with branchB, you might as well just not check it out. The branch get's tracked automatically as origin/branchB and once you need it, you'll create a local branch and check it out. If you think of branches as movable pointers that point to a specific commit within the git commit graph it helps a lot for understanding. – Snowberry

There are perfectly valid reasons to update a local branch, without wanting to checkout. It's not going to be the most common situation but it can be appropriate – Paucker

Answer 10

For many GitFlow users the most useful commands are:

git fetch origin master:master --update-head-ok
git fetch origin dev:dev --update-head-ok

The --update-head-ok flag allows using the same command while on dev or master branches.

A handy alias in .gitconfig:

[alias]
    f=!git fetch origin master:master --update-head-ok && git fetch origin dev:dev --update-head-ok

Litt

Beware the documentation on git fetch "--update-head-ok" says "This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it." – Hillari

Answer 11

For many cases (such as merging), you can just use the remote branch without having to update the local tracking branch. Adding a message in the reflog sounds like overkill and will stop it being quicker. To make it easier to recover, add the following into your git config

[core]
    logallrefupdates=true

Then type

git reflog show mybranch

to see the recent history for your branch

Altazimuth

I think the section must be [core] not [user]? (and it is by default on, for repos with a workspace (i.e. non-bare). – Bossuet

Answer 12

I wrote a shell function for a similar use case I encounter daily on projects. This is basically a shortcut for keeping local branches up to date with a common branch like develop before opening a PR, etc.

Posting this even though you don't want to use checkout, in case others don't mind that constraint.

glmh ("git pull and merge here") will automatically checkout branchB, pull the latest, re-checkout branchA, and merge branchB.

Doesn't address the need to keep a local copy of branchA, but could easily be modified to do so by adding a step before checking out branchB. Something like...

git branch ${branchA}-no-branchB ${branchA}

For simple fast-forward merges, this skips to the commit message prompt.

For non fast-forward merges, this places your branch in the conflict resolution state (you likely need to intervene).

To setup, add to .bashrc or .zshrc, etc:

glmh() {
    branchB=$1
    [ $# -eq 0 ] && { branchB="develop" }
    branchA="$(git branch | grep '*' | sed 's/* //g')"
    git checkout ${branchB} && git pull
    git checkout ${branchA} && git merge ${branchB} 
}

Usage:

# No argument given, will assume "develop"
> glmh

# Pass an argument to pull and merge a specific branch
> glmh your-other-branch

Note: This is not robust enough to hand-off of args beyond branch name to git merge

Moton

Parsing the output of git branch might be a bad idea, it could be modified by config/etc, it's meant for human consumption. Use git symbolic-ref --short HEAD instead. Also the first two lines can be combined: branchB=${1:-develop}. – Evincive

Answer 13

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]

You can try git worktree to have two branches open side by side, this sounds like it might be what you want but very different than some of the other answers I've seen here.

In this way you can have two separate branches tracking in the same git repo so you only have to fetch once to get updates in both work trees (rather than having to git clone twice and git pull on each)

Worktree will create a new working directory for your code where you can have a different branch checked out simultaneously instead of swapping branches in place.

When you want to remove it you can clean up with

git worktree remove [-f] <worktree>

Plato

Just used this! Loved the solution and learning this new git command. Thank you – Fadiman

Answer 14

Another way to effectively do this is:

git fetch
git branch -d branchB
git branch -t branchB origin/branchB

Because it's a lower case -d, it will only delete it if the data will still exist somewhere. It's similar to @kkoehne's answer except it doesn't force. Because of the -t it will set up the remote again.

I had a slightly different need than OP, which was to create a new feature branch off develop (or master), after merging a pull request. That can be accomplished in a one-liner without force, but it doesn't update the local develop branch. It's just a matter of checking out a new branch and having it be based off origin/develop:

git checkout -b new-feature origin/develop

Pinchas

Answer 15

just to pull the master without checking out the master I use

git fetch origin master:master

Graceless

Answer 16

It is absolutely possible to do any merge, even non-fast forward merges, without git checkout. The worktree answer by @grego is a good hint. To expand on that:

cd local_repo
git worktree add _master_wt master
cd _master_wt
git pull origin master:master
git merge --no-ff -m "merging workbranch" my_work_branch
cd ..
git worktree remove _master_wt

You have now merged the local work branch to the local master branch without switching your checkout.

Portsmouth

isn't git worktree add effectively does a checkout? but you don't need to clone the repo. – Fabien

I guess it depends on what you mean by a checkout... It does load the branch history, but that's unavoidable for the general case AFAIK. It does not replace the existing checkout/branch, though. The question asked is slightly different than the title, so... – Portsmouth

Answer 17

If you want to keep the same tree as one of the branch you want to merge (ie. not a real "merge"), you can do it like this.

# Check if you can fast-forward
if git merge-base --is-ancestor a b; then
    git update-ref refs/heads/a refs/heads/b
    exit
fi

# Else, create a "merge" commit
commit="$(git commit-tree -p a -p b -m "merge b into a" "$(git show -s --pretty=format:%T b)")"
# And update the branch to point to that commit
git update-ref refs/heads/a "$commit"

Motorboat

Answer 18

This is actually quite important feature in my daily workflow. Should be documented here for reference.

Suppose I am working in a feat1 branch but I have something that should be committed into feat2, which is a branch way behind the current HEAD. I used to be doing these steps: first checkout feat2, then do a git rebase feat. But that would usually cause my running development server to detect a change and re-render to the old version, which will usually crash if your working tree is too different from the current branch. To avoid huge change of the working tree, while staying on branch feat1, I just do git fetch <repo> <src>:<dst>, in the above case that would be:

git fetch . HEAD:feat2

or

git fetch . feat1:feat2

After that feat2 will be pointing to same commit as feat1. You can then safely checkout feat2 without crashing your development server.

Obey

Welcome to StackOverflow! Can you edit and explain how this answer is different than the process described in the accepted answer? (at first glance they look the same, but I might be missing something!) – Malevolent

This appears to be a duplicate of the answer provided here – Pendentive

Answer 19

I use the following alias:

[alias]
sync = !git fetch && git fetch -u . $(git for-each-ref --format='%(push):%(refname)' refs/heads)

See https://mcmap.net/q/13034/-can-quot-git-pull-all-quot-update-all-my-local-branches for the detailed explanation

Candelabra

Answer 20

You can simply git pull origin branchB into your branchA and git will do the trick for you.

Function