🛠 1. Initial Setup – One-Time Only

📌 Scenario: You’re using Git for the first time on your machine.

Set your user details (required for commits):

git config --global user.name "Alice Dev"
git config --global user.email "alice@example.com"

Optional settings:

git config --global core.editor "code --wait"         # Use VS Code as Git editor
git config --global pull.rebase false                 # Pull uses merge by default
git config --global init.defaultBranch main           # Default branch is main, not master

📥 2. Cloning a Repository

📌 Scenario: You’re joining a team or starting a project from GitHub or Azure DevOps.

git clone https://github.com/org/project.git
cd project

🧠 Analogy: Cloning is like downloading a working copy of a shared Google Doc where Git tracks every change.

🌿 3. Branching – Working in Isolation

📌 Scenario: You’re working on a new feature or fixing a bug.

Always start from the latest main:

git checkout main
git pull origin main
git checkout -b feature/signup-form

• feature/signup-form is your personal workbench.
• You can commit freely without affecting the main product.

🧠 Analogy: You forked a Google Doc to make your own edits before merging back.

🔄 4. Status, Add, Commit – Making and Saving Changes

You’ve made changes. What’s going on?

git status

You’ll see:

• ✅ Tracked files – Git knows these; changes will be recorded.
• ⚠️ Untracked files – Git has no record of them yet.
• 🔄 Modified files – You changed something but haven’t committed yet.

Stage changes (prepare them for commit):

git add file.txt          # Stage one file
git add .                 # Stage all changes

Commit:

git commit -m "Add signup validation"

🧠 Analogy: Think of add as selecting slides for a presentation, and commit as saving the version of that presentation.

🧳 5. Stashing – Save Without Committing

📌 Scenario: You’re halfway through work and need to switch tasks or rebase.

Basic stash:

git stash -m "WIP: signup flow"

Stash including untracked files:

git stash -u -m "WIP: with new files"

Get back stashed changes:

git stash pop            # Pops and applies top stash
git stash list           # View all stashes
git stash drop stash@{0} # Delete a specific stash

🧠 Analogy: It’s like saving a draft email without sending it.

🌐 6. Fetch, Merge, Rebase – Sync with Main

📌 Scenario: You’ve been working for days. The main branch is updated by others.

🔁 git fetch

git fetch origin

• Updates your local view of origin/main
• Doesn’t change your working branch

🧠 Analogy: Refreshing your inbox without replying yet.

🔀 git merge origin/main

git merge origin/main

• Combines your branch with the latest main.
• Keeps history with a merge commit.

🧠 When to use:

• Shared branches (safe)
• You want to preserve all commit history

🧠 Analogy: Combining two versions of a doc with a sticky note saying “merged here”.

🔁 git rebase origin/main

git rebase origin/main

• Replays your work on top of latest main
• Makes history look linear

🧠 When to use:

• Clean up before opening a Pull Request
• You haven’t pushed yet

🧠 Analogy: You move your edits to a new copy of the doc as if you started fresh.

⚔️ 7. Merge & Rebase Conflicts

📌 Scenario: You and a teammate changed the same file or line.

Git will say:

CONFLICT (content): Merge conflict in file.py

You’ll see conflict markers like:

<<<<<<< HEAD
Your code
=======
Their code
>>>>>>> origin/main

Fix the file, then:

git add file.py
git rebase --continue     # or git merge --continue

🚀 8. Pushing and Pull Requests

📌 Scenario: You’re done with your feature and want it reviewed.

git push origin feature/signup-form

Then go to GitHub/Azure and open a Pull Request (PR) into main.

🧠 Analogy: Submitting your edited draft for peer review.

✅ 9. Cleaning Up

After your PR is merged:

git checkout main
git pull origin main
git branch -d feature/signup-form              # local
git push origin --delete feature/signup-form   # remote

🧰 10. Advanced but Useful Commands

🧪 Real-World Scenarios

🔄 Scenario 1: Update your branch with latest main (safe way)

git stash -u -m "WIP before update"
git fetch origin
git rebase origin/main
git stash pop

