Skip to main content

Git

Git and Version Control​

A. Why We Use Git​

Git is a version control system.

In this server setup, Git allows us to stop writing all of our code directly on the server.

Instead, we can develop on our local machine and use GitHub as a central repository.

The basic workflow becomes:

This gives us a proper local development environment while still allowing the server to receive the latest version of the application.

B. Create a Git Repository​

The application on the server should first be initialized as a Git repository.

For example:

cd /var/www/app
git init

This turns the application directory into a local Git repository.

Conceptually:

The course had already initialized the application repository before continuing with the GitHub setup.

C. Create a Repository on GitHub​

Next, create a remote repository on GitHub.

We will connect:

Server Repository
       ↕
     GitHub

GitHub becomes the central location where the repository can be shared between the development machine and the server.

The goal is eventually:

The course's exercise specifically asks us to create a GitHub repository and connect the server repository to it.

D. Create an SSH Key for GitHub​

The server needs a way to authenticate with GitHub.

The course uses SSH authentication.

Create the key from your home SSH directory:

cd ~/.ssh
ssh-keygen

When prompted for the file in which to save the key, enter:

/home/<username>/.ssh/gh_key

This is why the examples below use the filename gh_key. The transcript also notes that an existing SSH key can be reused instead of creating a separate GitHub key.

The key should be stored inside the user's:

~/.ssh/

directory.

For example:

~/.ssh/
├── gh_key
└── gh_key.pub

This creates:

gh_key
→ Private key

gh_key.pub
→ Public key

The private key stays on the server.

The public key will be added to GitHub.

E. Add the Public Key to GitHub​

Copy the public key:

gh_key.pub

and add it to GitHub's SSH keys.

The idea is the same as the SSH key setup previously used with DigitalOcean.

Server
│
├── Private Key
│
│
└── Public Key ─────→ GitHub

When the server later connects to GitHub:

Do not copy the private key to GitHub.

The course specifically emphasizes copying the public key.

F. Add GitHub as a Remote Repository​

The local Git repository on the server now needs to know where its remote repository is.

Use:

git remote add origin git@github.com:<owner>/<repository>.git

Copy the repository's SSH URL from GitHub and replace <owner> and <repository> with the actual values. This SSH URL uses the key configured in the following section.

Conceptually:

origin is the name assigned to the remote repository.

After this, Git knows where to push and pull code.

G. Tell SSH Which Key to Use​

If the machine contains multiple SSH keys, SSH needs to know which key should be used when connecting to GitHub.

Create or edit the SSH configuration file:

vi ~/.ssh/config

Open this file as the regular user, without sudo, so the configuration remains owned by the account that runs Git.

Add a configuration like:

Host github.com
    HostName github.com
    IdentityFile ~/.ssh/gh_key

Each setting has a different purpose:

Host github.com
→ Apply this configuration when connecting to github.com.

HostName github.com
→ The actual hostname SSH should connect to.

IdentityFile ~/.ssh/gh_key
→ Use this private key for authentication.

Conceptually:

The important idea is:

The SSH config tells SSH which private key to use when connecting to a specific host.

H. One SSH Key Can Be Reused​

An SSH key does not necessarily have to be used for only one service or account.

The same SSH key can be reused, or separate keys can be created.

For example:

One SSH Key
├── GitHub
├── Server A
└── Server B

or:

GitHub
   ↓
GitHub-specific key

Server A
   ↓
Server-specific key

The course leaves this choice up to how you want to manage your SSH keys and security.

I. Push the Repository to GitHub​

Once the remote repository and SSH authentication are configured, push the code:

git push origin main

Breaking it down:

git push
→ Send local commits to a remote repository

origin
→ The remote repository

main
→ The branch being pushed

So:

If the push succeeds without an authentication error, the GitHub connection is working.

J. Test the SSH Connection​

If GitHub authentication is not working, SSH can provide more information about the connection.

The course uses an SSH test command:

ssh -Tv git@github.com

This creates a test connection and displays detailed information about what SSH is doing.

It can help identify problems such as:

Wrong SSH key
Incorrect SSH config
Permission problems
Authentication failure

Conceptually:

This is especially useful when Git only reports a general public key authentication error.

K. First-Time SSH Host Verification​

The first time the server connects to GitHub, SSH may display a message saying that the authenticity of the host cannot be established.

This does not necessarily mean the public key was copied incorrectly.

SSH keeps track of machines it has connected to before using the:

known_hosts

file.

Conceptually:

Once accepted, SSH can remember that host for future connections.

L. Develop Locally Instead of on the Server​

Once GitHub is connected, the repository can also be cloned onto the local development machine.

The workflow becomes:

Instead of:

we can use:

This is the main reason the course sets up Git and GitHub at this point.

We can use modern development tools locally, push our changes to GitHub, and then pull those changes onto the server.

M. Complete Git Workflow​

The final workflow is:

Git provides version control.

GitHub provides the central remote repository.

SSH provides secure authentication between the server and GitHub.

Together, they allow us to separate:

Development
→ Local Machine

Code Storage / Synchronization
→ GitHub

Application Execution
→ Server

This means we no longer need to do all development directly on the production server.