Before we look at how teams work together safely, let’s do a quick recap of the two commands you need right after git add:

• git commit: This takes everything in your staging area and saves it as a permanent snapshot (a history receipt) with a message explaining what you did. (We will look at this in depth in just a moment!)
• git pull: (Note: We mentioned this briefly here just for learning purposes, but we will dive deep into when to use git pull, git merge, and git rebase, which one is safest, and when to use each in a dedicated future post!) This fetches the latest code changes your teammates have pushed to GitHub and merges them directly into your local workspace so you are always up to date.

0. A Closer Look at git commit (Saving Your Permanent Snapshot)

While git add selects your changes, git commit is where those changes are permanently locked into your project's history.

Why is git commit crucial?

• Creates a permanent record: Every commit acts as a distinct version checkpoint. If something breaks three months from now, you can look back at exact commits to see what changed and who changed it.
• Requires a message: Git forces you to attach a note with -m "Your message here" so anyone reading the project history knows why the change was made.

Best Practices for Writing Commit Messages

A good commit message should be short, descriptive, and clearly state what the change does. Many professional teams follow standard prefixes to keep history readable:

• feat: for a brand-new feature (e.g., git commit -m "feat: add user login screen")
• fix: for fixing a bug (e.g., git commit -m "fix: resolve crash on app startup")
• docs: for updating documentation or README files

Pro Tip for Team Cleanliness: Always make a separate commit for functional changes and clean-up commits. Do not mix code refactoring, whitespace cleanups, or deleting unused files into the same commit where you are adding core logic. Keeping them separate makes it much easier for your team to review actual code changes and trace bugs.

1. The Team Trap: Why Working in a Team Changes Everything

When you work entirely by yourself, a mistake only affects your own machine. But the moment you collaborate with a team, the dynamic shifts completely.

Your daily team workflow looks like this:

1. You pull the latest code updates from GitHub (git pull).
2. You write your new feature on top of that shared foundation.
3. You stage (git add), commit (git commit), and share your code.

In this environment, you have to be extra careful. A single careless git add . can accidentally bundle up your unfinished experiments, broken configuration files, or local debug keys and push them straight to the shared repository—bringing down the entire codebase for your team.

Don't panic if you’ve broken things or made a messy commit before—that is literally the only way anyone learns Git! Let's break down how to prevent accidents and how to undo them when they happen.

2. How to Avoid Accidental Staging (Prevention)

Before you blindly throw everything into your staging area using git add . or git add -A, use these safety rails:

• Always check your status first: Run git status before adding anything. Look at the red list. Are there random .DS_Store files, local environment files (.env), or half-baked test scripts staring back at you? Do not use a blanket git add . if there is clutter.
• Use .gitignore like a bouncer: Make sure your project has a proper .gitignore file so Git automatically blocks build folders, node modules, and local secrets from ever showing up in your working area.
• Be surgical with git add -p: Use interactive patching when you're working on team code so you can review every single line before it enters your staging area.

3. Oh No, I Added the Wrong Files! How Do I Revert? (git reset)

Let's say you panicked and ran git add ., and now half your team's broken experimental code is sitting comfortably in your staging area (green).

How do you take items out of the staging area without deleting your actual code?

Unstaging a Specific File

If you want to pull just one file back out of the staging area into your working area:

• The Command: git restore --staged <filename> (or the older version: git reset HEAD <filename>)
• What it does: It removes the file from the staging area, but your actual code edits remain safely untouched in your working directory.

Unstaging EVERYTHING at Once

If you want to clear your entire staging area and start fresh:

• The Command: git reset
• What it does: Instantly empties your staging area. Everything turns back to red, giving you a clean slate to re-curate your changes properly.

4. What if I Already Committed the Mistake? (git reset --soft vs --hard)

What if you didn't just stage the mistake—you actually committed it, or realized right after committing?

Depending on how bad the mistake is, Git gives you different escape hatches:

Option A: The "Oops, take back the commit, keep my code" (git reset --soft HEAD~1)

• When to use: You committed too early, or your commit message has a typo, and you want to undo the commit without losing any of the code you just wrote.
• What it does: It steps back one commit (HEAD~1), completely erases the receipt, but leaves all your changed files sitting safely in your staging area so you can fix them.

Option B: The Nuclear Option ("Delete everything and take me back to yesterday") (git reset --hard HEAD~1)

• When to use: Your entire codebase is broken, nothing compiles, and you just want to completely wipe out your last commit and all uncommitted changes to return to a clean, working state.
• ⚠️ WARNING: This will permanently destroy any uncommitted work you haven't saved elsewhere. Use with extreme caution!

Embrace the Breakages

Every senior engineer you look up to has accidentally pushed a broken build, wiped a file, or had a minor heart alarm staring at a Git terminal. Breaking things is not a failure—it is the crash course that teaches you how Git works.

Take risks, test things out locally, and remember: as long as you haven't force-pushed a disaster to the shared online repository, almost everything on your computer can be fixed.

So far in this series, we have learned how to set up our development environment, create repositories on GitHub, initialize local projects, properly add and curate code, and lock down clean commits. Stay tuned as we keep building our workflow mastery!

When you are starting out with Git, commands like git commit or git push get all the glory. But before you can save or share anything, you have to answer one critical question: How do you actually tell Git which files you want to include?

That is where git add comes in. But first, before we even start coding, how do we actually create a repository on GitHub, open it locally, and connect them together?

0. Setting Up the Repository: GitHub, git init, & Remote Linking

If you create a brand-new project folder on your computer, Git doesn't know about it yet.

1. Creating a Repository on GitHub

Before linking anything locally, you need a home for your project in the cloud:

• Go to GitHub.com and log into your account.

• In the top-right corner, click the + icon and select New repository.

• Give your repository a name (e.g., my-website), choose whether it should be Public or Private, and leave all other boxes (like README or .gitignore) unchecked so the repository stays completely empty.

• Click Create repository. Copy the repository URL provided on the next page.

2. Initializing Git Locally (git init)

• Where to run it: Open your terminal, use the cd command to navigate directly into your project's main folder (root directory), and run it there. For example: cd Desktop/my-website You can also do this by using Finder on mac and File Manager on windows/linux,navigate to folder in which you have all the files of your project and right click on folder choose open in terminal and run command.

• The Command: git init

• What it does: It sets up an empty tracking system inside your folder, telling Git to start paying attention to everything happening inside.

3. Connecting to GitHub (git remote add origin)

• Where to run it: Right inside the same project folder terminal.

• The Command: git remote add origin https://github.com/your-username/your-repo-name.git

• What it does: It links your local project folder to your online remote repository URL so you can push and pull code.

1. Why Do We Need a Staging Area Anyway?

When working with files, your project is split into two main zones to give you complete control over your progress:

• The working area: This is your actual project folder where you type, edit, and experiment. Everything you change lives here immediately. It can contain finished work, half-written notes, and accidental mistakes all mixed together.

• The staging area: This is a temporary holding space that sits between your project folder and your permanent history. It allows you to hand-pick specific parts of your work rather than saving everything at once.

Why this setup is important:

• Prevents messy records: If you saved your work automatically without a selection step, your project history would quickly become a cluttered mix of unfinished thoughts and random edits.

• Allows selective saving: You might change five different files while fixing a problem, but you only want to save the updates for two of them right now. This system lets you choose precisely what goes into your permanent record.

• Reduces mistakes: By moving items into a holding space first, you get a clear chance to review your choices and make sure you are not saving broken or unwanted changes by accident.

2. All the Variations of git add (The Complete Guide)

Depending on what you need, here are all the variations of git add you will ever need:

1. The Single Item (git add <filename>)

• The Command: git add index.html

• Real-World Scenario: You fixed a quick typo in index.html, but you also have half-finished, broken code in style.css. You only want to stage index.html so you can commit the fix immediately.

2. The Current Aisle (git add .)

• The Command: git add .

• Real-World Scenario: You just finished building a new "Contact Us" page. You created contact.html, contact.css, and modified app.js. Because they all belong to this one feature, you use the dot (.) to stage them all together.

3. The Entire Store (git add -A or git add --all)

• The Command: git add -A

• Real-World Scenario: You did a massive project cleanup—moving files into new folders, deleting old unused images, and updating links everywhere. You want to make sure every single move, deletion, and edit is staged project-wide.

4. The Replacements Only (git add -u or git add --update)

• The Command: git add -u

• Real-World Scenario: You updated several files to fix a bug, but you also created a brand new test-scratchpad.js file just to try out some random ideas. You want to stage all your bug fixes, but ensure your messy scratchpad is ignored.

5. The Category Batch (git add *.extension or git add folder/)

• The Command (by file type): git add *.js

• The Command (by folder): git add src/components/

• Real-World Scenario: You ran an image optimizer that modified 50 PNG images across your project. Instead of adding them one by one, you use git add *.png to stage just the images without touching your code files.

