Remotes

When you are using git chances are high you use it in a collaborative setting. Chances are also high you will use it with remotes set and not via e-mail.

We will focus on the simple setups. Your repository has one remote from where it pulls and to where it pushes.

Protocols

Git support various protocols to talk to remotes. One of the most used protocols when it comes to read/write access is ssh. For read only access there is the git and smart http protocol. Not every protocol can be used to pull and push.

The smart http protocol, the ssh protocol and the local protocol can be used in pull and push settings. Depending on their configuration the use may or may not be able to push to the repository. The git protocol is strictly read only.

The local protocol can work with absolute paths or with a URL like file:///share/gitrepo. When using the URL git uses the same methods for transfer as it is using over network.

Remote repository

The remote repository is usually a bare repository. Bare means it does not have a working tree and only consists of the git folder. It can be initialized with git init --bare.

Cloning

To get a local copy of the remote, we use git clone remoteURL, this clones the remote into a directory named like the remote repository. If you need to clone into a specific local directory, use git clone remoteURL localDir.

Interacting with the remote

Use git remote -v to print the remotes set up for your repository. You also can edit the remotes with the git remote command. By convention the first remote is named origin.

Fetch

git fecth downloads the remote references and objects but does not change anything locally. Your head, index and working tree stay untouched.

Pull and Push

Pull and push either pulling changed from the remote or pushing them to it. Git needs to be able to connect the remote branch and the local branch. The remote branch is name tracking branch.

To set up a tracking branch for your local branch, use git push -u remoteName branchName. Git is also helpful if you push without setting one up. It will fail but print the needed command.

Diverged Histories: Force Pushing and Resets

There will come a time either you changed your local history and the remote will not accept it, or some colleague did overwrite the remote with a changed history. This can be needed after a rebase or squash. Or simply after some cleanup.

When someone else works on the same branch, talk to them before performing a force push. This is one of the rare events where recovering lost work can be tricky.

Force Push

Git know two variants of forcing the remote to accept the local changes and overwrite the remote:

• git push --force-with-lease will only overwrite if the remote has no new commits compared to your local clone
• git push --force will overwrite without any hesitation

Resetting to a force pushed branch

Imagine someone force pushed and you want to have your local branch reflect the remote one. There are multiple options:

• git switch otherBranch, git branch -D branchName and then git switch branchName
• git branch -m newBranchName and then git switch branchName
• git reset --hard origin/branchName

The reset will move the HEAD to the tip of the remote branch and reset your index and working tree.

Exercise

Have a look at the remotes exercise. This exercise contains a setup script which setups a local remote and will guide you through cloning and interacting with a remote. It will even take a peek inside the remote.