Two Git Repos: 'git_origin' and 'git_cloned'

Creating a repository and cloning it#

You’re going to start by creating a simple Git repository and then clone it:

1   mkdir -p lgthw_pull
2   cd lgthw_pull
3   mkdir git_origin
4   cd git_origin
5   git init
6   echo 'first commit' > file1
7   git add file1
8   git commit -am file1
9   cd ..
10  git clone git_origin git_cloned

Similarities and differences#

The two repositories (the folders: git_origin and git_cloned) contain identical content:

11  diff git_origin/file1 git_cloned/file1

However, their .git/config files differ in instructive ways.

The git_origin folder has this in its .git/config file:

12  cat git_origin/.git/config

While the git_cloned folder has this in its .git/config file:

13  cat git_cloned/.git/config

Remote#

While the git_origin has no visibility of any remotes, the cloned one does. The git_cloned repository has a remote called “origin.”

Its URL is (in this case) pointed at the directory git_origin that is local on the host. URLs can also be an http:// or https:// one or even ssh:// or git://. The last is a Git-specific protocol that is rarely seen these days. When you see a Git repository cloned with git@ (i.e., git@github.com:kubernetes/kubernetes), then this is in fact using the ssh:// protocol under the hood.

If you go to the git_cloned repository and ask it for information about its remotes:

14  cd git_cloned
15  git remote

You get the name origin back.

Origin#

The name origin is the default name for a remote, but it does not have a special meaning. It could be renamed to BitBucket or GitLab, for example.

Fetch and push#

The above remotes are divided into (fetch) and (push) actions. These relate to two different actions on remotes, i.e., getting changes from a remote or pushing changes to a remote.

These actions can work against different remotes. For example, the output of git remote -v might be:

16  git remote -v

But I’ve never seen an example of these entries being different from one another in the wild.