• git and http://github.com make version control and collaboration easier
• Package development requires iteration and maybe input from multiple sources
• Ad hoc approaches suffer and can have disastrous consequences
• Here are some examples

• In an attempt to speed up computation time, I tried reimplementing a MLE function.
• Turns out it broke the method entirely and didn’t end up speeding things up.
• How to go back to what it was originally?

• A package gets popular on github, and I occasionally get feature requests or contributions
• How to keep track of the requests?
• How to keep track of contributions from other people?

Once a paper gets published, occasionally people want to use or extend the method.

Email is an ineffective tool for sharing code, data, documents

git

• “The stupid content tracker”, developed to manage Linux source code
  • Files organized into repositories
  • Users commit changes, additions, deletions
  • Entire history of commits saved
  • Only successive diffs are saved, not full copies

Github

• A web interface and host for repositories
  • Explore repositories
  • View code, documents, etc.
  • Interact with collaborators

• Add structure to the iterative process of package development
  • are you sensing a trend?
• Creates a record of all the steps you took
• Gives structure to collaboration, with benefits for asynchronous work
• Github adds the benefit of creating a web-presence
  • Not everyone agrees that this is a benefit

Open up Rstudio

git is not dropbox!

Each commit should be minimally complete

Minimal

• Relates to a single problem
• Makes it easier to describe and understand
• Reduces risk of conflicts (if collaborating)

Complete

• Solves the problem in the code
• Is documented
• Has tests

Oops I forgot to document

• use “Amend previous commit” before pushing to github

I broke someting

• do a “hard reset” back to the previous commit (Discard all in Rstudio)

A collaborator is working on something else at the same time

• use branches and merge later

• The diff shows you exactly what changed
• The commit message should communicate the context

Basic guidelines

1. Write a concise subject heading (about 50 characters)
   • Complete the following sentence: “If applied, this commit will …”
2. If more explanation needed, write a body to explain why and how
3. Reference any relevant issue tracking ids, or links

• Use the imperative tense (like you’re telling someone what to do)
• Be concise, but detailed enough to trigger your memory

• I’m working on a paper with my friend Sue
• Statistical analysis + simulation studies + discussion
• I decide to take the lead and create an initial repository
• Add a draft .tex file, some analyses in .R with data and output
• Commit at appropriate stopping points

Commits do not affect the other branch

branch

Push all of her changes to github, then submit a pull request.

pull

pull2

merge

propose

issue

• git is a structured approach to tracking content
  • Small committment to learn and use
  • But benefits are enormous
  • … especially if using plain text files
• github is a web interface and repository host
  • Adds value to git
  • It’s not Dropbox, formal and structure commits + discussion
  • Everything is public
  • Alternatives: bitbucket, gitlab, self-hosting, local-only