Git

Everything you need to know before you type your first command.

1. Git – The Time Machine for the Code

Git is like a time machine for source code files. It is a “Distributed Version Control System” (DVCS) that keeps track of every change make to the project so you can look back, undo mistakes, or work with others without messing up each other’s work.

1. 1. The Three Core Jobs of Git

• Tracking Changes: Instead of saving files as is Git remembers every tiny edit you make to a single file.
• The “Undo”: If code breaks, instantly jump back to exactly how it looked yesterday (or three months ago).
• Collaboration: It allows multiple people to work on the same file at the same time. Git helps “merge” everyone’s changes together into one finished piece.

1.2. Git is a Distributed Version Control System.

• In the world of software development, a Distributed Version Control System (DVCS) is a type of version control where the complete codebase history including every change, branch, and commit is mirrored on every developer’s local computer.Unlike older Version Control Systems where you had to “check out” a file from a central server to work on it, a DVCS turns every workstation into a full-fledged backup of the project.

1.3. How it Works: The “Peer-to-Peer” Model

In a DVCS, there is typically a central server (like GitHub, GitLab, or Bitbucket), but its role is primarily for sharing and synchronization, not for storage of the “master” copy.

1. Cloning: When a developer starts working, they “clone” the entire repository. This downloads the latest code plus the entire history of every version ever made.
2. Local Commits: Developers record their changes (commits) locally. They don’t need an internet connection to save their progress, create new branches, or view past history.
3. Pushing & Pulling: When ready to share, the developer “pushes” their local history to the central server (like GitHub, GitLab, or Bitbucket), or “pulls” the latest history from their teammates.

1.4. Key Characteristics of a DVCS

1. Full Local Redundancy – Every developer has a full backup. If the main server crashes or the data is corrupted, any developer’s local repository can be used to restore the entire server with zero loss of history.
2. Speed and Performance – Because most operations (commit, diff, log, branch) happen on your local hard drive rather than over a network, they are nearly instantaneous. You only experience network latency when pushing or pulling.
3. Advanced Branching and Merging – DVCS tools like Git were built with branching as a core feature. Developers can create “feature branches” to experiment safely, merge them back, or delete them without ever bothering the rest of the team or the central server.
4. Offline Capability – You can work in a flight, in a remote area, or during an ISP outage. You can commit your work and manage your project history entirely offline, then sync everything once you are back online.

1.5. DVCS vs. Centralized VCS (CVCS)

1.6. Common DVCS Tools

• Git: The industry standard (used by Linux, Google, Microsoft, and most startups).
• Mercurial: Known for its simplicity and efficiency (formerly used by Facebook and Google).
• Bazaar: A project by Canonical (Ubuntu) focused on being easy to use.

1.7. Git vs. GitHub

• Git: The engine/tool on your computer.
• GitHub/GitLab: The cloud storage (Google Drive for code) where you share your work.

1.8. Essential Configuration

Before you start, sign your work so the team knows who wrote what:

git config --global user.name "Name"
git config --global user.email "username@domain.com"
git config --global core.autocrlf true  # Fixes Windows/Linux line ending mess

1.9 The .gitignore File

A .gitignore file as a “Do Not Enter” list. It tells Git which files are trash (like temporary logs) or private (like passwords) and should never be tracked or uploaded.

• Without this it will accidentally upload huge folders like node_modules, compiled code (.exe, .pyc), or sensitive .env files containing API keys.
• A plain text file named .gitignore in your project root and list file patterns inside it.
• Common Patterns:
  • *.log – Ignores all log files.
  • node_modules/ – Ignores the entire folder.
  • .env – Ignores environment variables (Security!).
• Global Gitignore: You can set a global list for your whole computer (e.g., to ignore Mac .DS_Store files everywhere).

1.10. SSH vs. HTTPS – Secure Connection

To talk to GitHub or GitLab, need a “door pass.” HTTPS uses your username/password, but SSH uses a digital “key pair” (Public and Private) which is much more secure and convenient for DevOps automation.

• HTTPS: Easier to set up but asks for a “Personal Access Token” frequently.
• SSH (Secure Shell):
  • You generate a key on your laptop (ssh-keygen).
  • You give the Public Key to GitHub.
  • You keep the Private Key safe on your machine.
  • DevOps Benefit: SSH is essential for Jenkins, GitLab CI, or GitHub Actions to pull code automatically without a human typing a password.

1.11. Git Internal Structure .git Folder

