AE05 - Git together

Learning how to play nice with others

Published

October 1, 2026

Purpose

Today you’ll experience two sides of working with git as a team. First, you’ll deliberately create and resolve a merge conflict, so you know what one looks like and how to fix it.

Second, you’ll use a feature branch for the first time: instead of everyone editing main directly, each of you does your own work in isolation and brings it in with a Pull Request. This is the standard way collaborators combine work on GitHub.

Getting started

  1. Log into GitHub and go to the DATA385-f26 organization.
  2. Find your team’s repo for today.
  3. Clone it to your RStudio but otherwise don’t touch it.

The origin remote

When you clone a repository with git clone, it automatically creates a remote connection called origin pointing back to the cloned repository. This is useful for developers creating a local copy of a central repository, since it provides an easy way to pull upstream changes or publish local commits.

Credit: Wanderson Chaves Linkedin - https://www.linkedin.com/pulse/uso-b%C3%A1sico-do-git-simplificando-o-controle-de-vers%C3%A3o-wanderson-chaves/

All git repositories have a main branch - this is where you have been doing the work so far.

Part 1: Working together on main

  1. Sit with your team and everyone open your shared repo in RStudio.
  2. Make up a team name (<30 seconds)
  3. Assign the numbers 1–4 to each team member (double up if your team has fewer than four people).
Important

Only one person acts at a time. Everyone else watches — don’t pull or render on your own — until it’s your turn.

Role 1:

  • Change the Team name: line to your team’s actual name.
  • Render, commit, push.

Team name: _____________________

1 + 1
[1] 2

🛑 Wait for Role 1 to finish before continuing.

Role 2:

  • Change the same Team name: line to something else.
  • Render, commit, push. You should get an error — GitHub rejects the push because your local copy is behind.
  • Pull. Look at the file and note the new content around the Team name.
CautionMerge conflict

When two people edit the same line you will get a merge conflict. The areas of conflict will show up in your code like this:

<<<<<<< HEAD

=======

>>>>>>> new_branch_to_merge_later

Think of these new lines as “conflict dividers”. The ======= line is the “center” of the conflict. All the content between the center and the <<<<<<< HEAD line is content that exists in the current branch main. All content between the center and >>>>>>> new_branch_to_merge_later is content that is present in our current file.

Ref: Atlasssian documentation on merge conflicts

Role 2 cont:

  • Resolve it by editing the file to keep whichever version you want (or blend both), and delete the <<<<<<<, =======, and >>>>>>> marker lines around it.
  • Render, stage, commit, push.

🛑 Wait for Role 2 to finish before continuing.

Role 3:

  • Change the label of the icebreaker chunk above to something new.
  • Render, commit, push. You should get an error, same as before.
  • Pull new changes. This time there’s no conflict because the changes were on different lines. git merges the two changes automatically.
  • Render, commit, push.

🛑 Wait for Role 3 to finish before continuing.

Role 4:

  • Change the same chunk’s label to something different than Role 3 picked.
  • Render, commit, push. Error again.
  • Pull, resolve the conflict the same way Role 2 did, commit, push.

Everyone: pull, and confirm you all see the identical final file.

Tip

Roles 1 & 2 edited the same line, so git couldn’t guess which version you wanted, creating a conflict. Roles 3 & 4 edited different parts of the file (a chunk label, elsewhere), so git combined both changes on its own, no conflict.

Part 2: Feature branching fixes this

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the main branch.

  • Assume a central remote repository
  • The main branch is the official project history
  • Developers create branches off main to work on features
  • Branches are then merged back onto main using a pull request, bringing that complete (and bug free) work back onto main
  • Multiple branches can be created at the same time so work can occur in parallel.

Atlassian Documentation on Git Branching - Overview

Example workflow

See https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Part 3: Collaborative Work

You are going to answer a few more questions using the unvotes data from AE01. Each of you will answer one question below, on your own branch, then merge it all together in GitHub.

Important

Read the full workflow first, make sure all team members know their assignment then start the work.

Setup

library(tidyverse)
library(lubridate)
library(scales)
library(unvotes)

unv <- unvotes::un_votes %>%
  inner_join(un_roll_calls, by = "rcid") %>%
  inner_join(un_roll_call_issues, by = "rcid")

Workflow

  1. Branch. Everyone creates their own branch off main, named after your question (e.g. q1-one-country).
  2. Answer your question — pick one of the four below, or use the number you were assigned by filling in only that question’s chunk under ## Team questions with your code, and adding 1-2 sentences of interpretation below it.
  3. Render, commit, push your branch.
  4. Open a Pull Request. On GitHub, open your repo. You’ll see a banner at the top for your just-pushed branch.
    • Click Compare & pull request, make sure the base main and the arrow is pointing from your branch going into main.
    • Add a short description then click Create pull request.
  5. Trade. Don’t merge your own PR. Open a teammate’s instead, read their change, leave a comment or approval, then Merge pull request.
  6. Once all PRs are merged, everyone switches back to main locally and pulls, so you all end up with the whole team’s questions in one document.
  7. Render your document locally to see these changes. Do not push again

Team questions

Q1. How does one country vote?

Pick one country (check its spelling in the AE01 Appendix) and make a bar chart of its votes. Does it vote yes more often than no?

Q2. What gets voted on the most?

Make a frequency table of issue. Which issue has the most votes?

Q3. U.S. yes votes by issue

For the United States, calculate the proportion of yes votes on each issue. Which issue does it vote yes on the most? The least?

Q4. Two countries, one issue

Filter to the United States and Canada on “Human rights”, then make a bar chart with one bar per country, filled by vote (position = "fill"). Do the two countries mostly agree?

Note

The merge-conflict activity in Part 1 adapts material from Data Science in a Box (Unit 2, Lab 03: “Nobel laureates”) by Mine Çetinkaya-Rundel, licensed under CC BY-SA 4.0. Source: tidyverse/datascience-box.

Images and other references pull from https://www.atlassian.com/git/tutorials/