• View
• Edit
• History
• Print

Pushing and Pulling

Git push

Pushing commits created locally to a remote repo

The simplest case where pushing becomes relevant is when working on a cloned repo. Pushing consists of updating the remote repository with new content that was developed locally. It is done with:

git push <remoteRepo> <targetBranch>

which can be conceived of as pushing the local content onto the remote repository. Note that you cannot push a branch to a remote repo if that branch is already checked out in the remote repo. The easiest way around this situation is to create and checkout another branch in the remote repo, even if it is a dummy branch.

If your local branch is already configured to track a remote branch, the remoteRepo and targetBranch can be omitted from the above.

Pushing a branch created locally:

If you created a new branch on your local repo and want it to be in the remote repo as well, you can do:

git push -u remoteRepo newBranchName

where -u is for --set-upstream, which defines the remote repo as the reference from which to pull in the future, remoteRepo is the tag you have given to the remote repo (commonly origin, the default name for the remote repo from which a local repo is cloned) and newBranchName is the name of the new branch that was created locally.

Pushing forcefully

Sometimes, through using rebase or merging, your local repo will differ from your remote repo. One way to fix that is to painfully redo everything you have done locally on the remote repo (if you can even ssh there). The other way, if you are confident that your changes are good, is to squash the remote repo and force it to take your new version. This can be done using:

git push -f <remoteRepo> <targetBranch>

Git pull

Conversely, updating the local repo with newer information from the remote repo is called pulling, and can be conceived as pulling the remote content onto the local repo. It is done with:

git pull <remoteRepo> <targetBranch>

If your local branch is already configured to track a remote branch, the remoteRepo and targetBranch can be omitted from the above.

Pulling nicely

When tracking a remote repo belonging to someone else, or where multiple people work, you might encounter occasions where your history and theirs differs. The nicest way to deal with this is by using rebase to first apply the changes that come from the remote branch. This can be done using the -r option and will essentially go back to the latest common commit, apply all of the new remote commits (thus recreating the remote branch as it currently is) and then proceed to try to apply your local commits. Conflicts, if any, will thus only be in your code, and should be easier to solve. If you then push the branch, others will also see all your changes together at the top of the log, as if they were all new, which, for them, actually is the case.

This is very useful when working in groups or even by yourself with multiple branches, to keep your working branch up to date with the latest releases and bugfixes so that, once you are done, your new feature can immediately be merged into the release branch.

Pulling "forcefully"

In a similar way as pushing an update forcefully, maybe you were working on something that did not pan out and want to go back to the remote's version of a branch. Unfortunately, the intuitive git pull -f does not work. Instead, you need to reset the branch to its origin:

git reset --hard <remoteRepo>/<targetBranch>