Using Git and GitHub

Introduction

Setup

Step 1: pick a project name

In all of the steps below replace PROJECTNAME with your actual project name (please don’t actually use all caps).


Step 2: create a GitHub account


Step 3: create a new repository on GitHub

This step should be done by ONE PERSON per group.

Then:

  1. Click on the green New button
  2. For “Repository name” use your PROJECTNAME
  3. Enter a short, useful description; include information about the data that will be featured. You can update this later.
  4. Choose “Public”
  5. CHECK “Initialize this repository with a README”
  6. Drop down “Add .gitignore” and choose “R” (duh)
  7. Go to Settings, then select Collaborators and add your other group members to the github project.


Step 4: setup a new RStudio project

This step should be done by EVERYONE in your group.

  1. On your group’s repository page on GitHub, click the green “Clone or Download” button
  2. In RStudio from the menu bar select “File” -> “New Project…”
  3. Choose “Version Control”, then “Git”, then paste in the URL you copied from GitHub.
  4. Hit “Create”

You should see the same set of files listed on your “Files” tab that you had in your GitHub repository.


Step 5: setup Git identity

This step should be done by EVERYONE in your group.

In RStudio from the menu bar select “Tools” -> “Shell…”

In the shell enter these two commands (with your actual email and name; duh.)


Step 6: setup .gitignore

From the files pane, open up your “.gitignore” file and add the following line:

*.Rproj*

The will prevent you or your groupmates from including RStudio configuration files in the code that you push to GitHub.

Step 7: test out the configuration

This step should be done by EVERYONE in your group.

Let’s test to make sure everything is working so far.

  1. Open up “README.md”
  2. Make a change; any change. Save it.
  3. Next to your “History”" tab, you should have a “Git” tab.
  4. There should be a blue “M” (for modified) next to “README.md”
  5. Click the check box to stage this change, then Commit
  6. In the “Commit message” box enter something like “testing git setup”
  7. Hit “Commit”. You should see a message about one file changing.

Hopefully that all worked and nothing caught fire.

(Optional) Step 8: Setup SSH key-pairs

  1. Generate a key pair
  2. Add the key to your github account

All of the “Bash” commands shown in these tutorials can be entered using the Shell in RStudio (Tools menu).

Anatomy of a Shiny App

Git & GitHub Workflow

Make some changes, stage files

Let’s make some example changes to your app files. Assign each person in your group to do one of the following:

  1. Add a new actionButton after the sliderInput in ui.R
  2. Change the max number of bins to 100 for the sliderInput in ui.R
  3. (if there are three of you) Add a new comment line starting with # somewhere in ui.R

When you hit “Commit” and then select “ui.R” you’ll each see the change you made highlighted.

Push your changes to GitHub

Pick one person in your group to go first. Hit the “Push” button in the Commit window or on the “Git” pane.

Pick the second person in your group to go; Hit “Push”.

You’ll see a message like:

To https://github.com/WL-Biol185-ShinyProjects/sample-project.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/WL-Biol185-ShinyProjects/sample-project.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Following the message’s advice, you should click “Pull” to download person #1’s files.

Depending on how you each edited your files one of two things might happen:

  1. Automerge succeeds without any help from you; this works when Git’s merging algorithm can be pretty sure it knows how to merge the files without loosing anything.

  2. You see a message like this:

From https://github.com/WL-Biol185-ShinyProjects/sample-project
   bcba6e0..d1b8b44  master     -> origin/master
Auto-merging ui.R
CONFLICT (content): Merge conflict in ui.R
Automatic merge failed; fix conflicts and then commit the result.

Do you believe me now that it will be important for everyone in your group to write well formatted, easy to read, code?

Real work-flow

  1. Pull
  2. Change stuff
  3. Stage changed files
  4. Commit changes
  5. Repeat steps 3-5 for every “task”; write meaningful messages. You’ll thank yourself for be diciplined about this!
  6. Once a set of tasks is “complete” Push commits back to GitHub.

Publishing to the Shiny Server

When you’re ready to publish a live version of your app in a publically available location, you can run:

That will fetch the current version of your code from GitHub and update the app linked from our course project’s page:

https://rstudioconnect.wlu.edu/bio185/projects-page.html

Avoiding Conflicts (with code & people)

Clear file structure design (ahead of time)

No need to write any implementation code; just start by sketching out your goals.

Consider this refactoring of our ui.R script:

Here we’ll split out the code that makes the major UI elements (sidebar and main panel) into their own script files:

sidebar.R:

main-panel.R:

ui.R:

Clear goals; clear ownership

  1. Design it: you need to know exactly what you’re trying to build before you can start coding
  2. Implement it: write the code you think will work
  3. Fix all of the bugs
  4. (most of the time) Realize your design is flawed/incomplete/impossible and go back to step 1.

Project Requirements

Data

Motivation

Ambition

Final product

It must run by 5pm on Friday of Finals week (as published on the RNA Shiny server).

It’d be nice to include a link to the projects hosting page on RNA in your README.md:

https://rstudioconnect.wlu.edu/bio185/projects-page.html