For an “Architect,” you should know what’s inside that hidden .git folder. It is basically a simple database.

• HEAD: A file that points to the branch you are currently on.
• config: Your project-specific settings.
• objects/: This is the heart. It stores all your code as “Blobs,” your folder structure as “Trees,” and your history as “Commits.”
• refs/: Stores the pointers for your branches and tags.

Here is your Step-by-Step Practical Lab for getting started with Git. Follow these instructions exactly to see how Git manages your files in real-time.

Core Foundations Lab

Lab 1.1: The Identity & First Snapshot

In this lab, you will introduce yourself to Git and take your first “Snapshot” (Commit) of a project.

Git – Install from this link before starting this lab.

Step 1: Introduction (Global Config)

Open your terminal (Command Prompt, Terminal, or Git Bash) and tell Git who you are. This information will be attached to every piece of code you write.

# Open command prompt and create one directory
mkdir git-lab
cd git-lab
# Run below commands to set your user details.(As of now does not require any remote repo for this)
# Set your name
git config --global user.name "Your Name"

# Set your email
git config --global user.email "yourname@example.com"

# Verify the settings
git config --list

Step 2: Initialize the “Time Machine”

Turn this normal folder into a Git Repository.

# Initialize git repo locally
git init

• Observation: You will see a message saying “Initialized empty Git repository.” A hidden folder named .git is created here. This is where Git stores all its data.

Step 3: Create a File

Create a simple text file.

# Create txt file
echo "Hello Git - This is my first version" > hello.txt

Step 4: Check the Status (The Red Stage)

Ask Git what is happening in the folder.

git status

• Observation: You will see hello.txt in Red. Git says it is “Untracked.” This means Git sees the file but isn’t watching it yet.

Step 5: Stage the File (The Green Stage)

Tell Git you want this file to be part of your next “Snapshot.”

git add hello.txt
git status

• Observation: The file name turns Green. Git says “Changes to be committed.” It is now in the Staging Area.

Step 6: The Permanent Snapshot (The Commit)

Save the version forever in the local database.

git commit -m "Initial commit: Add hello.txt"

• Observation: Git gives you a “Hash” (a unique ID like a1b2c3d) for this version. You have successfully created your first point in history!

Lab 1.2: The .gitignore “Do Not Enter” List

In this lab, you will learn how to keep your repository clean by hiding junk files from Git.

Step 1: Create “Junk” Files

In real coding, we often have temporary logs or huge folders that we don’t want to upload. Let’s create some.

# Create a dummy log file
echo "log data" > logs.txt

# Create a dummy folder (like node_modules in JavaScript)
mkdir node_modules
echo "heavy-data" > node_modules/library.js

Step 2: See the Mess

Check the status again.

git status

• Observation: Git shows logs.txt and node_modules/ in Red. It wants to track them.

Step 3: Create the .gitignore File

We will tell Git to ignore these patterns forever.

# Create the .gitignore file
touch .gitignore

# Open it in your editor and add these lines:
# logs.txt
# node_modules/

(Alternative for terminal users: echo "logs.txt" >> .gitignore and echo "node_modules/" >> .gitignore)

Step 4: Verify the Filter

Check the status again.

git status

• Observation: logs.txt and node_modules/ have disappeared from the status! Only .gitignore itself is visible because Git needs to track the list of rules.

Step 5: Save the Rules

git add .gitignore
git commit -m "Admin: Add gitignore to filter junk files"

2. The Core Workflow – The local lifecycle.

2.1 The Three Stages of Git

1. Working Directory: Where you edit your files.
   • Changes here are “untracked” or “modified.” They are not yet part of Git’s permanent memory.
2. Staging / Index Area: Where changes for the next commit.
   • This is a middle layer (a draft space) where you prepare for your next commit.
3. Local Repo: Where your “snapshots” are stored forever.
   • Git takes a “snapshot” of the staged files and stores them forever in the .git folder as a part of the project’s history.

2.2 The Big Four Commands

3. Branching & Merging

How multiple developers work on the same code without fighting.

3.1. The Git Branch

In Git, a branch is not a copy of your files; it is simply a lightweight, movable pointer to a specific commit.

• The Default Branch: By default, every Git repository starts with a branch named main (formerly master).
• The Purpose: Use branches to isolate your work. You can create a branch for a new feature, a bug fix, or an experiment.
• The Safety Net: While you work on a separate branch, the main branch remains untouched and stable. If your experiment fails, you can simply delete the branch, and your production-ready code stays safe.

3.2 Merging Logic

Once work on a branch is complete, you “merge” it back into your main branch. Git uses different logic depending on the history of the branches.

1. Fast-Forward Merge

This happens when the branch you are merging into (e.g., main) has not had any new commits since you created your feature branch.

• Git doesn’t need to combine anything. It simply moves the main pointer forward to the latest commit on your feature branch.
• A clean, straight line of history with no extra “merge commits”.

2. 3-Way Merge

This happens when both branches have changed since they diverged. For example, you were working on feature-A while a teammate pushed a fix to main.

• Git looks at the two branch snapshots and their common ancestor (the point where they split).
• Git automatically creates a new “Merge Commit” that ties the two histories together.

3. Conflict Resolution

Sometimes, automated merging fails. This happens when two people change the exact same line of the exact same file in different branches.

The Markers: Git will pause the merge and place markers in the affected file:

• <<<< HEAD: Your local changes.
• ====: The separator.
• >>>> [branch-name]: The incoming changes from the other branch.

The Fix:

1. Open the file and manually decide which code to keep.
2. Remove the <<<<, ====, and >>>> markers.
3. Save the file, then run git add and git commit to finalize the merge.

Lab 3.1: The Parallel Universe – Branching

Create a separate branch to build a feature while keeping your main branch safe.

Step 1: Check your current location

# Clone practice repo ready with main branch
# Clone remote repo
git clone https://github.com/Rajkumar-Aute/git-practices.git
# Change directory
cd git-practices
# check branches and active branch will be marked with *
git branch

• Observation: You will see * main. The asterisk (*) tells you which branch you are currently on.

Step 2: Create and switch to a new branch

git checkout -b feature-login

• Observation: This command does two things: creates a branch called feature-login and switches you to it.

Step 3: Make changes in the feature branch

Open hello.txt and change the text to: “Login Feature – Work in Progress”. Save the file.

# create hello.txt file
echo "Login Feature - Work in Progress" > hello.txt
# Adding hello.txt file to staging area
git add hello.txt
# committing hello.txt file to local repo
git commit -m "Feature: Start working on login logic"

Step 4: The Time Travel (Switch back to Main)

Watch your folder closely.

git checkout main

• Observation: Open hello.txt. The text has reverted to your very first version! This is because the “Login” changes only exist in the other branch.

Step 5: The Merge (Combining Work)

Now, bring that login feature into your main code.

# Merging / Moving hello.txt file from feature branch to main branch (Locally)
git merge feature-login

• Observation: Git performs a Fast-Forward merge. Now, main and feature-login are identical.

4. Git Strategy

A Git Strategy defines how a team protects their code, works together without fighting, and releases software safely to production.

1. The Mindset & Solo Strategy

Before you type a single command, understand that Git is a “Time Machine”. Its goal is to enable teamwork and protect the “Source of Truth”.

• Solo Strategy: When working alone on personal projects, the workflow is a straight line: Working Directory → Staging Area → Local Repo.
• The Rule: One feature = one commit. Never write “fixed stuff” as a message; explain what you fixed.

2. Team Collaboration – The Feature Branch

In small teams (2–5 people) or Agile sprints.

• The Strategy: Every new task gets its own Feature Branch.
• The Flow: 1. Create feature/login-page from main. 2. Work and commit locally. 3. Push to the server and open a Pull Request (PR). 4. Code Review: A teammate checks the code for bugs or security leaks. 5. Merge into main only after approval.

3. Git Flow – The Enterprise Standard

Large teams with scheduled releases (e.g., v1.0, v2.0).

This is a structured, multi-branch model:

4. GitHub Flow

GitHub Flow was created by GitHub to simplify the development process for web applications and SaaS. It follows a “Deploy-First” mindset.

• Main is Always Deployable: The main branch must always contain code that is stable and ready to go live at any second.
• No “Develop” Branch: There is no intermediate branch. You go straight from Feature → Main.
• PR-Centric: No code enters main without a Pull Request and a discussion.

1. The 6-Step Workflow

This is the standard cycle every developer follows in GitHub Flow:

1. Create a Branch: Start from main and give your branch a descriptive name (e.g., feature/add-login-button or bugfix/header-style).
2. Add Commits: Work on your code locally. Make small, frequent commits with clear messages.
3. Open a Pull Request (PR): As soon as you have a basic idea or some code (even if unfinished), open a PR. This starts the conversation.
4. Discuss & Review: Teammates look at your code, leave comments, suggest improvements, and ask questions. You can push more commits to the branch to address feedback.
5. Test & Deploy (Optional): Many teams deploy the feature branch to a “Staging” or “Preview” environment to see it live before merging.
6. Merge & Delete: Once approved, merge the PR into main. The code is deployed to production immediately. Then, delete the branch to keep the repo clean.

2. GitHub Flow Benefits

• Simplicity: Very easy for new developers to learn. Only one rule: “Don’t break main.”
• Continuous Delivery: Perfectly suited for CI/CD pipelines.
• High Quality: Forced code reviews ensure that at least two pairs of eyes see every line of code before it reaches the user.
• Agility: You can fix a bug and ship it in 15 minutes without waiting for a “Release Window.”

3. Comparison: GitHub Flow vs. Git Flow

4. Best Practices for GitHub Flow

• Keep Branches Short: A branch should ideally live for 1-3 days. If it’s longer, your feature is too big—break it down!
• Write Good PR Descriptions: Explain why you made the change, not just what you changed. Use screenshots for UI updates.
• Automated Checks: Set up GitHub Actions to run tests automatically on every PR. If tests fail, the “Merge” button should be locked.
• Protected Branches: Use GitHub settings to prevent anyone (even the boss) from pushing directly to main. Force everyone to go through a PR.

5. Trunk-Based Development – The DevOps Way

Trunk-Based Development is a version control strategy where developers merge small, frequent updates to a single central branch, typically called main or master. This is the opposite of “Git Flow,” where features live in separate branches for a long time.

• Continuous Integration (CI): Since everyone merges daily, the code is integrated constantly.
• Small Batches: Instead of a 1000-line “Mega-Commit,” developers push 50-100 lines of code multiple times a day.
• Single Source of Truth: There is only one version of the code that matters: the Trunk.

2. How it Works – The Workflow

1. Pull: Sync your local machine with the main branch.
2. Code & Test: Make a small change and run local automated tests.
3. Short-lived Branches (Optional): If you use branches, they must be deleted within 24–48 hours.
4. Merge: Push the code to main.
5. Automated Build: The CI server automatically builds the code and runs all tests to ensure nothing broke.

3. Key Technical Requirements

To make TBD work without breaking the entire application, two things are non-negotiable:

• Automated Testing: You must have a robust suite of unit and integration tests. Since there is no “QA Week,” the code must be verified by the system automatically.
• Feature Flags (Feature Toggles): This is a “switch” in the code.
  • Scenario: You are building a new Payment Gateway, but it will take 5 days.
  • Action: You merge the code daily, but wrap it in an if statement: if (payment_flag_enabled) { … }.
  • Result: The code is in Production, but the users can’t see it until you flip the switch.

4. Benefits of Trunk-Based Development

• Eliminates Merge Hell: When many people work on the same file in different branches for weeks, merging them becomes a nightmare. TBD solves this by merging every few hours.
• Increased Velocity: No waiting for “Release Managers” to approve branch merges. You code, you test, you ship.
• Better Code Quality: Because the “Trunk” must always be in a deployable state, developers are more disciplined about not breaking things.

5. Challenges to Consider

• High Seniority/Skill Required: Junior developers might find it scary to push directly to main.
• Culture Shift: It requires a “You build it, you run it” mindset.
• Infrastructure Cost: You need a very fast CI/CD pipeline to handle the constant merging and testing.

6. Release & Emergency – Hotfix

1. Tag-Based Releases – The Labeling System

In Git, a Tag is a permanent pointer to a specific point in your history. While branches move, tags stay put.

• Why use Tags? Without tags, “Production” is just a vague term. With tags, you can say, “Production is running exactly v1.4.2.” This makes it easy to roll back if something breaks.
• Semantic Versioning (SemVer): This is the industry standard for naming tags. It uses a three-part number: MAJOR.MINOR.PATCH (e.g., v2.3.1).
  • MAJOR: Big changes that might break old code (e.g., a total UI redesign).
  • MINOR: New features added, but everything still works as before.
  • PATCH: Only bug fixes (no new features).

2. The Hotfix Strategy

A Hotfix is a special type of branch used to quickly address a critical bug in the live production environment.

Step-by-Step Hotfix Process -When an emergency happens, you follow this specific path to ensure the fix is safe and doesn’t get lost:

