# Git Walkthrough — Learn by Doing ## Step 1: Your First Repository Let's start by creating a Git repository from scratch. **Task:** Create a new directory and initialize it as a Git repository. **Question:** Before we run any commands — what do you think `git init` actually creates? What would you expect to find in the directory afterward? **Checkpoint:** The user should mention the `.git` hidden directory and understand it stores Git's internal data. --- ## Step 2: Understanding the Three Areas Now let's explore how Git tracks changes. **Task:** Create a file called `hello.txt` with some content. Then run `git status`. **Question:** Git says your file is "untracked." What do you think that means? Where does the file live in Git's three-area model (working directory, staging area, repository)? **Checkpoint:** The user should explain that untracked means Git sees the file but isn't tracking changes to it yet. It exists only in the working directory. --- ## Step 3: Staging and Committing **Task:** Stage `hello.txt` with `git add`, then commit it. **Question:** Why do you think Git has a separate staging area instead of committing directly from the working directory? What advantage does this give you? **Checkpoint:** The user should understand that staging lets you choose exactly which changes to include in a commit — you can have 10 modified files but only commit 3. --- ## Step 4: Making Changes **Task:** Edit `hello.txt` to add a second line. Run `git diff` to see the changes. **Question:** What does the `+` and `-` notation in the diff output mean? Can you read the diff and predict exactly what changed? **Checkpoint:** The user can read diff output and explain additions (`+`) and removals (`-`). --- ## Step 5: Branching **Embed:** https://learngitbranching.js.org/ **Task:** Create a new branch called `feature` and switch to it. Make a change and commit it. **Question:** When you created the branch, did Git copy all your files? What actually happened under the hood? **Checkpoint:** The user should understand that a branch is just a pointer to a commit — no files are copied. It's extremely lightweight. --- ## Step 6: Merging **Task:** Switch back to `main` and merge your `feature` branch. **Question:** What kind of merge happened — fast-forward or three-way? How can you tell? **Checkpoint:** The user should be able to identify the merge type from the output and explain why that type was used. --- ## Step 7: Handling Conflicts **Task:** Create a conflict scenario: 1. On `main`, edit line 1 of `hello.txt` and commit 2. Create a branch, edit the same line differently, and commit 3. Try to merge **Question:** When you see the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`), what does each section represent? How do you decide which version to keep? **Checkpoint:** The user can resolve a conflict manually, understanding that the top section is their current branch and the bottom is the incoming branch.