GitNoon Lesson 2

In this tutorial, you will learn how to:

1. Configure your GitHub account to support SSH authentication
2. Share repos on GitHub
3. Update remote and local repos
4. Instruct Git to ignore certain files
5. Publish a repo as a website on GitHub

Note: While this tutorial makes use of GitHub, it should be reasonably straightforward to adapt its contents to an alternative hosting provider, like GitLab.

Configuring your GitHub account to support SSH authentication

Following instructions from: docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account

GitHub (and most Git hosting providers) support two types of connection:

1. HTTPS, with authentication based on username and password
2. SSH, with authentication based on a private key you keep on your machine, and a public key that you share with GitHub

We’re going to use SSH, which is generally the preferred option and is simpler when your account has Two-Factor Authentication enabled.

To do so, whenever we want to use Git on a new machine, we’ll need to:

1. Generate an SSH keypair to identify your machine
   • You can skip this if you already have a key on your machine that you want to use
2. Add your public key to your GitHub account

Generating an SSH keypair

To generate a new SSH keypair, open a terminal and run:

ssh-keygen -t ed25519 -C "your.email@example.com"

• If you have an older system that doesn’t support ed25519, use:
  • ssh-keygen -t rsa -b 4096 -C "your.email@example.com"
• You will be asked if you want to protect your private key with a new password
  • You should ideally use a password generated by a password manager

This will create two files in an .ssh directory under your home directory, which we can list with:

ls -l ~/.ssh

You should see:

• A private key: id_ed25519 (or similar)
• A public key: id_ed25519.pub (or similar)

Adding your public key to your GitHub account

1. Visit github.com in your web browser
2. Click on your profile picture, and select Settings
3. Under SSH and GPG keys, select New SSH key
4. Fill in the following details:
   1. Title: Use a name that identifies your machine, e.g. work-laptop
   2. Key type: Authentication Key
   3. Key: Paste the contents of your public key, which you can get by running:

cat ~/.ssh/id_ed25519.pub

• Git also supports using keys to cryptographically sign your commits - providing evidence that it was actually you who made a commit bearing your name and email address.
• If anyone else ever gains access to your private key, you should delete it from your GitHub account.

Sharing repos on GitHub

Pushing your repo

Let’s create a repository on GitHub to publicly share the blog we made last week:

1. Visit github.com in your web browser
2. From the + dropdown at the top-right, select New Repository
3. Fill in the following details:
   • Name: blog
   • Visibility: Public
   • Don’t add a README or any other files

Your new repository will be completely empty, with no commits.

Now let’s connect your local blog repo to this remote repo on GitHub:

1. From your repo’s GitHub page, find the Quick setup instructions
2. Select the SSH tab, and copy the URL
3. Open your repo’s directory in a terminal (cd blog)
4. Add the remote to your repository:

git remote add origin git@github.com:<username>/blog.git

IMPORTANT: If the network you are on does not allow traffic over SSH port 22, you will need to use a different URL format:

git remote add origin ssh://git@ssh.github.com:443/<username>/blog.git

To check our remote has been added successfully, run:

git remote -v

• We can potentially connect multiple remote repositories to push/fetch code to/from.
• origin is the conventional name for the primary remote.

Now let’s push the current state of the local repository (specifically, the main branch we have been working on) to the origin remote:

git push -u origin main

• You may need to accept the authenticity of the Git remote’s fingerprint - you can double-check it at: docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
• You may also be prompted for your SSH private key’s password

Go back to your repo on GitHub and you should see your blog files!

Cloning your neighbour’s repo

Now try cloning your neighbour’s repo:

1. Ask your neighbour for the link to their repo on GitHub
2. From the repo page, find the Code dropdown, and copy the SSH URL
3. In a new terminal, clone their entire repository into a new directory called friend-blog by running:

git clone git@github.com:<friend-username>/blog.git friend-blog

Again, if the network you are on does not allow traffic over SSH port 22, you will need to use a different URL format:

git clone ssh://git@ssh.github.com:443/<username>/blog.git friend-blog

Have a look at their blog posts!

cd friend-blog
ls -l
cat entry_1.md

Updating remote and local repos

We should add a README file to every repo to provide a starting point for anyone looking at it (including our future selves!).

Let’s each add a README to our own repo, then fetch the README that our neighbour added into our local clone of their repo.

Pushing a README to our remote repo

First, go back to the terminal opened to your own blog’s directory, and create a README.md file:

nano README.md

Give it the following content’s

# My Blog

## Contents

* [Entry 1](entry_1.md)

Save and exit nano (Ctrl + x, y, Enter), then add and commit the README:

git status
git add README.md
git status
git commit
# Commit message: Add README
git status

• With that last git status, you should see that your branch is “ahead of origin/main by 1 commit”
• origin/main is a remote reference that tells us what the main branch looked like on the origin remote the last time we cloned or “fetched” from that remote.
• We can indeed see that (based on our last fetch), origin/main does not yet have our latest commit:

git log

To publish the latest commits from the local copy of our branch to the remote, we just need to run:

git push

Now check the status and log again, and see that origin/main has been updated:

git status
git log

Finally, refresh your repo’s page on GitHub, and see that you have a fancy-looking README file!

Fetching the README of our neighbour’s repo

Now go back to the terminal open in your friend-blog/ directory, and fetch the latest commits:

git fetch

Now git status tells us that our local repo is behind the remote by 1 commit:

git status

We can also see this from the log:

git log origin/main

• Because git log defaults to showing us commits on our current local branch, we need to tell it to look at commits on the remote branch

Because we haven’t made any commits of our own since we last cloned/fetched, we can simply tell Git to update our local branch by “fast-forwarding” through all of the commits on the remote branch:

git merge --ff-only origin/main

• --ff-only tells Git to only update our local branch if it is possible to “fast-forward”.
• If we had made our own local commits, fast-forwarding wouldn’t be possible, and we’d need to take a different approach.
• We’ll look at that case along with branches and git merge in more detail in the next lessons.
• NOTE: Some tutorials might teach you to use git pull, which performs both a fetch and merge from one command
  • Recommendation: Avoid using pull until you fully understand how merges work, and the implications of the different ways the pull command can be configured.

Telling Git to ignore certain files

Sometimes we have files that we don’t want Git to track, especially when sharing repos with others:

• Local configuration that doesn’t need to be shared
• Secrets that shouldn’t be shared (like API keys)
• Temporary editor lock files
• Locally-installed dependency packages
• Outputs of build/compilation processes

For example, let’s say we have a file containing some secrets:

touch secrets.txt

Git is ready for us to start tracking it:

git status

But we will tell Git to never track that file by adding its path to a .gitignore file:

nano .gitignore

Add the following line into .gitignore:

secrets.txt

Now Git will ignore secrets.txt, though we will need to make sure we commit the .gitignore file:

git status

Publishing your repo as a website on GitHub

Finally, let’s use GitHub’s Pages feature to publish your blog as a static website!

1. Open your repo’s page on GitHub
2. Go to Settings -> Pages
3. Select Deploy from a branch, select the main branch, then Save
4. Open your website at: https://<username>.github.io/blog
   • You may need to wait a minute for it to be published.

You can make a pretty fancy blog or documentation website on GitHub pages with a static site tool like Jekyll, or by crafting your own HTML and CSS.

Conclusion

• You have now learned how to work with remote Git repositories
• In the next lesson, you’ll learn how to use Git’s branching and merging features, which are especially important for managing multiple people working on the same repository.