If you hit a conflict, resolve it and continue with:

git add conflicted-file
git rebase --continue

🚧 Scenario 2: You want to stop working and pick up later

git stash -u -m "Login form in progress"
# go to another branch or pull updates
# come back
git stash pop

🚀 Scenario 3: Starting a new feature

git checkout main
git pull origin main
git checkout -b feature/payment-method

🛠 Scenario 4: Fix a critical bug on production

git checkout -b hotfix/critical-crash
# fix it
git add .
git commit -m "Fix crash"
git push origin hotfix/critical-crash

Open a PR into main or release and get it deployed.

💤 Scenario 5: You Made Changes, Took a Break, and Came Back

📌 Situation:

You were working on a feature. You made some changes locally but didn’t commit or push. You went on a weekend or short leave. Now you’re back.

Other teammates may have updated the main branch while you were away. You need to sync your branch with the latest main before continuing.

🧠 First Steps When You’re Back:

1. Check if you have uncommitted changes:

git status

• If yes: 🧳 stash your work to avoid losing it

git stash -u -m "WIP before syncing"

2. Fetch the latest changes from the remote:

git fetch origin

3. Rebase your branch on top of the updated main:

git rebase origin/main

This applies your commits on top of the new changes from main

4. Bring back your stashed changes (if any):

git stash pop

👇 Example Flow:

git status                       # You see uncommitted changes
git stash -u -m "WIP: login fix"
git fetch origin                 # Get the latest main
git rebase origin/main           # Replay your branch on top
git stash pop                    # Restore your work

🧠 Why this matters:

• Keeps your branch up to date
• Reduces conflicts later during PR
• Prevents pushing outdated code
• Makes your PR easier to review

✅ Pro Tip: Always fetch and rebase when returning from a break. It’s a small habit that saves hours of merge pain later.

🧠 Git Mental Model Cheatsheet

🔁 11. Renaming, Deleting, Reverting, and Resetting

These are essential for fixing mistakes, cleaning your repo, or handling files during refactors.

✏️ Rename a File

git mv oldname.py newname.py
git commit -m "Rename oldname.py to newname.py"

🧠 Analogy: Like moving a file in Google Drive — Git sees it’s the same content, just with a new name.

🗑️ Delete a File

git rm obsolete.js
git commit -m "Remove unused script"

• Removes file from version history from this commit onward
• File is still in past commits — Git never forgets unless forced

🔁 Undo with git revert (Safe Method)

git revert <commit-hash>

✅ Safest way to undo a commit ✅ Works even after you’ve pushed

• Creates a new commit that undoes the changes
• Preserves history

🧠 Analogy: You’re adding a new note saying “Actually, undo what I just did.”

💥 Reset with git reset (Dangerous But Powerful)

🟡 Soft Reset (keep changes, undo commit)

git reset --soft HEAD~1

• Last commit is removed
• Changes stay staged

🟡 Mixed Reset (default, keep changes unstaged)

git reset HEAD~1

🔴 Hard Reset (dangerous!)

git reset --hard HEAD~1

• Removes last commit
• Deletes any unstaged changes
• ⚠️ Use only if you’re 100% sure

🧠 Analogy: Like tearing out a page and throwing it away — no record unless someone copied it.

🧪 Scenario: You Made a Bad Commit

Use revert if you already pushed:

git revert 7a8b9c1

Use reset if it’s local only and you want to start over:

git reset --hard HEAD~1

💡 Bonus: Viewing Commit History

git log --oneline --graph --decorate --all

• Visualize commit history like a tree
• Helps understand merges, reverts, and branch relationships

📌 Summary: Undo Commands

✅ Final Pro Tips

• Use rebase before PRs for clean history
• Use merge on shared branches
• Always stash if you have uncommitted changes before pulling
• Avoid --force unless you understand rebase
• Small, frequent commits > giant ones
• Use revert if you already pushed the commit
• Use reset only for local rewrites
• Avoid reset --hard unless you’ve stashed or backed up work
• Git doesn’t lose data until you tell it to — but reset --hard will destroy uncommitted edits