How to Create a GitHub Account and Your First Repository

A GitHub repository is a folder that Git tracks. Every change to its files is saved as a commit, so you can read the history later and see what changed. This lesson shows how to create an account, make a repository, and make two commits, all in the browser. You need no programming background and no security tools.

#What you need

• An email address you can read.
• A username you are comfortable making public.
• A web browser. Nothing needs to be installed for this lesson.

#1. Create your account

Go to github.com and follow the sign-up flow on the site. Use a unique password, ideally stored in a password manager. Then turn on two-factor authentication in your account security settings. The official 2FA guide lists the available second-factor methods. SMS is only offered in some countries.

GitHub's layout changes over time. If a label below does not match your screen, use the Hello World guide as the reference.

#2. Create a repository

Open the create menu in the upper-right corner and choose New repository. The official guide describes these fields:

• Owner: your personal account.
• Name: up to 100 characters, using ASCII letters, digits, and the characters ., -, and _.
• Description: an optional short summary.
• Visibility: public or private.
• Initial files: optional README, .gitignore, and license.

Use the name security-learning-notes, add a short description, and choose Private while you learn. Tick the option to add a README, then create the repository.

Private visibility limits who can see the repository. That does not make it a safe place for passwords or keys, as section 6 explains.

#3. Edit the README

Open README.md and click the pencil icon to edit it in the browser. Replace the contents with something specific:

# My Security Learning Notes

This repository contains exercises I created while learning cybersecurity.

## Topics
- How DNS works
- Encoding versus encryption

## Scope
All exercises use local labs or systems I own.

Write a short message describing the change, such as Document learning goals, and commit it. A commit is a saved change with a message and a timestamp. GitHub stores it as part of the repository history.

#4. Add a second file and commit it

Choose Add file, then Create new file. Type notes/first-lesson.md in the name field. Typing a slash creates a folder. In the body, write one paragraph explaining the difference between a password hash and encryption. A hash is a one-way fingerprint of data, used to check a value without storing the value itself. Encryption is reversible by anyone who holds the key. Commit this file with its own message, such as Add first lesson notes.

Separate commits make the history easier to read. Each commit should describe one idea.

#5. Read the history

Open the repository's commit history. You should see at least two commits with messages you can understand. Being able to explain what changed and why matters more than the number of commits.

If Git is installed on your computer, the same history is available from the command line. I ran this on a scratch repository with one commit using the same message:

git log --oneline

Output from that run:

03c208a Document learning goals

Your hash will differ. On Windows, Git may also print a warning about line endings during the first commit. The warning does not change the commit.

#6. Keep secrets out of the repository

Before you upload any file, check it for .env files, access tokens, customer data, cloud credentials, and private logs. A .gitignore file tells Git to skip matching files, which helps prevent accidents. It does not remove a secret that was already committed, because the old commit stays in the history.

An example .gitignore for a learning project:

.env
*.pem
*.log

If you commit a secret by mistake, revoke or rotate it first. Once the secret is revoked or rotated, the old value can no longer grant access, so rewriting history may not be worth the effort. GitHub's guide on removing sensitive data covers both steps, including the side effects of a rewrite.

#7. Common mistakes

• Pasting a token into the README to test it.
• Assuming a repository is private without checking the visibility setting.
• Uploading a real client file to practice with. Use synthetic data instead.
• Bundling many unrelated changes into one commit. Split the work into smaller commits.

#8. What to learn next

A web-based repository is useful for understanding structure and history. The next step is to learn what Git does on your own machine, then how git clone creates a local copy of a repository so you can work on it safely.

Keep only notes and exercises in this repository that you would be comfortable showing to anyone.