When trying to push to a remote location from a local workstation.

Pushing to a remote

Use git push to push commits made on your local branch to a remote repository.

The git push command takes two arguments:

• A remote name, for example, origin
• A branch name, for example, master

For example:

git push  <REMOTENAME> <BRANCHNAME> 

As an example, you usually run git push origin master to push your local changes to your online repository.

Renaming branches

To rename a branch, you'd use the same git push command, but you would add one more argument: the name of the new branch. For example:

git push  <REMOTENAME> <LOCALBRANCHNAME>:<REMOTEBRANCHNAME> 

This pushes the LOCALBRANCHNAME to your REMOTENAME, but it is renamed to REMOTEBRANCHNAME.

Dealing with "non-fast-forward" errors

If your local copy of a repository is out of sync with, or "behind," the upstream repository you're pushing to, you'll get a message saying non-fast-forward updates were rejected. This means that you must retrieve, or "fetch," the upstream changes, before you are able to push your local changes.

For more information on this error, see "Dealing with non-fast-forward errors."

Pushing tags

By default, and without additional parameters, git push sends all matching branches that have the same names as remote branches.

To push a single tag, you can issue the same command as pushing a branch:

git push  <REMOTENAME> <TAGNAME> 

To push all your tags, you can type the command:

git push  <REMOTENAME> --tags

Deleting a remote branch or tag

The syntax to delete a branch is a bit arcane at first glance:

git push  <REMOTENAME> :<BRANCHNAME> 

...

Prerequisites

Before you get started, you should have:

• an LFID account (sign up here)

• git installed (see: http://www.git-scm.com/downloads)

• git configured with your name, e-mail address and editor

  git config --global user.name "Firstname Lastname"
  git config --global user.email "email@address.com"
  git config --global core.editor "text-editor-name"
  

  Note: Your name and e-mail address (including capitalization) must match what you entered when creating your LFID account.

• an ssh public/private key pair (see the good GitHub docs on generating ssh keys)

• register in the Gerrit server. See below for detailed instructions. Register your SSH key with Gerrit

• git-review installed (see: https://www.mediawiki.org/wiki/Gerrit/git-review#Installation

Push patches to Gerrit

1. Open a shell to the directory containing the project repo

2. Create a local working branch, based on the branch you would like to make changes to.

   git fetch origin
   git checkout -b new_feature_branch origin/master
   

   Replace origin/master with whichever remote/branch you need to contribute to. Typically master is the latest development branch.

3. Make the modifications you would like to change in the project

4. Stage the modified files for commit. (Repeat for all files modified)

   git add /path/to/file
   

5. Verify the staged files by running git status

6. Commit the staged files by amending the patch

   git commit -s
   

   Note

   The ‘-s’ argument signs the commit message with your name and email and is a statement that you agree to the Developer’s Certificate of Origin.

7. Push the patch to Gerrit using one of the 2 methods documented:

   1. Push using git review
   2. Push using git push

Push using git review

We recommend using git-review if possible as it makes working with Gerrit much easier.

1. Install git-review via your local package management system

   If your distro does not package git-review or you need a newer version.

   Install it via PyPi in a virtualenv environment:

   virtualenv ~/.virtualenvs/git-review
   pip install git-review
   

2. Push the patch to Gerrit

   git review
   

   We can optionally pass the parameter -t my_topic to set a topic in Gerrit. Useful when we have related patches to organize in one topic.

Once pushed we should see some output in the terminal as described in Gerrit Push Output.

Push using git push

This method is a useful fallback in situations where we cannot use git-review.

1. Use the following command:

   git push <remote> HEAD:refs/for/master
   

   Where <remote> is the Gerrit location to push the patch to. Typically ‘origin’ but can also be ‘gerrit’ depending on how we have our local repo setup.

Note

Notice the word “for” is explicitly intending to perform the push into Gerrit. Using “heads” instead, will attempt to make the a push into the repository bypassing Gerrit which can come in handy for some isolated cases (when having force push rights). Another variable commonly used is “refs/changes/<gerrit-number>” which is an explicit way of making an update to an existing gerrit. In such case, is best to let gerrit handle this via Change-Id in the commit text.

More options for this command: git-push.

Once pushed we should see some output in the terminal as described in Gerrit Push Output.

Push output

After pushing a commit to Gerrit we should see the following output:

   (releng) cjac@probook0:/usr/src/git/lf/gerrit.linuxfoundation.org/releng/docs$ git review
   remote: Processing changes: updated: 1, refs: 1, done
   remote:
   remote: Updated Changes:
   remote:   https://gerrit.linuxfoundation.org/infra/7404 documentation on the topic of git-review
   remote:
   To ssh://gerrit.linuxfoundation.org:29418/releng/docs.git
   * [new branch]      HEAD -> refs/publish/master/git-review-docs

This output includes a URL to the patch. The number at the end is the patch’s change number.

For Further Information go to following URL's for Git Guide and Gerrit Guide.

Git Guide: https://docs.releng.linuxfoundation.org/en/latest/gerrit.html

Gerrit Guide: https://docs.releng.linuxfoundation.org/en/latest/gerrit.html

Related articles

...