🖥️ Week 10 Lecture

Using Git as a Team

📍 Logistics

Time and Location: Thursday, 04 December 2025, 16:00 - 18:00, CLM 5.02

Today’s lecture is interactive, more like a lab than a traditional lecture. We’ll form project groups and learn how Git workflows change when working collaboratively on GitHub. This session prepares you for your group project work and next week’s pitch presentation.

Note: Groups must be made up of 3-4 people, ideally from the same Friday lab session. Your first group commitment is to present a very short pitch at the W11 Labs, in the same time slot as the majority of those in each group.

🗣️ Lecture Overview

Part 1: Choosing Your Data Source

I will use this time to tell you about the expectations for your group project and the 🔎 Choosing Your Data Source guide.

Part 2: Form Your Groups

I will guide you through forming groups and setting up your team repository:

• Form groups of 3-4 people (ideally from the same Friday lab session)
• Choose a creative team name (will be part of your GitHub repository URL)
• Click on the button below to create your team repository. The first person to click the button will create the team name, the others will join using the same team name.

• Everyone then needs to clone the repository locally:

  git clone <repository-url>

Part 3: Syncing Changes and Managing Conflicts

When multiple team members work on the same repository, you need to sync your local copy with changes others have made.

I will demonstrate two new Git commands that will help you sync changes made by other team members:

git fetch: Downloads changes from GitHub without merging them into your working directory

git fetch

git pull: Downloads changes and automatically merges them into your current branch (combines git fetch and git merge)

git pull

Experiencing a merge conflict:

• Two team members make changes to the same file (README.md) on the main branch at the same time

• Both commit and push their changes

• The second person to push gets a message saying that there is a divergence between their local and remote repositories and that they need to git pull to resolve it.

  Note that for the first time this happens, git will pause and ask you how you typically want these things to be resolved. I recommend you set it to the merge strategy:

  git config --global rebase false

  This guarantees that every time git is trying to synchronise changes, it will try to merge (incorporate) the changes from the other branch into your current branch.

  Then, once the second person tries to git pull again, git will try to solve it for you. If it can, the second person will be able to git push normally.

• If git cannot sync the changes between the local and remote repositories automatically - typically due to the fact that changes were made in the same lines in the same file by both people, then git will mark the file as conflicted and you will need to resolve it manually.

  If both people have made changes to the same lines in the same file, this is called a git conflict. These are represented like this:

  <<<<<<< HEAD
  This is the code from the branch you're merging into (usually your current branch)
  =======
  This is the code from the branch you're merging from
  >>>>>>> branch-name

  I will show you how to delete the conflict markers and keep the version you want to maintain (or a combination of the two). Then, you should git add, git commit and git push to resolve the conflict.

• Alternatively, I will demonstrate VS Code’s merge conflict editor to resolve the conflict in a more visual and user-friendly way. You will still need to git commit and git push to resolve the conflict later

Part 4: Setting Up GitHub Pages

In your final project of this course (the 📦 Group Project) you will be required to create a website where you will communicate results to the world. This is meant to be very similar to the REPORT.md you created in your previous project.

I will demonstrate:

1. Navigate to your repository’s Settings > Pages
2. Configure the source to deploy from the main branch
3. Set the folder to /docs
4. Create a docs/index.md file (this will be your pitch page)
5. GitHub will automatically publish your page at https://<team-name>.github.io/<repo-name>/

🗣️ Next Week: Project Pitch

You’ll present your project idea to the class in Week 11 Labs (worth 10% of final grade). Keep it short (3-5 minutes) but make it count.

What to present:

• What data you’re planning to use (check the 🔎 Choosing Your Data Source guide)
• What kind of questions you’re hoping to answer
• How you’ll divide the work among your team

The key to success is showing that you can work well together as a team.

Presentation format:

• Your presentation must be a GitHub Page (present your pitch as a GitHub Page)
• Do not add a lot of text: the page should be a visual aid to your presentation, not a script
• Your ideas can (and probably will) evolve completely by the project deadline

Note: Your ideas can evolve significantly between the pitch and the final project deadline. The pitch demonstrates team coordination and initial planning, not a final commitment.

🔖 Appendix

Post‑Lecture Actions

• Complete your team repository setup if you haven’t already
• Practice syncing changes with your team:

git fetch
git pull

• Set up your GitHub Pages site (Settings > Pages > /docs folder)
• Create your docs/index.md file for next week’s pitch presentation
• Start discussing project ideas and data sources

Useful Links

• 💻 W10 Lab (tomorrow)
• 🗣️ W11 Lab (project pitch presentations)
• 🔎 Choosing Your Data Source
• ✍️ Group Project (released this week)
• 📔 Syllabus

Looking Ahead

• Tomorrow (W10 Friday): Continue Git collaboration practice in lab
• Next week (W11): Group project pitch presentations (10% of grade)
• Group Project: Due Winter Term Week 03 (50% of grade)
• Key skill: These Git collaboration skills are essential for your group project work