1. Branch Out: Create a new branch named hotfix/v1.0.1 directly from the Main/Master branch (or the tag that is currently live).
2. Fix & Test: Apply the fix only for that specific bug. Do not add new features here. Run tests to make sure the fix works.
3. Merge to Main: Merge the hotfix branch back into main so the live site is fixed immediately.
4. Tag It: Create a new tag (e.g., v1.0.1) so you have a record of the fix.
5. Merge to Develop: Crucial Step! Merge the fix back into the develop branch. If you forget this, the bug will reappear in the next big release because the development code still has the old bug.

4. Best Practices for Emergency Fixes

• Keep it Tiny: A hotfix should only contain the code required to fix the emergency.
• Don’t skip QA: Even in an emergency, at least one other person should review the code (Peer Review).
• Automate Deployment: Use a CI/CD tool to push the hotfix to production instantly once the merge is approved.
• Delete the Branch: Once the hotfix is merged and tagged, delete the hotfix/ branch to keep the repository clean.

Comparison: Regular Release vs. Hotfix

Note: If you are using Trunk-Based Development, you usually don’t need a separate hotfix branch. You just fix it on the main trunk and deploy immediately. Hotfixes are most common in Git Flow or GitHub Flow environments.

Lab 4.1: The Enterprise Standard (Git Flow)

You are working on a massive project. You need to maintain a stable main branch, an integration develop branch, and specific branches for features and hotfixes.

Step 1: Initialize the Develop Branch

In Git Flow, main only stores production-ready code. All daily work happens in develop.

Note – fork practice Fork Rajkumar-Aute/git-practices repo to your github account

# Clone practice repo ready with main branch
# Clone remote repo or create a fork of this below repo and user your own github repo.
git clone https://github.com/Rajkumar-Aute/git-practices.git
# Change directory
cd git-practices
# check branches and active branch will be marked with *
git branch

# Ensure you are on main and up to date
git checkout main
git pull origin main

# Create and push the develop branch. Your need your own github repo.
git checkout -b develop
git push origin develop # this will throw error as you are working on readonly repo.

Step 2: Create a Feature Branch

# Switch to develop and create a new feature
git checkout develop
git checkout -b feature/login-module

# Create a file and commit
echo "Login logic v1" > login.txt
git add login.txt
git commit -m "Feature: Initial login logic"

Step 3: Simulate an Emergency (Hotfix)

While working on the feature, a critical bug is found in main. You must fix it without including unfinished develop code.

# 1. Switch to main (Production)
git checkout main

# 2. Create hotfix branch
git checkout -b hotfix/v1.0.1

# 3. Apply the fix
echo "FIX: Security patch applied" >> hello.txt
git add hello.txt
git commit -m "Hotfix: Resolve security vulnerability"

# 4. Merge back to main and Tag it
git checkout main
git merge hotfix/v1.0.1
git tag -a v1.0.1 -m "Urgent patch v1.0.1"
git push origin main --tags

# 5. CRITICAL: Merge the fix back into develop so future versions are safe
git checkout develop
git merge hotfix/v1.0.1

# Cleanup
git branch -d hotfix/v1.0.1

Lab 4.2: The Agile Standard (GitHub Flow)

Scenario: You are working in a modern SaaS team. You want to push a small feature, get it reviewed, and deploy it immediately.

Step 1: Create a Short-lived Feature Branch

git checkout main
git checkout -b feature/dark-mode

Step 2: Commit and Push

echo "body { background: #000; }" > styles.css
git add styles.css
git commit -m "UI: Add basic dark mode styles"
git push origin feature/dark-mode

Step 3: The Pull Request (PR) – Manual Step

1. Go to https://github.com/Rajkumar-Aute/git-practices.
2. Click the “Compare & pull request” button that appears.
3. Write a description and click “Create pull request”.
4. On the GitHub UI, click “Merge pull request” then “Confirm merge”.

Step 4: Cleanup

git checkout main
git pull origin main
git branch -d feature/dark-mode

Lab 4.3: The DevOps Way (Trunk-Based Development)

Scenario: You want to avoid “Merge Hell.” You push small, tested changes directly to main multiple times a day using Feature Flags.

Step 1: Code a Feature Flag

Instead of a long-lived branch, we wrap unfinished code in a “switch” so it can be safely pushed to main.

git checkout main

# Create a simple python script with a feature flag
cat <<EOF > app.py
# Feature Flag Configuration
NEW_PAYMENT_ENABLED = False 

def process_payment():
    if NEW_PAYMENT_ENABLED:
        print("Executing New Crypto Payment Gateway...")
    else:
        print("Executing Standard Credit Card Gateway...")

