Session 3: Alice & Bob use a Git server

Reasons:

• Repositories by Alice and Bob may not always be available.
• Complex topology if more friends join.
• A maintained server has 24/7 availability and simple topology.
• Even with a central server, each collaborator keeps the full history and does not depend on the server (they can work off-line). The architecture is fully distributed, explaining why Git is called a Distributed Version Control System (DVCS).

Alice and Bob setup their ssh keys: ssh-keygen

Alice does this (and so does Bob):

1. Get account on a Git server, for example EODC's GitLab.
2. Create an ssh public+private key pair with ssh-keygen.
3. Upload public key onto Git server.
4. Load private key into a local ssh agent.

Alice creates an empty repository on the Git server

Alice logs on to EODC GitLab (https://git.eodc.eu), navigates to a GitLab group of her choice, and presses the New project button.

She puts in the repository name (e.g. cci_cm_demo_src), a brief description, and chooses verbosity level private.

Alice puts her repository onto the Git server: remote, push

git remote add eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git
git remote show eodc

git push -u eodc master:master # semantics: <local_branch>:<remote_branch>
git branch -a

The -u (--set-upstream) flag adds an upstream (tracking) reference, which is used by argument-less "git pull" and other commands.

Bob clones from the Git server: --origin

git clone --origin eodc git@git.eodc.eu:cci-sm-work/cci_cm_demo_src.git

Remote alias origin will be used if --origin flag is not given.