25: GitHub collaboration and shiny design

Author

Affiliation

Prof Amanda Luby

Carleton College
Stat 220 - Winter 2026

library(tidyverse)

Github merge conflicts

When you and your teammates work on the lines of code within a document and both try to push your changes, you will run into issues.

Merge conflicts happen when you merge branches that have competing changes, and Git needs your help to decide which changes to incorporate in the final merge.

Our first task today is to walk you through a merge conflict!

First, a bit of Git review:

Pushing to a repo replaces the code on GitHub with the code you have on your computer.
If a collaborator has made a change to your repo and pushed it to your collaborative GitHub repository, GitHub will stop you from pushing your changes to the repo because this could overwrite your collaborator’s work!
So you need to explicitly “merge” your collaborator’s work before you can push.
If your and your collaborator’s changes are in different files or in different parts of the same file, git merges the work for you automatically when you pull.
If you both changed the same part of a file, git will produce a merge conflict because it doesn’t know how which change you want to keep and which change you want to overwrite.

Git will put conflict markers in your code that look like:

<<<<<<< HEAD 

See also: [dplyr documentation](https://dplyr.tidyverse.org/)   

======= 

See also [ggplot2 documentation](https://ggplot2.tidyverse.org/)  

>>>>>>> some1alpha2numeric3string4

The ===s separate your changes (top) from their changes (bottom).

Note that on top you see the word HEAD, which indicates that these are your changes.

And at the bottom you see some1alpha2numeric3string4 (well, it probably looks more like 28e7b2ceb39972085a0860892062810fb812a08f).

This is the hash (a unique identifier) of the commit your collaborator made with the conflicting change.

Your job is to reconcile the changes: edit the file so that it incorporates the best of both versions and delete the <<<, ===, and >>> lines. Then you can stage and render the result.

Setup

Clone the day25-yourgroup repo and open app.R
Assign the numbers 1, 2, and 3 to each team member. If your team has fewer than 3 people, some will need to have multiple numbers
If your partner(s) aren’t here and you are currently a group of 1, join up with a group of 2 (Amanda will add you to their repo)

Hint

If the conflict markers are not appearing in your files (=====, >>>>>, etc.) try clicking “Terminal” in Rstudio and running the command:

git merge --no-ff

Let’s cause a merge conflict!

Our goal is to see two different types of merges: first we’ll see a type of merge that git can’t figure out on its own how to do on its own (a merge conflict) and requires human intervention, then another type of where that git can figure out how to do without human intervention.

Doing this will require some tight choreography, so pay attention!

Take turns in completing the exercise, only one member at a time. Others should just watch, not doing anything on their own projects (this includes not even pulling changes!) until they are instructed to. If you feel like you won’t be able to resist the urge to touch your computer when it’s not your turn, we recommend putting your hands in your pockets or sitting on them!

Before starting

Everyone should have the repo cloned and know which role number(s) they are.

Role 1

Go to app.R in your project repo. Change the [team name] to your actual team name.
Run the app, commit (all changed files), and push.

Important

Make sure the previous role has finished before moving on to the next step.

Role 2

Change the team name to some other word.
Run the app, and commit all changed files
Now, try to push your changes. You should get an error.

Pull. Take a look at the document (app.R) with the merge conflict
Resolve the conflict by editing app.R to choose the correct/preferred change. Remove the merge conflict decorators (<<<<<< HEAD, ======, and >>>>>>> 97e290f39f197467b5563ea8f81187b760c95aa2, the commit hash)
Then, run the app
Click the stage checkbox for all files in your git tab. Make sure they have checkmarks, not filled in boxes
Commit and push

Important

Make sure the previous role has finished before moving on to the next step.

Role 3

Change the name of the title in the app
Run the app, commit and push. You should get an error.
Pull. No merge conflicts should occur, but you should see a message about merging
Now push.

Important

Make sure the previous role has finished before moving on to the next step.

Role 1 (if you have 3 people) / Role 2 (if you have 2 people)

Pull all changes from the remote repo
Change something in the app
Run the app, commit, and push. You should not get an error because you pulled first. This is “good” collaborative behavior: start with pulling before doing any work

Important

Make sure the previous role has finished before moving on to the next step.

Tips for collaborating via GitHub

Always pull before you start working
Resolve a merge conflict (render and push) before continuing your work. Never do new work while resolving a merge conflict
Render, commit, and push often to minimize merge conflicts and/or make merge conflicts easier to resolve
If you find yourself in a situation that is difficult to resole, ask questions ASAP. Don’t let it linger and get bigger.

Warm Up

Open the following shinyapps and explore a little bit.

With the folks around you, discuss:

Did any apps stand out as enjoyable or useful?
What features or design choices make an app stand out?
Are there any small tweaks you could make to make them more usable?

AskAManager App

Use the version you’ve been working on, or use a new starter app at https://stat220-w26.github.io/files/25-starter-app.R (it is also in the solutions repo)

Part 1

Move the initial data preparation code to an R script called data-prep.R
Write the cleaned dataset to a CSV or .Rds file
- write_rds(manager_survey, "/data/manager-survey.rds")
In the app.R file, load the data with read_csv
- manager_survey <- read_rds("data/manager-survey.rds")

Part 2

Reorganize the app layout so that the two graphs show up on different panels, tabsets, or pages within a navlist
Commit and push the changes so everybody has the new version

Part 3

Add a custom theme to the AskAManager app
Update the ggplot themes to match

(If Time)

Set up shinyapps.io account and deploy either (a) Portfolio 4 or (b) the AskAManager app

You can deploy shiny apps online
- using Posit’s cloud server (free/fee) - https://www.shinyapps.io/
  - “Getting started” guide will walk you through connecting RStudio to your shinyapps.io account
  - note: there is also now an option to deploy via Connect Cloud from your github. Feel free to try it!
- creating a shiny server
Your app and files should be in their own folder and the entire folder is what you “deploy”. You do not want multiple app.R or .Rmd files in that folder!

Credit: Mine Çetinkaya-Rundel’s Ask a Manager application exercise and GitHub collaboration exercise

--- title: "25: GitHub collaboration and shiny design" --- ```{r} library(tidyverse) ``` # Github merge conflicts When you and your teammates work on the lines of code within a document and both try to push your changes, you will run into issues. Merge conflicts happen when you merge branches that have competing changes, and Git needs your help to decide which changes to incorporate in the final merge. Our first task today is to walk you through a merge conflict! First, a bit of Git review: - Pushing to a repo replaces the code on GitHub with the code you have on your computer. - If a collaborator has made a change to your repo and pushed it to your collaborative GitHub repository, GitHub will stop you from pushing your changes to the repo because this could overwrite your collaborator's work! - So you need to explicitly "merge" your collaborator's work before you can **push**. - If your and your collaborator's changes are in different files or in different parts of the same file, git merges the work for you automatically when you **pull**. - If you both changed the same part of a file, git will produce a **merge conflict** because it doesn't know how which change you want to keep and which change you want to overwrite. Git will put conflict markers in your code that look like: ``` <<<<<<< HEAD See also: [dplyr documentation](https://dplyr.tidyverse.org/) ======= See also [ggplot2 documentation](https://ggplot2.tidyverse.org/) >>>>>>> some1alpha2numeric3string4 ``` The `===`s separate *your* changes (top) from *their* changes (bottom). Note that on top you see the word `HEAD`, which indicates that these are your changes. And at the bottom you see `some1alpha2numeric3string4` (well, it probably looks more like `28e7b2ceb39972085a0860892062810fb812a08f`). This is the **hash** (a unique identifier) of the commit your collaborator made with the conflicting change. Your job is to *reconcile* the changes: edit the file so that it incorporates the best of both versions and delete the `<<<`, `===`, and `>>>` lines. Then you can stage and render the result. ## Setup - Clone the `day25-yourgroup` repo and open `app.R` - Assign the numbers 1, 2, and 3 to each team member. If your team has fewer than 3 people, some will need to have multiple numbers - If your partner(s) aren't here and you are currently a group of 1, join up with a group of 2 (Amanda will add you to their repo) ::: callout-tip ## Hint If the conflict markers are not appearing in your files (`=====`, `>>>>>`, etc.) try clicking "Terminal" in Rstudio and running the command: ``` git merge --no-ff ``` ::: ## Let's cause a merge conflict! Our goal is to see two different types of merges: first we'll see a type of merge that git can't figure out on its own how to do on its own (a **merge conflict**) and requires human intervention, then another type of where that git can figure out how to do without human intervention. Doing this will require some tight choreography, so pay attention! Take turns in completing the exercise, only one member at a time. **Others should just watch, not doing anything on their own projects (this includes not even pulling changes!)** until they are instructed to. If you feel like you won't be able to resist the urge to touch your computer when it's not your turn, we recommend putting your hands in your pockets or sitting on them! ### Before starting Everyone should have the repo cloned and know which role number(s) they are. ### Role 1 - Go to `app.R` in your project repo. Change the `[team name]` to your actual team name. - Run the app, commit (all changed files), and push. ::: callout-important Make sure the previous role has finished before moving on to the next step. ::: ### Role 2 - Change the team name to some other word. - Run the app, and commit all changed files - Now, try to push your changes. You should get an error. ![](https://sta199-f25.github.io/project/images/role-2-push-error.png) - Pull. Take a look at the document (`app.R`) with the merge conflict - Resolve the conflict by editing `app.R` to choose the correct/preferred change. Remove the merge conflict decorators (`<<<<<< HEAD`, `======`, and `>>>>>>> 97e290f39f197467b5563ea8f81187b760c95aa2`, the commit hash) - Then, run the app - Click the stage checkbox for all files in your git tab. Make sure they have check**marks**, not filled in boxes - Commit and push ::: callout-important Make sure the previous role has finished before moving on to the next step. ::: ### Role 3 - Change the name of the title in the app - Run the app, commit and push. You should get an error. - Pull. No merge conflicts should occur, but you should see a message about merging - Now push. ::: callout-important Make sure the previous role has finished before moving on to the next step. ::: ### Role 1 (if you have 3 people) / Role 2 (if you have 2 people) - Pull all changes from the remote repo - Change something in the app - Run the app, commit, and push. You should not get an error because you pulled first. This is "good" collaborative behavior: start with pulling before doing any work ::: callout-important Make sure the previous role has finished before moving on to the next step. ::: # Tips for collaborating via GitHub - **Always pull before you start working** - Resolve a merge conflict (render and push) *before* continuing your work. Never do new work while resolving a merge conflict - Render, commit, and push often to minimize merge conflicts and/or make merge conflicts easier to resolve - If you find yourself in a situation that is difficult to resole, ask questions ASAP. Don't let it linger and get bigger. # Warm Up Open the following shinyapps and explore a little bit. + [Data Wrangling](https://psu-eberly.shinyapps.io/data_wrangling/) + [Biodiversity in NPS](https://abenedetti.shinyapps.io/bioNPS/) + [Hex Memory Game](https://dreamrs.shinyapps.io/memory-hex/) + [Lake Profile Dashboard](https://gallery.shinyapps.io/lake-profile-dashboard/) + [Classification Trees](https://asluby.shinyapps.io/GSS_classification/) With the folks around you, discuss: 1. Did any apps stand out as enjoyable or useful? 2. What features or design choices make an app stand out? 3. Are there any small tweaks you could make to make them more usable? # AskAManager App Use the version you've been working on, or use a new starter app at [https://stat220-w26.github.io/files/25-starter-app.R](https://stat220-w26.github.io/files/25-starter-app.R) (it is also in the solutions repo) ## Part 1 - Move the initial data preparation code to an R **script** called `data-prep.R` - Write the cleaned dataset to a CSV or .Rds file + `write_rds(manager_survey, "/data/manager-survey.rds")` - In the `app.R` file, load the data with `read_csv` + `manager_survey <- read_rds("data/manager-survey.rds")` ## Part 2 - Reorganize the app layout so that the two graphs show up on different panels, tabsets, or pages within a navlist - Commit and push the changes so everybody has the new version ## Part 3 - Add a custom theme to the AskAManager app - Update the ggplot themes to match ## (If Time) Set up shinyapps.io account and deploy either (a) Portfolio 4 or (b) the AskAManager app - You can deploy shiny apps online + using Posit's cloud server (free/fee) - https://www.shinyapps.io/ - ["Getting started"](https://docs.posit.co/shinyapps.io/guide/getting_started/) guide will walk you through connecting RStudio to your shinyapps.io account - note: there is also now an option to deploy via Connect Cloud from your github. Feel free to try it! + creating a shiny server - Your app and files should be in their own **folder** and the entire folder is what you "deploy". You do *not* want multiple `app.R` or `.Rmd` files in that folder! ::: aside Credit: [Mine Çetinkaya-Rundel's](https://vizdata.org/) Ask a Manager application exercise and GitHub collaboration exercise :::