779

I'd like to push and pull all the branches by default, including the newly created ones.

Is there a setting that I can define for it?

Otherwise, when I add a new branch, locally and I want to pull it from the server, what is the simplest way to do it?

I created a new branch with the same name and tried to pull but it doesn't work. Asks me for all the remote config of the branch. How do I set it.

2
  • 5
    "and tried to pull but it doesn't work". Details please. Show us what command you tried to use. Commented Dec 16, 2009 at 14:41
  • 2023, Git 2.41: git push -u --branches
    – VonC
    Commented May 18, 2023 at 21:33

15 Answers 15

1599

The simplest way is to do:

git push --all origin

This will push tags and branches.

14
  • 15
    Among dozens of answers that I found on SO and other places, this is the simplest way to push a newly created local branch, without touching configuration. Thanks! Commented Jun 24, 2012 at 15:12
  • 201
    And if you add -u once, e.g. git push --all origin -u, tracking is setup and after that you can simply use git push.
    – Alec
    Commented Aug 9, 2012 at 14:54
  • 31
    For git version 1.7.12.3 I had to use git push --tags origin to push all tags.
    – thisgeek
    Commented Oct 18, 2012 at 18:23
  • 22
    Also look at "--mirror" instead of "--all" this push more stuff
    – Loda
    Commented Jul 5, 2013 at 11:22
  • 23
    WARNING: If you have a bunch of LOCAL branches that you have not cleaned up (features, hotfix's) - or did not clean up properly (me), this will flood your remote. Damn. And we just did a pruning. Not sure why my local had so many branches left over.
    – Jack
    Commented Apr 3, 2014 at 21:15
156

With modern git you always fetch all branches (as remote-tracking branches into refs/remotes/origin/* namespace, visible with git branch -r or git remote show origin).

By default (see documentation of push.default config variable) you push matching branches, which means that first you have to do git push origin branch for git to push it always on git push.

If you want to always push all branches, you can set up push refspec. Assuming that the remote is named origin you can either use git config:

$ git config --add remote.origin.push '+refs/heads/*:refs/heads/*'
$ git config --add remote.origin.push '+refs/tags/*:refs/tags/*'

or directly edit .git/config file to have something like the following:

[remote "origin"]
        url = [email protected]:/srv/git/repo.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = +refs/tags/*:refs/tags/*
        push  = +refs/heads/*:refs/heads/*
        push  = +refs/tags/*:refs/tags/*
8
  • 4
    @Merc: git push --all origin is good for one time publishing all branches and tags, though default up till current version 'matching' semantic would mean that you would push all branches afterwards... unless you add new branch or tag. The setting to "push [...] all the branches by default" is as written. Commented Sep 16, 2013 at 12:51
  • You could improve the answer to add the way to reconfigure Git this way. This is useful for users having set the simple mode.
    – Dereckson
    Commented Feb 20, 2014 at 13:54
  • 3
    This has changed since git 2.0. Push default is simple, not matching any more.
    – mike
    Commented Sep 7, 2014 at 13:17
  • 1
    @BrianLacy it looks to me like you have quotes around the refspec in the configuration. Just open config file in editor and check. Commented Dec 23, 2015 at 8:49
  • 2
    Now default value for push.default is simple. Commented Apr 21, 2016 at 7:36
44

I had used below commands to migrate all branches to the new repository.

~$ git clone --mirror <url_of_old_repo>
~$ cd <name_of_old_repo>
~$ git remote add new-origin <url_of_new_repo>
~$ git push new-origin master
~$ git push new-origin --mirror

NOTE: I had to use second last (i.e. push master first) command while cloning a repo from Atlassian Stash to AWS CodeCommit (blank repo). I am not sure the reason, but after pushing (git push new-origin --mirror) default branch was referring to some other branch than master.

7
  • 1
    Perfect for moving a repo to another host. Thank you!
    – Pelmered
    Commented Jul 5, 2016 at 10:04
  • 2
    This is indeed only useful method. Use git push new_origin --alljust push your current local branches to new_origin, not all branches of origin. Commented Aug 31, 2016 at 15:38
  • Just noting that this makes a --bare repository, which is a bit different from a regular repository, it only has the .git files, not your files. It's perfectly enough if you are not going to do work in it. See --bare and --mirror git-scm.com/docs/git-clone.
    – jmmut
    Commented Oct 20, 2016 at 8:14
  • All though it only has the .git files and not the actual source code, if you perform a remote update it will re-fetch everything from the origin to the destination.
    – SanthoshM
    Commented Aug 1, 2017 at 18:21
  • 1
    This did not work for me for some reason... Maybe because my repository was private. Anyways I found more info here: docs.github.com/en/repositories/… and used the step, which is pretty much the same and it worked. Just FYI, had made my source and target, public. Commented Mar 18, 2022 at 2:36
33

Including the + in the push spec is probably a bad idea, as it means that git will happily do a non-fast-forward push even without -f, and if the remote server is set up to accept those, you can lose history.

Try just this:

$ git config --add remote.origin.push 'refs/heads/*:refs/heads/*'
$ git config --add remote.origin.push 'refs/tags/*:refs/tags/*'
$ git config --add remote.origin.fetch 'refs/heads/*:refs/remotes/origin/*'
$ git config --add remote.origin.fetch 'refs/tags/*:refs/tags/*'
2
  • You can also add the --global option to each of these to make this the global default for all your repositories.
    – Ether
    Commented Feb 6, 2012 at 18:47
  • It is unfortunate that the + is added automatically by git when doing git remote add.
    – Ether
    Commented Feb 7, 2012 at 19:24
16

If you are moving branches to a new repo from an old one and do NOT have all the old repo branches local, you will need to track them first.

for remote in `git branch -r | grep -v '\->'`; do git branch --track $remote; done

Then add your new remote repo:

git remote add bb <path-to-new-repo>

Then you can push all using this command:

git push -u bb --all

Or you can configure the repo using the git config commands noted in the other responses here if you are not doing this one time or are only looking to move local branches.

The important point, the other responses only push all LOCAL branches. If the branches only exist on an alternate REMOTE repository they will not move without tracking them first. The for loop presented here will help with that.

4
  • BTW, I am using "bb" in place of "origin" here because I assume your original/old repository was named "origin" and is likely still attached to that label. "bb" is for Bitbucket, where I moved my original repo to, but you can call it something more applicable like "neworigin" if you prefer. Commented Apr 18, 2013 at 3:38
  • 4
    That didn't work for me. Ended up with all remote branches tracking the same local branch :/
    – jhsowter
    Commented Dec 16, 2014 at 10:35
  • 4
    AFAIK this shouldn't work, as per @jhsowter comment. the right command for me to track a remote branch in a newly cloned repo is git branch --track reponame origin/reponame otherwise you'll get all the remote branches tracked on the current local branch Commented Jan 12, 2016 at 10:43
  • I changed the repo-collecting snippet to git branch -r | grep -v '\->' | sed 's/ origin\///', which gives just the remote branch name.
    – Paul Hicks
    Commented May 20, 2018 at 23:37
12

If you are moving all branches to a new repo from an old one then in your local repo you need to set up tracking of each branch to existing origin branches, before pushing to the new repo, otherwise all your origin branches won’t appear in the new origin. Do this manually by tracking or checking out each branch, or use the one liner:

for remote in `git branch -r | grep -v '\->' | grep -v master`; do git branch --track `echo $remote|sed 's=origin/=='` `echo $remote`; done

This one line command is based on versions of it in other answers on this page, but is arguably better because:

  1. it correctly sets up the branch tracking, unlike some older variants of this command on this page which only supply one parameter to --track and thus each branch ends up tracking master - not good
  2. names the local branches without the prefix “origin/” which I personally don’t want - and is consistent with what happens when you checkout a branch normally.
  3. skips tracking master since that is already happening
  4. doesn’t actually checkout anything thus is fast
  5. avoids stumbling over the -> in the output of git branch -r

Next, if you are switching origins, replace the link to the old origin and point to a new remote. Ensure you create the new remote first, using bitbucket/github GUI, but don’t add any files to it or there will be a merge problem. E.g.

git remote set-url origin [email protected]:YOUR/SOMEREPO.git

Now push. Note the second command is needed to push the tags as well:

git push -u --all origin
git push --tags origin
1
  • Yes, this improves the one answered on Apr 18, 2013 by Lance Cleveland, and I've just tried it and confirmed it's working as expected, i.e., when I do NOT have all the old repo (64) branches locally, and need to track them first.
    – xpt
    Commented Jul 15 at 3:01
9

I found the best and simplest method here, just as @kumarahul posted, works like a charm for me, it will push all the tags and branches from origin to the new remote:

git remote add newremote new-remote-url

git push newremote --tags refs/remotes/origin/*:refs/heads/*

I used 'git push --all -u newremote', but it only push the checkouted branches to the newremote.

Git: Push All Branches to a New Remote

by Keith Dechant , Software Architect

Here's a scenario some of you might have encountered with your Git repositories. You have a working copy of a Git repo, say from an old server. But you only have the working copy, and the origin is not accessible. So you can't just fork it. But you want to push the whole repo and all the branch history to your new remote.

This is possible if your working copy contains the tracking branches from the old remote (origin/branch1, origin/branch1, etc.). If you do, you have the entire repo and history.

However, in my case there were dozens of branches, and some or all of them I had never checked out locally. Pushing them all seemed like a heavy lift. So, how to proceed?

I identified two options:

Option 1: Checkout every branch and push I could do this, and I could even write a Bash script to help. However, doing this would change my working files with each checkout, and would create a local branch for each of the remote tracking branches. This would be slow with a large repo.

Option 2: Push without changing your working copy There is a second alternative, which doesn't require a checkout of each branch, doesn't create extraneous branches in the working copy, and doesn't even modify the files in the working copy.

If your old, no-longer-active remote is called "oldremote" and your new remote is called "newremote", you can push just the remote tracking branches with this command:

git push newremote refs/remotes/oldremote/*:refs/heads/*

In some cases, it's also possible to push just a subset of the branches. If the branch names are namespaced with a slash (e.g., oldremote/features/branch3, oldremote/features/branch4, etc.), you can push only the remote tracking branches with names beginning with "oldremote/features":

git push newremote refs/remotes/oldremote/features/*:refs/heads/features/*

Whether you push all the branches or just some of them, Git will perform the entire operation without creating any new local branches, and without making changes to your working files. Every tracking branch that matches your pattern will be pushed to the new remote.

For more information on the topic, check out this thread on Stack Overflow.

Date posted: October 9, 2017

7

To see all the branches with out using git branch -a you should execute:

for remote in `git branch -r`; do git branch --track $remote; done
git fetch --all
git pull --all

Now you can see all the branches:

git branch

To push all the branches try:

git push --all
2
  • 1
    λ git fetch --all origin fatal: fetch --all does not take a repository argument Commented Jul 27, 2015 at 9:22
  • are you trying git fetch --all ?
    – tokhi
    Commented Jul 27, 2015 at 9:40
5

The full procedure that worked for me to transfer ALL branches and tags is, combining the answers of @vikas027 and @kumarahul:

~$ git clone <url_of_old_repo>
~$ cd <name_of_old_repo>
~$ git remote add new-origin <url_of_new_repo>
~$ git push new-origin --mirror
~$ git push new-origin refs/remotes/origin/*:refs/heads/*
~$ git push new-origin --delete HEAD

The last step is because a branch named HEAD appears in the new remote due to the wildcard

1
  • I've just tried it and confirmed it's working as expected, i.e., when I do NOT have all the old repo (64) branches locally, and need to push them all.
    – xpt
    Commented Jul 15 at 3:11
4

If you are pushing from one remote origin to another, you can use this:

git push newremote refs/remotes/oldremote/*:refs/heads/*

This worked for me. Reffer to this: https://www.metaltoad.com/blog/git-push-all-branches-new-remote

0
2

The 2012 answer mentions git push --all origin as "This will push tags and branches."

Well... no: it will push only all branches (i.e. refs under refs/heads/, not under refs/tags/)

That is why in 2023, with Git 2.41, the answer to "Set up git to pull and push all branches" would be:

git push -u --branches

Because with Git 2.41 (Q2 2023), "git push --all"(man) gained an alias git push --branches(man)".

See commit 022fbb6 (12 May 2023) by Elijah Newren (newren).
See commit 425b4d7 (06 May 2023) by Teng Long (dyrone).
(Merged by Junio C Hamano -- gitster -- in commit f37da97, 15 May 2023)

push: introduce '--branches' option

Signed-off-by: Teng Long

The '--all' option of git-push(man) built-in cmd support to push all branches (refs under refs/heads) to remote.
Under the usage, a user can easlily work in some scenarios, for example, branches synchronization and batch upload.

The '--all' was introduced for a long time, meanwhile, git supports to customize the storage location under refs/".
When a new Git user see the usage like, 'git push origin --all', we might feel like we're pushing all the refs instead of just branches without looking at the documents until we found the related description of it or '--mirror'.

To ensure compatibility, we cannot rename '--all' to another name directly, one way is, we can try to add a new option '--heads' which be identical with the functionality of '--all' to let the user understand the meaning of representation more clearly.
Actually, We've more or less named options this way already, for example, in 'git-show-ref' and 'git ls-remote'(man).

git push now includes in its man page:

'git push' [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]

git push now includes in its man page:

--branches

1

Solution without hardcoding origin in config

Use the following in your global gitconfig

[remote]
    push = +refs/heads/*
    push = +refs/tags/*

This pushes all branches and all tags

Why should you NOT hardcode origin in config?

If you hardcode:

  1. You'll end up with origin as a remote in all repos. So you'll not be able to add origin, but you need to use set-url.
  2. If a tool creates a remote with a different name push all config will not apply. Then you'll have to rename the remote, but rename will not work because origin already exists (from point 1) remember :)

Fetching is taken care of already by modern git

As per Jakub Narębski's answer:

With modern git you always fetch all branches (as remote-tracking branches into refs/remotes/origin/* namespace

1

Add your new remote repo and the last step will exclude the HEAD branch when you push

git clone <url_of_old_repo>
cd <name_of_old_repo>
git remote add new-origin <url_of_new_repo>
git ls-remote . | grep 'refs/remotes/origin/' | grep -v 'HEAD' | awk -F 'origin/' '{print $2}' | xargs -i git push -f new-origin  --tags refs/remotes/origin/{}:refs/heads/{}
0

first add the remote git to your loacl with

git remote add remote_name remote_address

and after you just need to do it with the following command

git push --all remote_name
0

I took a backup from a server that was shut down. When I wanted to send all branches to the new server, I could not find a single command for this. When I checked with git branch -a, there were remotes/origin/master entries. I realized from the code changes that these branches existed in my locale. With git checkout, I could push each branch that was passed. To solve this unnecessary git command complexity, I wrote the following script with gpt.

List all branches and push

for branch in $(git branch -r | grep -v '\->' | sed 's/ *origin\///'); do
    git checkout -B $branch origin/$branch
    git push origin $branch
done

Push tags

git push --tags origin

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.