6. The Pro Inspector (git add -p or git add --patch)

• The Command: git add -p

• How it works: Git walks through your code chunk by chunk and asks y (yes to stage), n (no to ignore), or s (split into smaller pieces).

• Real-World Scenario: You were working in auth.js and fixed a login bug at the top of the file. But further down in the same file, you started writing an incomplete "reset password" feature. You use -p to stage only the bug fix lines and leave the incomplete code unstaged.

7. The Rule Breaker (git add -f or git add --force)

• The Command: git add -f secret-config.env

• Real-World Scenario: Your project is set up to automatically ignore all .log files (via .gitignore). However, you specifically need to commit an example_error.log file to show your team what a server crash looks like.

8. The Wishlist (git add -N or git add --intent-to-add)

• The Command: git add -N new-feature.js

• Real-World Scenario: You created a blank database.js file but haven't written the code yet. You want Git to acknowledge it exists so it shows up when you run git diff while you are writing, but you don't actually want to stage it for a commit yet.

3. How to Double-Check Before You Commit

Before you commit your changes, always verify what you have staged using: git status

• Files in green are staged and ready to be locked in.

• Files in red are modified files sitting loose in your working area.

You can also view the exact line-by-line changes waiting in your staging area by running: git diff --staged

What’s Next?

By mastering repository creation, initialization, and all the variations of git add, you have complete control over how you curate your changes. You no longer have to guess what is going into your repository!

In the next part of our workflow series, we will take those items out of the staging area and complete the transaction by mastering git commit best practices.

Stay tuned, and happy coding!

Now that you know why you need Git, it is time to get your hands dirty and set it up on your local machine. Don't worry, it only takes a few minutes!

Step 1: Install Git

Depending on your operating system, the installation process is straightforward:

• For macOS: Open your terminal and type git --version. If Git isn't installed already, macOS will automatically prompt you to install the command-line developer tools. Alternatively, you can download it directly from git-scm.com.

• For Windows: Download the official installer from git-scm.com. During installation, you can safely stick to the default settings recommended by the installer (the Git Bash terminal included is fantastic).

• For Linux (Ubuntu/Debian): Open your terminal and run:

  sudo apt update
  sudo apt install git
  

Step 2: Verify the Installation

To make sure everything is installed correctly, open your terminal or command prompt and run:

git --version

Step 3: Configure Your Identity

Before you start writing your first "prescription" (commit), Git needs to know who you are. This ensures that every change you make is stamped with your name and email.

Run the following commands in your terminal, replacing the details with your own name and the email associated with your GitHub account:

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

You can verify this configuration as well by running:

git config --list

What Even Is "The Cloud"? (And Why Do We Need It?)

Before we connect your computer to GitHub, let's clear up one phrase that often scares beginners: "The Cloud".

You've probably heard people say, "Save your code to the cloud" or "Upload it to GitHub." It sounds like some magical, floating mystery in the sky, right?

In reality, the cloud is just someone else's computer (a server) sitting in a secure data centre somewhere else in the world.

Think of it like this:

• Your Local Machine (Your Laptop): This is your personal notebook. You write code here, test it, and make mistakes. It is private, but if your laptop ever breaks, gets lost, or spills coffee on itself, that notebook is gone.

• The Cloud (GitHub): This is like a secure, 24/7 bank safety deposit box. When you push your code to GitHub, you are making a safe backup copy on their massive computers.

So, when we talk about "connecting your computer to GitHub", we just mean setting up a secure bridge so your laptop can easily send safe backup copies of your code over to GitHub's servers!

Step 4: Connecting Your Computer to GitHub

Now that your computer knows who you are, it needs a secure way to talk to GitHub.

To bridge your laptop and GitHub, you have two main options: SSH or a PAT (Personal Access Token).

Option 1: SSH (The "Set It and Forget It" Way) — Recommended

How it works (The Padlock Example): Think of an SSH key like a padlock and a physical key. You give GitHub the open padlock (your "public key"), and you keep the only physical key that opens it (your "private key") safely hidden on your laptop. When your laptop tries to send code, GitHub checks if your key fits the padlock. Since it matches perfectly, you are instantly recognized without ever typing a password.