process_payment()
EOF

git add app.py
git commit -m "DevOps: Add Crypto Gateway behind feature flag"
git push origin main

Step 2: Flip the Switch

When the team decides the code is ready for users, you don’t merge a branch; you just change the config.

# Change False to True in app.py
sed -i 's/NEW_PAYMENT_ENABLED = False/NEW_PAYMENT_ENABLED = True/' app.py

git add app.py
git commit -m "Release: Enable Crypto Payment Gateway"
git push origin main

5. The “Fixer” Level – Handling Mistakes & Emergencies

In simple words, the Fixer Level is your “Undo” button and safety net in Git. Sometimes we make mistakes, commit the wrong code, or get interrupted by an urgent task.

• Resets are for going back in time (one is gentle, one is destructive).
• Reverts are the polite way to undo mistakes in a team project without messing up others’ work.
• Stash is like a temporary drawer where you hide your current messy work so you can deal with a “fire” (bug) and come back to it later.

1. Resets: Going Back in Time

When you want to move the “head” of your branch back to a previous commit, you use git reset. There are two main flavors:

1. Soft Reset –soft

• It moves the history back but keeps your changes in the staging area.
• Best for: When you realized you committed too early or want to combine (squash) multiple small commits into one clean one.
• Risk: Low. No code is lost.

2. Hard Reset –hard

• It moves the history back and completely deletes all changes made after that point.
• Best for: When you’ve made a total mess and want to “wipe the slate clean” to exactly how the code was before.
• Risk: Extreme. Use with caution! You cannot easily get deleted code back.

2. Revert vs. Reset

Choosing between these two depends on whether you are working alone or in a team.

Never reset a branch that has already been pushed to the server (GitHub/GitLab). Always use revert for public code.

3. Git Stash: The “Hold On” Button

Imagine halfway through a complex feature. Suddenly, In “Production is down! Fix it now!” You can’t commit your half-finished, broken code.

• git stash: Takes all your current uncommitted changes and puts them into a “secret storage.” Your working directory becomes clean (matching the last commit).
• Fix the Bug: switch branches, fix the bug, and deploy.
• git stash pop: Once the bug is fixed, back to feature branch and “pop” the stash. half-finished work reappears exactly where left it.

Useful Stash Commands:

• git stash save “Working on UI”: Gives your stash a name.
• git stash list: See all the things you have hidden away.
• git stash apply: Brings work back but keeps a copy in the stash.
• git stash drop: Permanently deletes the latest stashed work.

Lab 5.1: The Time Machine (Git Reset)

You made a commit too early and want to fix it (Soft Reset), and then you made a complete mess that you want to wipe away (Hard Reset).

Step 1: Soft Reset (The Gentle Undo)

1. Add a line “Feature Part 1” to hello.txt.
2. Commit it: git add . && git commit -m “Work in progress”.
3. Now, realize you wanted to add “Feature Part 2” in the same commit.
4. Run:git reset --soft HEAD~1
5. Observation: Run git status. You’ll see your changes are still there in the Staging Area. Git just “undid” the commit.
6. Action: Add “Feature Part 2” to the file, then commit again with a better message.

Step 2: Hard Reset (The Destructive Undo)

1. Add a lot of “trash” text to your files.
2. Commit it: git add . && git commit -m “Total mess”.
3. You decide this work is garbage and want to go back to the clean state.
4. Run:git reset --hard HEAD~1

Observation: Check your files. The “trash” text is completely gone. The history is rewritten. Warning: Never do this if you have already pushed the “mess” to GitHub.

Lab 5.2: The Professional Undo (Git Revert)

You pushed a commit to GitHub, but it has a bug. Since it’s on a shared remote, you must use the “polite” way to undo it.

Step 1: Create and Push a “Bug”

1. Add “This line causes a crash” to hello.txt.
2. Commit and Push:git add . git commit -m "Add: New feature logic" git push origin main

Step 2: Revert the Bug Instead of deleting the commit (which would break your teammates’ history), we will add a “fix-it” commit.

