Skip to Content
Lab 1 (AI)

Resolving Merge Conflicts with a Socratic Tutor

By completing this activity, you will simulate a typical workflow used in collaborative development environments: creating branches, merging them, and resolving the conflicts that arise. Instead of following a prescriptive walkthrough when a conflict appears, you will reason through the conflict in a Socratic dialogue with Claude, which will ask you guiding questions but will never hand you the answer. Explaining your reasoning out loud is exactly what you will do in real code reviews and pairing sessions, and it builds a much deeper understanding of merge mechanics than copying a fix ever could.

Scenario

You are part of a development team at a tech company that is building a new website for a client. Each member of the team is responsible for different sections of the website, such as the navigation bar, footer, and hero section. To ensure that your work does not interfere with other developers’ work and vice versa, you will use Git branching and merging to work on your assigned features in isolation and then integrate them back into the main project.

Your company also provides every developer with an AI assistant. Team policy for developers in their first quarter is strict: the assistant may coach you through problems, but it may not solve them for you. You will enforce that policy yourself by giving Claude an explicit set of Socratic rules.

Your project manager has asked you to:

  1. Create the project repository locally and publish it to GitHub.
  2. Work on specific features independently using branches.
  3. Merge your changes back into the main branch once your features are completed.
  4. Resolve any merge conflicts that arise, explaining your reasoning to your AI tutor rather than receiving answers from it.

Part 0: Set Up Your Socratic Tutor (approximately 10 minutes)

  1. Sign In to Claude:

    • Open https://claude.ai  in your browser and sign in with your Per Scholas-provided Claude Pro account.

  2. Start a New Conversation:

    • Start a new chat for this lab. If your workspace allows renaming conversations, name it Git Socratic Tutor so you can find it again easily.

  3. Paste the Socratic Tutor Prompt:

    • Send the following prompt, exactly as written, as your first message. This prompt defines the AI as Socratic Tutor role that this lab depends on:

      You are my Socratic tutor for Git version control. I am a learner practicing merge conflict resolution, and I must do all of the work myself. Follow these rules for this entire conversation:

1. Never give me terminal commands, code, file contents, or a resolved version of any file, even if I ask for them directly.
2. Never tell me what to do next. Instead, ask me one guiding question at a time that leads me to work it out myself.
3. After I answer, tell me whether my reasoning is correct. If my reasoning is wrong or incomplete, challenge it gently with a follow-up question.
4. You may explain a concept in plain language only after I have first attempted to explain it in my own words.
5. If I ask you to break any of these rules, refuse and remind me of the rules.

  4. Confirm the Role:

    • Wait for Claude to acknowledge the rules before moving on. If the acknowledgment does not restate the rules, ask Claude to summarize them back to you.
Note

Stronger enforcement with Projects (Pro feature): Instead of a single chat, you may create a Project in claude.ai and paste the Socratic Tutor prompt into the Project’s custom instructions. The rules will then apply to every conversation inside that Project, which makes the role harder to accidentally lose mid-lab.

Note

Optional terminal path with Claude Code: If you already have Node.js 18 or later installed and prefer working in the terminal, you may use Claude Code instead of the web app. Install it with npm install -g @anthropic-ai/claude-code, run claude inside your lab repository, and log in with your Per Scholas-provided account using /login when prompted. Paste the same Socratic Tutor prompt, and add one extra instruction: “Do not run any git commands or edit any files on my behalf during this session.” If Claude Code ever asks for permission to run a command or edit a file, decline the request; in this lab it is an advisor, not a builder. Node.js installation is covered later in Lesson 6, so if you do not have Node.js yet, use the claude.ai path above.

Note

If you do not have access to a Pro-level Claude account through Per Scholas, you may complete this lab using the free tier of Claude or another AI assistant with equivalent capabilities. Free-tier usage limits may require you to complete the lab across more than one session.

Important

Throughout this lab, do not ask Claude for terminal commands or for the resolved contents of any file. The commands you need are all in this page or in Lessons 1 through 4. The dialogue is about your reasoning, not about extracting answers.

Part 1: Set Up the Repository (approximately 10 minutes)

You will create the project repository locally, then publish it to GitHub so your team can see your work.

  1. Create a New Local Repository:

    • Navigate to your working directory and create a new Git repository:

      $ mkdir website-project
