Git — Establishing and Initializing a Folder with a GitHub Repository

September 13, 2026

Git is a version-control system that allows tracking changes to files, returning to previous versions, and synchronizing files with a remote repository such as GitHub.

This is a collection of the basic Git commands I use when setting up a new project, connecting it to GitHub, and maintaining it afterward.

Verify Git Is Installed

Before doing anything with Git, I want to make sure it's installed on the system.

git --version

If Git is installed, it'll show something similar to:

git version 2.47.3

The exact version will depend on the Linux distribution and when it was updated.

If the command returns something like:

bash: git: command not found

then Git isn't installed or isn't available in the PATH.

On Debian-based systems, install it with:

sudo apt install git

Configure Git Identity

Git records the author of each commit. I therefore need to configure a name and email address.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

The --global option means these settings apply to Git repositories for my user account on this computer.

The email address doesn't necessarily have to be the same email I use to log into GitHub, but using an address associated with my GitHub account allows GitHub to associate my commits with my account.

Check the configuration

To display the Git configuration settings that are configured globally.

git config --global --list

This is useful when troubleshooting commits, especially if Git is using an unexpected name or email address.

Set Up SSH Authentication

There are several ways Git can authenticate with GitHub. I use SSH because it allows Git to authenticate using an SSH key rather than entering my GitHub credentials every time.

Check for an Existing SSH Key

First, check whether an SSH key is already configured:

ls ~/.ssh

Why?

The .ssh directory contains SSH configuration files and keys for my user account.

I'm particularly interested in files such as:

id_ed25519
id_ed25519.pub

or older RSA keys:

id_rsa
id_rsa.pub

The file without .pub is the private key.

The .pub file is the public key.

The private key should never be given to anyone. The public key is the one that can safely be added to GitHub.

Generate an SSH Key

If an appropriate key is not found, create an Ed25519 key:

ssh-keygen -t ed25519 -C "you@example.com"

Notes

ssh-keygen creates an SSH key pair.

The important parts of this command are:

ssh-keygen — program used to create SSH keys
-t ed25519 — specifies the Ed25519 key type
-C — adds a comment to help identify the key

Press Enter to accept the default filename:

/home/username/.ssh/id_ed25519

The program will then ask whether I want to protect the key with a passphrase.

What about the passphrase?

This is an important distinction.

A passphrase protects the private key if somebody obtains the key file. It's therefore a good security practice. So do it.

However, if I create a passphrase-protected key and don't configure an SSH agent to remember it, SSH may ask for the passphrase when I use the key.

The SSH agent can solve this by keeping the unlocked key available for my session.

Start the SSH Agent

eval "$(ssh-agent -s)"

Notes

ssh-agent is a background program that can hold my private SSH keys in memory for the current login/session. This allows SSH and Git to use the key without asking for its passphrase every time.

The key itself is still stored securely on disk. ssh-agent only keeps the unlocked key in memory while the agent is running. When the agent is stopped or the session ends, the key normally needs to be added to the agent again.

The eval portion sets the necessary environment variables in my current shell so SSH knows how to communicate with that agent.

The output should be something similar to:

Agent pid 12345

Add the SSH Key to the Agent

ssh-add ~/.ssh/id_ed25519

Notes

This loads the private key into the SSH agent.

Verify that the key is loaded with:

ssh-add -l

Get the Public Key

cat ~/.ssh/id_ed25519.pub

Notes

cat displays the contents of the public-key file.

The output will look something like:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... you@example.com

Copy the entire line and add it to the GitHub account under:

GitHub → Settings → SSH and GPG keys

Again, this is the .pub file. Never copy or upload the private key.

Test the GitHub SSH Connection

ssh -T git@github.com

Notes

This tests whether my computer can successfully authenticate with GitHub using SSH.

The first time I connect, SSH may ask whether I trust GitHub's host key. After accepting it, a successful authentication should produce a message indicating that I've successfully authenticated.

This is a useful troubleshooting step because it separates SSH authentication problems from Git problems.

Using Git

Once Git and SSH are configured, I can start working with repositories.

There are two slightly different situations:

I already have a repository on GitHub and want to download it.
I have an existing local directory and want to turn it into a Git repository.

These are not the same operation.

Clone an Existing GitHub Repository

If the repository already exists on GitHub, I can clone it:

git clone git@github.com:USERNAME/REPO.git

Notes

git clone downloads an existing repository from a remote location and creates a local Git repository from it.

Normally, Git creates a directory using the repository's name.

For example:

git clone git@github.com:USERNAME/REPO.git

would normally produce:

current-directory/
└── REPO/
    ├── file1
    ├── file2
    └── .git/

