SDPT Lab 2

De la WikiLabs
Versiunea din 2 martie 2026 14:04, autor: Rhobincu (discuție | contribuții) (Pagină nouă: = Lab 2: Multi-Player Git, Merge Requests, and Conflict Resolution = == Introduction == In Week 1, you learned how to drive Git in "single-player mode." You initialized a reposito...)
(dif) ← Versiunea anterioară | Versiunea curentă (dif) | Versiunea următoare → (dif)
Jump to navigationJump to search

Lab 2: Multi-Player Git, Merge Requests, and Conflict Resolution

Introduction

In Week 1, you learned how to drive Git in "single-player mode." You initialized a repository, staged files, and pushed to your own remote server.

Today, we switch to "multi-player mode." Software engineering is a team sport. When multiple engineers edit the same codebase simultaneously, collisions are inevitable. By the end of this 2-hour lab, you and a partner will have:

  1. Configured a shared team repository.
  2. Enforced Trunk-Based Development by locking down the main branch.
  3. Worked in parallel on feature branches.
  4. Intentionally caused a Git Merge Conflict.
  5. Resolved the conflict using Git commands and GitLab Merge Requests (MRs).
  6. Conducted a formal Code Review.

Requirement: Find a partner. Decide who will be Student A (The Maintainer) and who will be Student B (The Developer).

---

Part 1: Team Setup and Branch Protection (20 Minutes)

We must first create a shared workspace and establish our "Traffic Laws" (Branch Protection).

1. Create the Shared Repository (Student A)

  • Student A: Log into GitLab and create a new blank project named sdpt-lab2-collaboration.
  • Uncheck "Initialize repository with a README".
  • On the left sidebar, go to Manage -> Members.
  • Click Invite members. Search for Student B by their university email or username.
  • Assign Student B the role of Developer and click Invite.

2. Enforce Branch Protection (Student A)

We are using Trunk-Based Development. The main branch is sacred. No one should be allowed to push broken code directly to it.

  • Student A: In the project sidebar, go to Settings -> Repository.
  • Expand the Protected branches section.
  • Ensure the branch is set to main (or master).
  • Set Allowed to merge to: Developers + Maintainers.
  • Set Allowed to push and merge to: No one.
  • Click Protect.

(Now, the ONLY way code gets into main is through a Merge Request!)

3. Initialize the Baseline (Student A)

Student A will push the initial skeleton code so you both have a starting point. 

# Student A's Terminal:
mkdir sdpt-lab2-collaboration
cd sdpt-lab2-collaboration
git init

Create a file named main.cpp: 

#include <iostream>

void init_hardware() {
    // TODO: Initialize communication protocol
}

int main() {
    std::cout << "System Booting..." << std::endl;
    init_hardware();
    return 0;
}

Commit and push: 

git add main.cpp
git commit -m "Initial baseline code"
git remote add origin git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
git push -u origin main

4. Clone the Repository (Student B)

  • Student B: Go to Student A's GitLab project page. Copy the SSH clone URL.
  • Open your terminal and clone the shared repository to your machine:
git clone git@gitlab.com:<Student-A-Username>/sdpt-lab2-collaboration.git
cd sdpt-lab2-collaboration

---

Part 2: Parallel Realities (30 Minutes)

Both students will now create isolated branches and attempt to implement the hardware initialization logic at the exact same time.

1. Branching Out (Both Students)

Both students must run the following commands on their own machines: 

# Student A runs:
git checkout -b feature-spi-init

# Student B runs:
git checkout -b feature-i2c-init

2. Writing the Code (Both Students)

Open main.cpp in your text editor. Find the init_hardware() function.

Student A (SPI Logic): Replace the TODO comment with this exact code: 

void init_hardware() {
    std::cout << "Initializing SPI Bus on Port A..." << std::endl;
}

Student B (I2C Logic): Replace the TODO comment with this exact code: 

void init_hardware() {
    std::cout << "Initializing I2C Bus on Port B..." << std::endl;
}

3. Commit and Push (Both Students)

Because you are on separate branches, you can both push to the server safely. 

# Student A:
git add main.cpp
git commit -m "Add SPI hardware initialization"
git push -u origin feature-spi-init

# Student B:
git add main.cpp
git commit -m "Add I2C hardware initialization"
git push -u origin feature-i2c-init

4. Open Merge Requests (Both Students)

  • Both students: Go to the GitLab project page.
  • You should see a blue banner saying "You pushed to feature-...". Click Create merge request.
  • Assign your partner as the Reviewer.
  • Click Create merge request.

---

Part 3: The Collision & Code Review (30 Minutes)

Right now, both Merge Requests look green and ready to merge. Git doesn't know there is a problem yet.

1. Review and Merge Student A's Code

  • Student B: Go to the Merge Requests tab and click on Student A's MR (SPI init).
  • Go to the Changes tab to review the code.
  • Leave a comment on the line of code: "Looks good, SPI is the correct protocol."
  • Click Approve, then click the green Merge button.

Student A's code is now officially part of the main branch!


2. The Conflict Appears

  • Student B: Go back to the Merge Requests list and open your own MR (I2C init).
  • You will see a glaring error: Merge blocked: merge conflicts must be resolved.
  • Why did this happen? Both of you edited the exact same line in main.cpp. Git refuses to guess whether the SPI code or the I2C code should win. A human must intervene.

---

Part 4: Resolving the Conflict (30 Minutes)

Student B must pull the new changes from the server and fix the conflict locally before they can merge.

1. Update the Local Main Branch (Student B)

Student B, your local machine does not know about Student A's merged code yet. 

# Switch back to main
git checkout main

# Download the latest changes from the server
git pull origin main

2. Rebase or Merge? (Student B)

Switch back to your feature branch. We need to integrate the new main into your feature branch. We will use a merge to resolve the conflict. 

git checkout feature-i2c-init
git merge main

Git will output: CONFLICT (content): Merge conflict in main.cpp. Automatic merge failed.

3. Fix the Code (Student B)

Open main.cpp in your text editor. Git has injected markers into your code: 

void init_hardware() {
<<<<<<< HEAD
    std::cout << "Initializing I2C Bus on Port B..." << std::endl;
=======
    std::cout << "Initializing SPI Bus on Port A..." << std::endl;
>>>>>>> main
}


  • Task: Discuss with Student A. Decide that you actually need both protocols to initialize.
  • Delete the Git markers (<<<<<<<, =======, >>>>>>>) and combine the logic so it looks like this:
void init_hardware() {
    std::cout << "Initializing SPI Bus on Port A..." << std::endl;
    std::cout << "Initializing I2C Bus on Port B..." << std::endl;
}

4. Finalize the Merge (Student B)

Now that the conflict is manually fixed, tell Git it is resolved: 

git add main.cpp
git commit -m "Resolve merge conflict between SPI and I2C initialization"
git push origin feature-i2c-init

5. Final Approval (Student A)

  • Student A: Go to Student B's Merge Request on GitLab.
  • Notice the conflict warning is gone. The MR is green again!
  • Review the Changes to ensure both SPI and I2C are initialized.
  • Click Approve, then click Merge.

---

Lab Deliverable

To receive full credit for this week's lab, both partners must call the professor or teaching assistant over to your workstation and demonstrate:

  1. The shared GitLab repository showing the main branch with both SPI and I2C logic combined.
  2. The Settings -> Repository -> Protected branches screen showing that main cannot be pushed to directly.
  3. The Merge Requests tab showing two Closed/Merged MRs with review comments visible.
  4. Run git log --graph --oneline on your terminal to show the visual graph of the diverging branches and the merge commit.
Adus de la „http://wiki.dcae.pub.ro/index.php?title=SDPT_Lab_2&oldid=8281”