Remote

instances and the canonical repository.

A remote repository is an instance of the repository that lives at another location.

There is no built-in hierarchy between instances. When there is a conflict, it's up to users to resolve it.

We use a pattern that sets one instance as the source-of-truth, with some flexibility when it needs to be corrected. We name it the canonical repository.

In practice, we put the canonical repository on a server known by all team members. Each member pushes changes to it and pulls changes from it.

For example, a member sets up a repository and publishes it to a host such as Github. The hosted repository becomes the canonical repository. Then, members clone the repository. Cloning downloads the repository and pre-configures it to be linked with the canonical repository.

remote-tracking branch

the remote-tracking branch mirrors a branch that lives on a remote repository, usually the canonical repository. As a faithful mirror, it is read-only, and only changes through a network call that signals changes.

we may poll the remote repository with git fetch. If updates are found, Git downloads the related commits and add them to the remote-tracking branches. We may inspect them like any other branch: we may log the commits and check the differences.

git log origin/main
git diff main origin/main

We may then merge the remote-tracking branch into the local-only one:

git merge origin/main

git pull is a shortcut for git fetch and git merge.

remote

As a Git technical term, a remote is a configured reference to a remote repository. We setup a remote to be able to push and pull from it.

We add a remote through its URL, and give it an alias name for convenience. By convention, we use origin for the main repository remote.

git remote add origin https://github.com/user333/helloworld.git

We may list remotes and show information for a given one. It's usually only origin.

git remote show
git remote show origin

## remote origin
##   Fetch URL: https://github.com/user33/abc.git
##   Push  URL: https://github.com/user33/abc.git
##   HEAD branch: main
##   Remote branch:
##     main tracked
##   Local branch configured for 'git pull':
##     main merges with remote main
##   Local ref configured for 'git push':
##     main pushes to main (up to date)

mutate a remote's URL

example: change the URL that origin refers to

git remote set-url origin git@github.com:user33/abc.git

merge the changes coming from remote

this is what happens when we do git pull (fetch + merge): the fetch updates origin/main, then the merge applies a fast forward so that main and origin/main point to the same commit.

git merge origin/main

merge a branch into main

git merge <branch-name>
git merge dev

clone: download and expand the .git directory

download

a clone download the .git directory.

https://github.com/mantinedev/mantine.git

we may clone a stripped-out version of the .git directory, one who contains less files.

For example, we ask the files needed by the last commit, and not the others. This is called a shallow clone.

We specify the depth, to target only the n-last commits.

git clone --depth 1 https://github.com/mantinedev/mantine.git
git clone --depth 1 [--branch master] https://github.com/mantinedev/mantine.git

expand

the clone automatically expands the latest commit files into the working directory.

branches and remote

push a branch that does not exist yet on the remote repository

Given that the remote repository doesn't have our local branch, we also don't have a remote-tracking branch that is supposed to track this branch on the remote. As such, we cannot set up an upstream just yet, because doing so requires binding a local-only branch to a remote-tracking branch.

Instead, we must first push the branch to the remote repository. If it is successful, we get the remote-tracking branch, and Git may now bind the branch to the remote-tracking branch, configuring it as the upstream.

We do it with one command: the push command, where we specify which remote we are pushing to, which branch we are pushing, and that we want Git to make the upstream binding if the push was a success

git push -u origin 2024

delete a branch on the remote repository

push is because it's an update to the remote repo.

git push origin --delete 2024

indicate match between current branch and remote-tracking branch

git branch --set-upstream-to origin/my_branch
git branch -u origin/my_branch
earlymorning logo

© 2025 - All rights reserved

Remote

instances and the canonical repository.

A remote repository is an instance of the repository that lives at another location.

There is no built-in hierarchy between instances. When there is a conflict, it's up to users to resolve it.

We use a pattern that sets one instance as the source-of-truth, with some flexibility when it needs to be corrected. We name it the canonical repository.

In practice, we put the canonical repository on a server known by all team members. Each member pushes changes to it and pulls changes from it.

For example, a member sets up a repository and publishes it to a host such as Github. The hosted repository becomes the canonical repository. Then, members clone the repository. Cloning downloads the repository and pre-configures it to be linked with the canonical repository.

remote-tracking branch

the remote-tracking branch mirrors a branch that lives on a remote repository, usually the canonical repository. As a faithful mirror, it is read-only, and only changes through a network call that signals changes.

we may poll the remote repository with git fetch. If updates are found, Git downloads the related commits and add them to the remote-tracking branches. We may inspect them like any other branch: we may log the commits and check the differences.

git log origin/main
git diff main origin/main

We may then merge the remote-tracking branch into the local-only one:

git merge origin/main

git pull is a shortcut for git fetch and git merge.

remote

As a Git technical term, a remote is a configured reference to a remote repository. We setup a remote to be able to push and pull from it.

We add a remote through its URL, and give it an alias name for convenience. By convention, we use origin for the main repository remote.

git remote add origin https://github.com/user333/helloworld.git

We may list remotes and show information for a given one. It's usually only origin.

git remote show
git remote show origin

## remote origin
##   Fetch URL: https://github.com/user33/abc.git
##   Push  URL: https://github.com/user33/abc.git
##   HEAD branch: main
##   Remote branch:
##     main tracked
##   Local branch configured for 'git pull':
##     main merges with remote main
##   Local ref configured for 'git push':
##     main pushes to main (up to date)

mutate a remote's URL

example: change the URL that origin refers to

git remote set-url origin git@github.com:user33/abc.git

merge the changes coming from remote

this is what happens when we do git pull (fetch + merge): the fetch updates origin/main, then the merge applies a fast forward so that main and origin/main point to the same commit.

git merge origin/main

merge a branch into main

git merge <branch-name>
git merge dev

clone: download and expand the .git directory

download

a clone download the .git directory.

https://github.com/mantinedev/mantine.git

we may clone a stripped-out version of the .git directory, one who contains less files.

For example, we ask the files needed by the last commit, and not the others. This is called a shallow clone.

We specify the depth, to target only the n-last commits.

git clone --depth 1 https://github.com/mantinedev/mantine.git
git clone --depth 1 [--branch master] https://github.com/mantinedev/mantine.git

expand

the clone automatically expands the latest commit files into the working directory.

branches and remote

push a branch that does not exist yet on the remote repository

Given that the remote repository doesn't have our local branch, we also don't have a remote-tracking branch that is supposed to track this branch on the remote. As such, we cannot set up an upstream just yet, because doing so requires binding a local-only branch to a remote-tracking branch.

Instead, we must first push the branch to the remote repository. If it is successful, we get the remote-tracking branch, and Git may now bind the branch to the remote-tracking branch, configuring it as the upstream.

We do it with one command: the push command, where we specify which remote we are pushing to, which branch we are pushing, and that we want Git to make the upstream binding if the push was a success

git push -u origin 2024

delete a branch on the remote repository

push is because it's an update to the remote repo.

git push origin --delete 2024

indicate match between current branch and remote-tracking branch

git branch --set-upstream-to origin/my_branch
git branch -u origin/my_branch