Clone Directly Into the Current Directory

Sometimes I don't want Git to create another directory.

If I'm already inside the directory where I want the repository files to go, I can use:

git clone git@github.com:USERNAME/REPO.git .

The . means:

Clone the repository into the current directory.

Why is the `.` important?

The final argument to git clone specifies the directory where Git should place the repository.

Normally Git derives that directory name from the repository:

git clone git@github.com:USERNAME/REPO.git

But explicitly specifying:

tells Git to use the current directory.

This is particularly useful when I already have a directory structure established and don't want Git creating another level of directories.

One caveat: the destination directory generally needs to be empty, or Git may refuse to clone into it.

Initialize a New Repository

If I already have a directory containing my project files locally and want to start using Git to sync with Github, I can initialize it with:

git init

Notes

git init creates the hidden .git directory inside the current directory.

For example:

my_project/
├── index.html
├── style.css
└── .git/

The .git directory contains the information Git needs to track the repository.

This is different from git clone.

git clone starts with an existing remote repository.

git init starts with a local directory and turns it into a Git repository.

Check the Repository Status

git status

Notes

git status is one of the commands I use most frequently.

It details what Git currently knows about the working directory.

For example, Git might report:

Untracked files:
  index.html
  style.css

or:

Changes not staged for commit:
  modified: index.html

This is important because Git doesn't automatically commit every change I make.

There is a progression:

Working directory
       ↓
Staging area
       ↓
Commit
       ↓
Remote repository

Understanding this progression makes the other Git commands much easier to understand.

Add Files to the Staging Area

To add one specific file:

git add filename

For example:

git add index.html

To add everything that has changed:

git add .

Notes

Git uses a staging area as a place where I select which changes should be included in my next commit.

The command:

git add index.html

means:

Put the current changes to index.html into the staging area for my next commit.

The command:

git add .

means:

Add the changes in the current directory and its subdirectories to the staging area.

This gives me an opportunity to review what I'm about to commit before actually creating the commit.

I can check what is staged with:

git status

Commit the Changes

git commit -m "Your commit message"

For example:

git commit -m "Add Git setup documentation"

Notes

A commit creates a recorded snapshot of the staged changes.

The -m option allows me to provide the commit message directly on the command line.

A good commit message should describe what changed.

For example:

git commit -m "Fix mobile code block scrolling"

is much more useful later than:

git commit -m "changes"

The important thing to remember is that git commit commits what is in the staging area, not necessarily every change currently sitting in the working directory.

Pull Changes from GitHub

git pull

Notes

git pull gets changes from the remote repository and integrates them into the current local branch.

Conceptually, it is doing two things:

Remote repository
       ↓
     fetch
       ↓
     merge
       ↓
Local repository

This is useful when the remote repository has changes that my local copy doesn't have.

For example, if I edit a project from another computer and push those changes to GitHub, I can use:

git pull

on this computer to bring those changes down.

Push Changes to GitHub

git push

Notes

git push sends my local commits to the configured remote repository.

The typical workflow is therefore:

git add .
git commit -m "Describe what changed"
git push

The sequence matters:

git add — select changes for the next commit.
git commit — create a permanent local snapshot.
git push — send that commit to GitHub.

Git doesn't normally push individual file changes directly. It pushes commits.

The Basic Git Workflow

Once everything is configured, most day-to-day Git work boils down to this:

At the start of the day, I'll pull any changes from the repository to make sure my local files are up to date:

git pull

then, througout the day:

git status
git add .
git commit -m "Describe what changed"
git push

The biggest thing to remember is that Git and GitHub are not the same thing.

Git is the version-control software running on the local computer.

GitHub is a remote service where I can store and collaborate on Git repositories.

Git can be used completely locally without GitHub, while GitHub relies on Git repositories to provide its version-control functionality.

Topics: Linux Git

Git — Establishing and Initializing a Folder with a GitHub Repository

Verify Git Is Installed

Configure Git Identity

Check the configuration

Set Up SSH Authentication

Check for an Existing SSH Key

Why?

Generate an SSH Key

Notes

What about the passphrase?

Start the SSH Agent

Notes

Add the SSH Key to the Agent

Notes

Get the Public Key

Notes

Test the GitHub SSH Connection

Notes

Using Git

Clone an Existing GitHub Repository

Notes

Clone Directly Into the Current Directory

Why is the . important?

Initialize a New Repository

Notes

Check the Repository Status

Notes

Add Files to the Staging Area

Notes

Commit the Changes

Notes

Pull Changes from GitHub

Notes

Push Changes to GitHub

Notes

The Basic Git Workflow

Why is the `.` important?