1. Run:git revert HEAD
2. Observation: A text editor will open for a commit message (usually “Revert ‘Add: New feature logic'”). Save and close it.
3. Action: Push the fix to GitHub.git push origin main

Conclusion: If you check git log, you will see the original commit AND the revert commit. This is the correct industry standard for public repositories.

Lab 5.3: The Temporary Drawer (Git Stash)

You are mid-way through a task, and your boss calls: “The production site is down! Switch to the main branch and fix it NOW!”

Step 1: Start a Messy Task

1. Switch to a new branch: git checkout -b big-feature.
2. Edit hello.txt with “Half-finished code…”. Do not commit.

Step 2: The Emergency Call You try to switch back to main, but Git might complain about uncommitted changes.

1. Run:git stash save "Work on big feature"
2. Observation: Run git status. Your working directory is perfectly clean! The “Half-finished code” is hidden in the stash.

Step 3: Fix the Emergency

1. git checkout main
2. (Imagine you fixed a bug here)
3. git checkout big-feature

Step 4: Retrieve Your Work

1. Run:git stash list # See your hidden work git stash pop

Observation: Your “Half-finished code” is back in the file. You can now continue your work.

6. Professional Git Techniques

1. Interactive Rebase git rebase -i

Interactive Rebase is the tool used to “rewrite history.” It allows you to clean up your commit history before sharing it with the team.

• The Problem: While working, you might make many small, messy commits like “wip,” “typo,” or “fix again.”
• The Solution: Use git rebase -i HEAD~n (where n is the number of commits). This opens a menu where you can:
  • Pick: Keep the commit as is.
  • Squash: Combine a commit into the previous one. This is the most popular use case.
  • Reword: Change a commit message.
  • Drop: Completely remove a commit.

2. Git Hooks: The Automation Layer

Hooks are scripts that Git executes before or after events like commit, push, or receive. They live in the .git/hooks folder.

1. Pre-commit Hook:
   • Runs before the commit is actually created.
   • Automatically running a “Linter” (to fix code formatting) or a security scan (to ensure you didn’t accidentally type your AWS password in the code). If the scan fails, the commit is blocked.
2. Pre-push Hook:
   • Runs before code is sent to the server.
   • Running all unit tests. If any test fails, the push is cancelled to prevent breaking the build for everyone else.

3. Handling Massive Projects

Standard Git struggles with very large files or giant “Monorepos” (where 100+ projects live in one repository).

1. Git LFS – Large File Storage

Git is great for text code but slow for heavy files (videos, 3D models, Photoshop files).

• Instead of storing the 500MB video in the Git history, LFS replaces it with a tiny “pointer” file. The actual heavy file is stored on a separate LFS server.
• Your git clone remains lightning-fast because you aren’t downloading every version of a 1GB file.

2. Sparse Checkout – The Selective Download

To work at a huge company with a 50GB repository, but only need to fix a bug in the “Login” folder, downloading the whole 50GB is a waste of time.

• init --cone: Prepares the repository to handle selective folders efficiently.
• set <folder>: Tells Git, “I only want to see this folder.” Everything else disappears from your disk (but remains safe on the server).
• add <folder>: Adds another specific folder to your view.
• disable: Returns the repository to a normal state where you see everything.

7. Git Commands

1. Setup & Configuration

Getting started and defining who you are.

2. The Core Local Workflow

The cycle of changing files and saving snapshots.

3. Inspecting History & Code

Understanding what happened in the past.

4. Branching & Tagging

Working in parallel universes and marking milestones.

5. Remote Synchronization

Sending and receiving code from the cloud.

6. Merging & Rebasing

Integrating changes from different branches.

7. Undoing & Recovery

Fixing mistakes at various stages.

8. Stashing & Advanced Tools

Temporary storage and specialized workflows.

Git Interview Question and Answers

• Don’t just say the command, explain the impact. (e.g., “Rebase makes history linear, which makes auditing easier.”)

• Mention “Best Practices”: Always talk about .gitignore, clear commit messages, and atomic commits.
• DevSecOps Mindset: Mention that “Git is the source of truth for Infrastructure-as-Code (IaC).”

The Core Foundations

Focus: Internalizing the Git mindset and the local lifecycle.

1. What is Git and why is it “Distributed”?
   1. Git is a DVCS. Unlike Centralized systems (SVN) where the server is the single source of truth, Git mirrors the entire history on every machine.
   2. DevOps Benefit: If the central server (GitHub) goes down, any developer can restore the full repository, including all branches and tags, from their local copy.
2. Explain the Git Three-Stage Architecture.
   • Working Directory: Your actual file system.
   • Staging Area (Index): A virtual “loading dock.” This allows you to perform Atomic Commits—you might have changed 10 files but only “stage” 2 that belong to a specific bug fix.
   • Local Repository: The .git directory where snapshots are cryptographically hashed and stored.
3. What is a “Commit” and why are messages important?
   1. A commit is a Snapshot, not a “diff” (it stores the whole file, not just the changes). Messages follow the Imperative Mood (e.g., “Fix bug” instead of “Fixed bug”) to act as instructions for the codebase’s future.
4. Difference between git pull and git fetch?
   1. fetch updates the origin/main pointer on your machine but doesn’t change your main branch. pull is a macro that runs fetch and then immediately tries to merge (or rebase) those changes into your current code.
5. What is the purpose of .gitignore?
   1. It prevents Repository Bloat. It stops binary files (like .exe), dependencies (node_modules), and secrets (.env) from being tracked. Once a file is committed, adding it to .gitignore won’t remove it; you must git rm –cached it first.

Good to Know

Focus: Solving collaboration friction and fixing common errors.

16. git merge vs. git rebase: When to use which?
    • Merge: Creates a “Merge Commit.” It preserves the context of when a feature branch existed.
    • Rebase: Rewrites history by moving your commits to the top of the target branch.
    • Pro Tip: Use Merge for shared branches to keep history accurate; use Rebase for local feature branches to keep history clean.
17. What is git stash?
    1. It takes your untracked and modified changes and pushes them onto an internal stack. It’s a “clean slate” button. Use git stash pop to bring changes back or git stash apply to keep them in the stack for multiple branches.
18. git reset vs. git revert?
    • Reset: Moves the branch pointer backward. It effectively “deletes” commits from the timeline.
    • Revert: Creates a New Commit that is the exact inverse of a previous commit.
    • Rule: If the code is already on GitHub, always Revert. Resetting public history causes “Merge Hell” for teammates.
19. What is git reflog?
    1. It stands for Reference Logs. Git tracks every time HEAD changes (switching branches, committing, rebasing). Even if you delete a branch, the commits stay in the database for 30–90 days, and reflog is the map to find their hashes.
20. What is “Trunk-Based Development”?
    1. A strategy where everyone merges to main at least once a day. It requires Feature Flags (toggles in the code) so that unfinished features can be merged into production without being visible to users.

Architect Advance Level

Focus: Plumbing, performance tuning, and automation.

41. What are Git Hooks?
    1. These are scripts located in .git/hooks.
    2. Client-side: pre-commit (runs linters/unit tests).
    3. Server-side: pre-receive (enforces commit message formats or blocks large files on the server).
42. How do you handle large binary files?
    1. Git is terrible at storing binaries (images/videos) because it can’t “diff” them. Git LFS replaces the binary with a text pointer in the repo, while the actual file lives on a separate LFS server. This keeps the .git folder small and cloning fast.
43. What are the 3 internal Git objects?
    • Blob: The content of a file (hashed).
    • Tree: A directory listing (hashes of blobs and sub-trees).
    • Commit: A pointer to a Tree, a parent Commit, and metadata (author/date).
44. What is “Sparse Checkout”?
    1. Standard Git downloads everything. Sparse checkout allows you to define a cone (a specific folder path). Git then only populates those files in your working directory. Essential for Monorepos where the total project size might be hundreds of gigabytes.
45. What is “rerere”?
    1. REuse REcorded REsolution. If you resolve a complex conflict and then rebase later, you might have to resolve it again. If rerere is enabled, Git remembers your previous fix and applies it automatically.
46. What is the “Index” file?
    1. It is a binary file (.git/index) that serves as the bridge between your Working Directory and the Repository. It contains a list of every file path in the project and the SHA-1 hash it should have.
47. How does Git ensure data integrity?
    1. Through Merkle Trees. Since every commit hash depends on its parent’s hash, you cannot change a commit from 2 years ago without changing every single hash that came after it. This makes Git a Block-chained history of code.
48. Explain “Plumbing” vs. “Porcelain” commands.
    • Porcelain: Commands made for humans (e.g., git status, git branch).
    • Plumbing: Low-level commands for scripting (e.g., git cat-file, git hash-object). In DevOps, we use plumbing to automate repository audits and cleanup.
49. What is git bisect?
    1. A debugging tool that uses Binary Search. You mark a “Good” commit and a “Bad” commit. Git then checks out the middle commit for you to test. It repeats this until it finds the exact commit that introduced a bug.
50. What is a “Bare Repository”?
    1. Created via git init –bare. It contains only the .git data and no working directory. You cannot edit files in a bare repo. This is what sits on servers like GitHub/GitLab to receive push events.