Asked  7 Months ago    Answers:  5   Viewed   33 times

I use the following command to push to my remote branch:

git push origin sandbox

If I say

git push origin

does that push changes in my other branches too, or does it only update my current branch? I have three branches: master, production and sandbox.

The git push documentation is not very clear about this, so I'd like to clarify this for good.

Which branches and remotes do the following git push commands update exactly?

git push 
git push origin

origin above is a remote.

I understand that git push [remote] [branch] will push only that branch to the remote.



You can control the default behavior by setting push.default in your git config. From the git-config(1) documentation:


Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are:

  • nothing: do not push anything

  • matching: (default before Git 2.0) push all matching branches

    All branches having the same name in both ends are considered to be matching.

  • upstream: push the current branch to its upstream branch (tracking is a deprecated synonym for upstream)

  • current: push the current branch to a branch of the same name

  • simple: (new in Git 1.7.11, default since Git 2.0) like upstream, but refuses to push if the upstream branch's name is different from the local one

    This is the safest option and is well-suited for beginners.

The simple, current and upstream modes are for those who want to push out a single branch after finishing work, even when the other branches are not yet ready to be pushed out

Command line examples:

To view the current configuration:

git config --global push.default

To set a new configuration:

git config --global push.default current
Tuesday, June 1, 2021
answered 7 Months ago

Let us say 'yourWebApp' is the folder you have your local web app. Change it to the directory

cd 'yourWebApp'

Init git in the folder

git init

Now add your github url as a remote

git remote add origin git://

Here origin is the short name for your url

Now pull the read me file from the github repo

 git pull origin master

Now push your web app to the github repository

git push origin master

Here it is assumed that you are in your master, the default branch

Here pulling your readme files is necessary to merge the readme file with your local work. If your github repository is empty, you can skip the pull and directly push to your github repository.

On the other hand, if you want to use clone, there is no need to init as clone automatically sets up git in the directory. clone also sets your remote git url. In that case, your workflow should be

 clone -> push
Tuesday, July 27, 2021
answered 5 Months ago

What probably happened is that you removed the file from your workspace but not from the index. If you did that git thinks that removing this file is a change and it will remove it from then on.

The way to go is to remove the file you don't want to track anymore from the index with

git rm --cached App.Local.config

and then add that file to the .gitignore Doing that you will have no more problems with the file

Thursday, August 12, 2021
answered 4 Months ago

That sounds like a git merge --squash

git checkout mainline
git merge --squash dev
git commit

Note that, as commented here, it is best to merge mainline in dev first and solve any conflict there, before merging back dev in mainline.

Tuesday, August 17, 2021
answered 4 Months ago

To push to a repo from within a Gitlab CI runner you need to use a user that has push access to the branch you want to push to. We use the following set-up to accomplish this (we let Gitlab CI tag releases and push them).

  1. Create a new Gitlab user called gitlab-ci
  2. Create a SSH key-pair and add the public key to the gitlab-ci user's SSH keys in Gitlab
  3. Give the gitlab-ci user push access to your repo (developer role)
  4. Add the content of the private-key as a CI/CD secret variable called **SSH_PRIVATE_KEY**

This way the private key will be available in CI jobs, next the first part of my CI job looks like this:

    # Install ssh-agent through openssh-client if not present
    - 'which ssh-agent || ( apt-get update -qy && apt-get install openssh-client -qqy )'
    # Add the private key to this user
    - eval $(ssh-agent -s) && ssh-add <(echo "$SSH_PRIVATE_KEY") && mkdir -p ~/.ssh
    # Docker specific settings
    - '[[ -f /.dockerenv ]] && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config'
    # Config git to avoid first usage questions. Set the identity
    - git config --global "" && git config --global "Gitlab CI"
    # Do Git stuff, for example:
    - git checkout $CI_COMMIT_REF_NAME
    - git tag my-release-1.0
    - git push -u origin my-release-1.0

Big fat disclaimer: Only use this in Gitlab CI runner setups that are disposed of, you are distributing private SSH keys with potential access to your repo so you must use this carefully.

Monday, October 4, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :