Set up git to pull and push all branches

Question

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.

Answer 1

The simplest way is to do:

git push --all origin

This will push tags and branches.

Answer 2

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 = user@example.com:/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/*

Answer 3

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.

Answer 4

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/*'

Answer 5

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.

Answer 6

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 git@bitbucket.org: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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

Answer 12

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/{}

Answer 13

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

Answer 14

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