(Curious about the tech magic behind this? It's called Asymmetric Cryptography. You can read a great, beginner-friendly explanation of how it works right here.)

• Pros: Once you set it up, you never have to type a password or token again. It works quietly in the background forever.

• Cons: Requires a few terminal commands to set up the first time.

How to set up SSH:(Note: The only thing you need to change below is your email address in Step 1! For the rest, you can copy and paste the commands exactly as they are. The ~ symbol is a smart terminal shortcut that automatically figures out your computer's username.)

1. Generate your padlock and key (replace with your GitHub email):

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

2. Press Enter through all the default prompts to save the key in the standard location without a passphrase.

3. Start the background service that holds your key by running:

   eval "$(ssh-agent -s)"
   

4. Add your new key to the background service:

   ssh-add ~/.ssh/id_ed25519
   

5. Copy your public key (the padlock) to your clipboard so you can give it to GitHub:

   • macOS:

     pbcopy < ~/.ssh/id_ed25519.pub
     

   • Windows (Git Bash):

     clip < ~/.ssh/id_ed25519.pub
     

   • Linux:

     cat ~/.ssh/id_ed25519.pub
     

     (and copy it manually)

6. Finally, go to your GitHub account > Settings > SSH and GPG keys > New SSH key, paste your key there, give it a title (like "My Laptop"), and save it!

   

Dissecting the Magic (What Did You Just Type?)

If you have never used a terminal before, typing those commands can feel like casting a spell in a language you don't understand. Let's break down exactly what you just told your computer to do, word by word.

1. Generating Your Keyssh-keygen -t ed25519 -C "your.email@example.com"

2. Starting the Background Serviceeval "$(ssh-agent -s)"

Think of ssh-agent as a security guard that runs in the background of your computer, holding onto your keys so you don't have to keep typing a password.

3. Handing Your Key to the Guardssh-add ~/.ssh/id_ed25519

Now that the guard is awake, you have to actually hand them your new physical key to hold onto.

Option 2: PAT (The "Digital Badge" Way)

How it works (The VIP Wristband Example): Think of a PAT like a temporary VIP wristband at an event. Later on, when you try to send your code to GitHub for the first time, your computer will ask for your GitHub password. Instead of typing your real password (which GitHub actually blocks for security reasons!), you simply paste this token. If you ever lose the token, you can instantly cancel it and get a new one without changing your real password.

• Pros: Very straightforward; if you ever worry about security, you can instantly delete just that token from your settings.

• Cons: Tokens expire (like every 30 or 90 days). When they expire, your code pushes will suddenly fail until you generate a new one.

How to create a PAT:

1. Go to GitHub > Settings > Developer settings > Personal access tokens > Tokens classic.

2. Click Generate new token, give it a name, choose how long it should last, and check the repo permission scope so it can manage your code.

3. Click generate, copy the token string, and keep it somewhere safe (GitHub only shows it to you once!). Remember, you will use this token whenever Git asks for your password in the terminal.

   

Which one should you pick?

• Go with SSH if you are on your personal laptop. Almost every developer uses it because you set it up once and never have to worry about passwords again!

• Go with a PAT if you prefer a simpler setup or if you are working on a temporary device.

Summary & A Quick Reminder

To wrap up: You have just given your computer a secure, password-free way (SSH) or a VIP digital badge (PAT) to talk to GitHub.

A quick note: If terms like "repository," "HTTPS," or "pushing code" still feel a bit confusing right now—please don't overthink them! We are going to look at all of these dedicatedly in the next part of this series when we actually start using them. For now, just pat yourself on the back. The hardest, most technical part of the setup is officially done!

There is no point in putting such efforts in if we can't reuse them in the future when we need them.

We can feel the pain through this analogy. Imagine visiting a doctor who just tells you a diagnosis and a list of medicines verbally. By the time you reach home, you might forget the dosage or the exact name.

Doctors write everything down on a prescription. It acts as a reliable record of what worked, what didn't, and what needs to be followed up on.

As engineers, our code is our prescription for solving the problems. Without version control, we are just working from memory—hoping we remember why we wrote a specific line of code six months ago.

Git is your personal notebook that tracks every single change you make to your code.

It allows you to experiment fearlessly. If a new feature breaks your application, you don't have to panic or hit "Undo" a hundred times; you simply revert to a stable version.

It saves your past efforts, allowing you to copy, adapt, and reference solutions you built months ago instead of reinventing the wheel.

If Git is your personal notebook, GitHub is the secure cloud archive where you back it up and share it with the world.

Just as multiple specialists might need to look at a patient's chart, team members can review, suggest improvements, and build upon your code seamlessly.

It serves as public proof of your work, showing the evolution of your skills and projects.

This post is part of my Git & GitHub Series, dedicated to taking you from version control beginner to confident developer. Stay tuned for the next article in this category, where we’ll dive into how to set it up on your machine!