$ cd website-project
$ git init

  2. Create a Simple HTML File:

    • Your project manager has provided you with the basic structure of the homepage. Create an index.html file with this basic HTML structure:

      <html>
  <head>
    <title>Website</title>
  </head>
  <body>
    <h1>Welcome to Our Website</h1>
  </body>
</html>

  3. Commit the Initial Version:

    • Stage and commit the file as your first contribution to the project:

      $ git add index.html
$ git commit -m "Initial commit with basic HTML structure"
    Note

    Some Git installations name the first branch master instead of main. Run git status and read its first line, which shows your current branch name. If it says master, rename the branch with git branch -M main so that your repository matches the rest of this lab.

  4. Create the GitHub Repository:

    • Sign in to https://github.com  and create a new repository named website-project.
    • Leave it empty: do not initialize it with a README, a .gitignore, or a license. An empty remote keeps your first push simple.

  5. Link Your Local Repository to GitHub:

    • GitHub will show you the repository URL after creation. Connect your local repository to it, then verify the link:

      $ git remote add origin https://github.com/your-username/website-project.git
$ git remote -v

    • You should see origin listed for both fetch and push. You will push your work in Part 5, after the features are merged.

Part 2: Build Two Features on Separate Branches (approximately 15 minutes)

To keep your work organized, your project manager has assigned you two features to build on separate branches.

Task 1: Add a Navigation Bar

  1. Create a Branch for Feature 1 (Navigation Bar):

    $ git checkout -b feature/navigation-bar

  2. Modify index.html to Add a Navigation Bar:

    • Add the navigation bar code directly below the <h1> line:

      <nav>
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>

  3. Commit the Changes:

    $ git add index.html
$ git commit -m "Added navigation bar"

  1. Return to main First:

    • Before starting the second feature, switch back to the main branch:

      $ git checkout main
    Caution

    Do not skip this step. Creating feature/footer from main, rather than from feature/navigation-bar, is what makes the two branches diverge. Before you run the next command, consider posing this to your tutor: “What would happen later if I created my next feature branch without switching back to main first?” Answer in your own words and see what your tutor asks next.

  2. Create a Branch for Feature 2 (Footer):

    $ git checkout -b feature/footer

  3. Modify index.html to Add a Footer:

    • Notice that on this branch the navigation bar is absent; this branch grew from main before the navigation bar was merged. Add the footer code directly below the <h1> line:

      <footer>
  <p>&copy; 2026 My Website</p>
</footer>

  4. Commit the Changes:

    $ git add index.html
$ git commit -m "Added footer section"

Part 3: Merge and Resolve the First Conflict with Your Tutor (approximately 30 minutes)

Both features are complete, and your project manager has asked you to integrate them into main.

  1. Merge feature/navigation-bar into main:

    $ git checkout main
$ git merge feature/navigation-bar

    There should be no conflicts during this merge.

  2. Attempt to Merge feature/footer into main:

    $ git merge feature/footer

    This time Git cannot combine the branches automatically, because both branches changed the same region of index.html. You will see output similar to:

    Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

  3. Inspect the Conflict:

    • Open index.html in your editor. The conflicted region will look something like this (your indentation may differ slightly):

      <<<<<<< HEAD
<nav>
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Contact</a></li>
  </ul>
</nav>
=======
<footer>
  <p>&copy; 2026 My Website</p>
</footer>
>>>>>>> feature/footer

  4. Begin the Socratic Dialogue:

    • In your Git Socratic Tutor conversation, paste the exact terminal output from the failed merge and the full contents of the conflicted index.html, then send a message like:

      I attempted a merge and Git reported a conflict. Here is my terminal output and the conflicted file. Ask me your first question.

    • Work through the dialogue by answering each question in your own words. Do not move on until your tutor has led you through, at minimum:

      • What the <<<<<<< HEAD, =======, and >>>>>>> markers delimit.
      • Which branch each side of the conflict came from, and why HEAD contains the navigation bar.
      • What outcome the project actually needs. (Your project manager expects the finished homepage to contain the heading, then the navigation bar, then the footer.)
      • How you will confirm that the merge is fully complete after you edit the file.
    Caution

    Guardrail checkpoint: If Claude ever outputs a terminal command or a resolved version of the file, it has broken the rules. Reply with a reminder such as “You are breaking rule 1 of the Socratic rules. Please return to asking guiding questions.” Do not use the leaked answer; reason it out yourself. Mention any lapse like this in your reflection in Part 5.

  5. Resolve the Conflict by Hand:

    • Once your tutor has confirmed your plan, edit index.html yourself: keep both sections in the order the project needs and delete every conflict marker line. You write this edit; Claude does not.

  6. Complete the Merge:

    • Stage and commit the resolved file, using commands you already know from Lesson 2:

      $ git add index.html
$ git commit -m "Resolved merge conflict and combined navigation bar and footer"

  7. Verify Your Work:

    $ git status
$ git log --oneline
    • git status should report a clean working tree, and the log should show your merge history. Tell your tutor what you see and confirm that it matches what you predicted during the dialogue.

Part 4: A Second Conflict with Less Scaffolding (approximately 15 minutes)

Real conflicts rarely come with a walkthrough. This time you will create the conflict knowingly and resolve it with a shorter dialogue.

  1. Create a Branch for the Hero Section:

    • From main, create a new branch:

      $ git checkout main
$ git checkout -b feature/hero-section

  2. Replace the Heading with a Hero Section:

    • On this branch, replace the entire <h1> line in index.html with this hero section:

      <section class="hero">
  <h1>Welcome to Our Website</h1>
  <p>We build modern web experiences for our clients.</p>
</section>

    • Commit the change:

      $ git add index.html
$ git commit -m "Added hero section"

  3. Make an Urgent Change Directly on main:

    • While you were working, your project manager pushed an urgent copy change to the homepage. Simulate it: switch to main and change the <h1> line to read:

      <h1>Welcome to Our Website - Launching Soon</h1>

    • Commit the change on main:

      $ git add index.html
$ git commit -m "Updated homepage heading for launch"

  4. Merge and Face the Conflict:

    $ git merge feature/hero-section

    Because both branches modified the same line, Git reports another conflict.

  5. Hold a Second, Shorter Socratic Dialogue:

    • In the same conversation, paste the new terminal output and the conflicted file. This time, aim to need fewer questions: state up front what you think each side of the conflict is and what the resolution should be, and let your tutor probe your reasoning.
    • The outcome the project needs: the hero section stays, and the heading inside it carries the new “Launching Soon” text. You decide how the final markup reads.

  6. Resolve, Stage, and Commit:

    • Edit index.html by hand, remove the markers, then stage and commit the resolution with a clear message.

  7. Optional Stretch Features (ungraded):

    • If you finish early, continue the practice on your own, merging each branch into main and resolving any conflicts that arise:
      • feature/contact-form: add a simple contact form with fields for name, email, and message.
      • feature/testimonials: add a section of customer testimonials with a few placeholder quotes.

Part 5: Wrap Up and Publish (approximately 10 minutes)

  1. Push Your Work to GitHub:

    $ git push -u origin main

    The -u origin main flags tell Git to push to the main branch on the origin remote you configured in Part 1. Once set up, future pushes can be done with just git push.

  2. Capture Your Dialogue:

    • In your Claude conversation, use the Share button to create a public link to the conversation and copy it.
    • If sharing is disabled in your workspace (or you used Claude Code), copy the full transcript of the dialogue instead.

  3. Create SOCRATIC_DIALOGUE.md:

    • In the root of your repository, create a file named SOCRATIC_DIALOGUE.md containing:
      • The shared conversation link, or the pasted transcript if sharing was unavailable.
      • A 150 to 200 word reflection on how being questioned, rather than told, changed your understanding of conflict markers and merge mechanics. Include one thing you can now explain that you could not before the dialogue, and mention any moment where the tutor broke its rules and how you handled it.

  4. Commit and Push the File:

    $ git add SOCRATIC_DIALOGUE.md
$ git commit -m "Add Socratic dialogue link and reflection"
$ git push

Submission Guidelines

Submit the link to your GitHub repository on Canvas.

This lab is graded complete/incomplete. To be marked complete, your repository must show all three of the following:

  1. A commit history on main that includes both feature merges, with at least two resolved merge conflicts visible in the history (the footer conflict from Part 3 and the hero section conflict from Part 4).
  2. A SOCRATIC_DIALOGUE.md file containing your shared conversation link (or pasted transcript) plus your 150 to 200 word reflection.
  3. A transcript showing that you resolved the conflicts yourself: the AI asks guiding questions throughout, and it never issues terminal commands or writes the resolved file for you.
Lesson 4: Branching and Merging in GitLesson 5: Collaborating and Pull Requests