3. Your First Repository

🏗️ Creating a New Repository

Create a new project folder and initialise Git inside it:

See the hidden .git folder Git created. You'll see a .git directory — that IS the repository:

📋 The Three States of a File

Every file in a Git repository is always in one of three states. Understanding this is the foundation of all Git operations:

🔄 The Core Workflow: Modify → Stage → Commit

Step 1: Check the current state of your repository. This shows untracked files, modified files, and staged files.

Step 2: Create a file.

Step 3: Check status again. README.md is now 'untracked'.

Step 4: Stage the file. Add it to the staging area. To stage ALL changed files at once, use git add .

Step 5: Commit the staged changes with a message.

Step 6: View the history. This shows each commit: hash, author, date, and message.

📝 Writing Good Commit Messages

Commit messages are the only documentation of why a change was made. In six months, when something breaks, your commit history is the investigation tool. Write messages for your future self:

• Bad: fix stuff
• Bad: updated files
• Bad: wip
• Good: Fix null pointer exception when user profile is empty
• Good: Add rate limiting to /api/login endpoint (prevents brute force)
• Good: Refactor database connection pool — reduce timeout from 30s to 5s

🐙 Creating a Repository on GitHub

Most projects start on GitHub first, then get cloned locally. Here is the exact sequence every professional uses:

1. Go to github.com → click the + icon → New repository
2. Give the repo a name (e.g., my-project). Use lowercase and hyphens — no spaces.
3. Choose Public (visible to anyone) or Private (only you + collaborators).
4. Check Add a README file so the repo is not empty.
5. Click Create repository.

GitHub now shows you the repo. To bring it to your local machine:

You are now inside a fully wired Git repository — origin already points to GitHub. Start coding immediately.

🔁 Starting a Local Project and Pushing to GitHub

Sometimes you start coding locally before creating a GitHub repo. Here is how you wire them together:

Now create a blank repo on GitHub (do NOT check README this time — your local files are the source of truth). Copy the SSH URL GitHub gives you, then:

Your project is now live on GitHub.

✍️ Writing Commit Messages Like a Professional

Commit messages are the permanent documentation of every decision ever made in a codebase. A well-written history lets you debug, audit, and onboard teammates in minutes instead of hours.

The Anatomy of a Great Commit Message

A commit message has two parts: a subject line (mandatory) and a body (optional but powerful):

Rules for the subject line:

• Keep it under 72 characters — GitHub truncates beyond this
• Write in imperative mood: "Add feature" not "Added feature" or "Adding feature"
• Do NOT end with a period
• Prefix with a type (see Conventional Commits below)

The Conventional Commits Standard

Most teams follow Conventional Commits — a lightweight specification that makes commit history machine-readable and changelog-ready: