💻 Week 10 Lab

Group Project Planning & Git Collaboration

📍 Logistics

Time and Location: Friday, 05 December 2025. Time varies by lab session.

Today’s lab builds on yesterday’s lecture. We’ll introduce branches and pull requests as the professional way to document project changes, then help you understand the pitch requirements and set up your GitHub Page.

Part 1: Group Formation & Repository Setup (30 min)

The first 30 minutes of this lab are dedicated to creating groups, setting up team repositories, and making sure everyone has their repository cloned locally on Nuvolos.

✅ Option 1: Attended Lecture & Have Team/Repo Ready

If you attended yesterday’s 🖥️ W10 Lecture AND you already have:

• A team of 3-4 people
• A GitHub team repository set up
• Everyone has cloned the repository locally

Use this time to:

• Discuss APIs you want to explore for your project
• Review the 🔎 Choosing Data Sources guide
• Share your ideas with your team members

At the end of this 30 minutes: Tell your class teacher about the APIs you’re considering exploring.

⚠️ Option 2: Need to Form a Group

If you don’t have a group yet, your class teacher will help you:

1. Form a new group: (3-4 people, ideally from the same lab session), OR
2. Join an existing group: Your class teacher may suggest (not force) you to join existing groups if they want new members, OR
3. Cross-class pairing: If someone is left without a group, your class teacher might try to pair you with people from other lab sessions, OR
4. Reach out to Jon: At the end of the day, if you still don’t have a group, Jon will assign groups to those who did not form groups in any way

Once you have a group, follow the steps below to set up your team repository.

📋 Setting Up Your Team Repository

If you need to set up your team repository, follow these steps:

Form Your Group

1. Choose a creative team name

   • The name will be part of your GitHub repository URL
   • Be creative! Don’t use generic names like “Group 1” or “Team A”

2. Access the GitHub assignment link

   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.

3. The first person to click the link will create a team name:

   

   Figure 1. Add a creative team name if you are the first in your group then click + Create team

   The other team members should use the same team name when they join.

4. A few clicks later, you’ll see the repository URL:

   

   Figure 2. You will see the dedicated repository for your team.

   And that’s it!

   

   Figure 3. Your repository will be completely empty, apart from a (mostly empty) README file.

5. Everyone should now clone the repository locally on Nuvolos:

   git clone <repository-url>

   OR, if you don’t like the huge name of the repository, you can rename it to something more concise when cloning:

   git clone <repository-url> <new-name>

   Replace <repository-url> with the SSH URL you copied from GitHub. Replace <new-name> with a name of your choice.

   💡 Important: Make sure everyone in your team has successfully cloned the repository and can navigate to it in their terminal before moving on.

Part 2: Branches and Pull Requests (30 min)

🗣️ TEACHING MOMENT

Work through the following steps to learn how teams can work safely on code using Git branches and pull requests. This is the most professional way to document project changes to each other, sometimes called Git Flow. Your class teacher will help you work through this - see if you can follow the instructions.

⚠️ Ideally you should avoid conflicts, but every now and then they will happen.

Yesterday, you learned how to handle a git conflict when multiple team members are working on the same branch (by default, everyone is on the main branch).

Now, another way to minimise conflicts is if each team member works on a separate branch. The conflict will only happen when you try to join the branches together into the main branch.

This is what we’ll practice in this part of the lab.

Ultimately, it is ok if you don’t use branches and pull requests extensively in your final project. Working directly on main is OK if you’re willing to risk the conflicts and have good communication with your team.

Working with Branches and Pull Requests

Follow these steps with your team:

1. One team member creates a branch

   git checkout -b add-initial-readme

   💡 Important Note: In this course, branches should serve a single purpose. This is reflected in the name, add-initial-readme, which is the only ‘feature’ we’re adding to the repository on this branch.
   
   Branches you might want to create in the future include:
   - explore-google-maps, or
   - explore-zoopla-api, or
   - explore-spotify-api, or
   - eda-<username>

2. Modify a file on that branch

   Inside that branch, make a big change to your README.md file, adding TODOs and placeholder items to the file with things that you want to work on in the near future.

   # Team: <team-name>
   
   **Objective:** Our goal is to explore [this and that API]. We are curious to [explore it freely and see what we can find of interest/try to investigate if.../etc.].
   
   #TODO: add initial project ideas and/or backup plans
   
   **Team members:**
   - [Person A](https://github.com/<team-member-1>)
   - [Person B](https://github.com/<team-member-2>)
   - [Person C](https://github.com/<team-member-3>)
   - ...
   
   ...

   Then, commit and push to that branch:

   git add README.md
   git commit -m "Add initial README with team info and project objectives"
   git push -u origin add-initial-readme

   (Notice that the main branch is left untouched.)

3. 💡 View branch history

   git log --oneline --graph --all

   This shows a visual representation of how branches diverge and merge. You can also view this on GitHub by going to your repository’s Insights > Network tab.

💡 Visualizing Git Branches

💡 Seeing Git in Action

Track your team’s work using:

1. GitHub’s ‘Insights’ > ‘Network’ tab for branch history
2. VS Code’s Source Control panel (shown in the lecture)

Figure 4. VS Code’s Source Control panel makes it easy to manage your branches.

⚠️ Note: This is just the beginning! Teams often develop more sophisticated workflows, like Gitflow, as projects grow.

4. Create a pull request on GitHub for team review

   • Go to your repository on GitHub
   • Click “Pull requests” > “New pull request”
   • Select your branch (add-initial-readme) and create the PR
   • Add a description of what you changed

   💡 Pro-tip: Pull requests let your team review and discuss changes before they become final.

5. Other team members act as reviewers

   • Review the changes in the pull request
   • Add comments if you have questions or suggestions
   • Approve the pull request when you’re happy with the changes

6. Merge the changes after team approval

   • Once approved, merge the pull request
   • The changes will be incorporated into the main branch

💡 Remember: This workflow helps document your project changes and allows team members to review work before it’s merged. It’s the professional approach, but working directly on main is also acceptable if you coordinate well.

Part 3: Understanding Pitch Requirements & Setting Up GitHub Pages

Now that you understand Git collaboration, let’s focus on what you need for next week’s pitch presentation.

Step 1: Understanding the Pitch Requirements

Read through the 🗣️ Pitch Assessment page carefully. Make sure everyone understands:

• What you need to present (3-5 minutes)
• The marking criteria (100 marks total)
• What makes a good pitch

Key points to discuss:

• Exploratory question(s) you want to explore
• Justification of data source choice
• Technical feasibility and implementation plan
• Work distribution among team members
• Backup plans or risk mitigation strategies

Step 2: Setting Up Your GitHub Page

Your pitch presentation must be a GitHub Page. Set this up now:

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. Keep it visual: Remember, the page is a visual aid, not a script. Use:

   • Headers and bullet points (not long paragraphs)
   • Images exported from Google Slides, Powerpoint, Canva, etc.
   • Simple diagrams if helpful
   • Clear sections that match your presentation flow

   Remember: you will only have a maximum of 5 minutes to present your pitch, so make it count!

6. Commit and push your changes:

   git add docs/index.md
   git commit -m "Add pitch presentation page"
   git push

7. Wait for GitHub to publish your page (usually takes a minute or two). Your page will be available at https://<team-name>.github.io/<repo-name>/

💡 Tip: You can preview your page locally before pushing to GitHub. If using Markdown, GitHub will render it automatically. If using Quarto, render it locally first to check formatting.

Step 3: Discuss Your Project Idea

• Data Source: What data will you use? Why is it appropriate? What technical challenges might come up? What is your backup plan?
• Research Questions: What questions do you want to answer? Are they specific and matched to your data source?
• Team Coordination: How will you divide up the work? Who does data collection, cleaning and transformation, visualisations, and documentation?

Step 4: Practice Your Presentation (if time allows)

Even though you won’t present until next week, start thinking about:

• Who will speak for each section?
• How will you transition between speakers?
• What visual aids will you show on your GitHub Page?
• How will you keep it to 3-5 minutes?

Practice run: Do a quick 5-minute practice where each person speaks about their assigned section. This helps identify timing issues early.

🔗 Useful Resources

📚 Essential Guides

• 🔎 Choosing Data Sources: API options and requirements
• 4️⃣ GitHub Guide: Git commands and workflows
• 🖥️ W10 Lecture: Git collaboration tutorial

📝 Assessment Materials

• 📝 Pitch Presentation: Requirements and marking criteria
• ✍️ Group Project: Final project overview (if released)

🆘 Getting Help

• Slack: Post questions to #help channel
• Office Hours: Book via StudentHub
• Class Teacher: Ask during lab if you’re stuck

💡 Key Takeaway: This lab is your chance to coordinate as a team and plan effectively. Use this time wisely - next week’s pitch presentation is worth 10% of your final grade!