Version Control

Monday, May 4

Today we will…

  • Questions about Midterm?
  • New Material
    • git/GitHub
    • Connect GitHub to RStudio
  • PA 6: Merge Conflicts – Collaborating within a GitHub Repo

Questions about Midterm Exam?

Version Control

What is version control?

A process of tracking changes to a file or set of files over time so that you can recall specific versions later.

git/GitHub Basics

Git vs GitHub

  • A system for version control that manages a collection of files in a structured way.
  • Uses the command line or a GUI.
  • Git is local.

Git vs GitHub

  • A system for version control that manages a collection of files in a structured way.
  • Uses the command line or a GUI.
  • Git is local.

  • A cloud-based service that lets you use git across many computers.
  • Basic services are free, advanced services are paid.
  • GitHub is remote.

Why Learn Git/GitHub?

  1. GitHub provides a structured way for tracking changes to files over the course of a project.
  • Think Google Docs or Dropbox history, but more structured and powerful!
  1. Share your work transparently!
  2. Designed for programming collaboration and project management.
  3. You can host a URL of fun things (like the class text, these slides, a personal website, etc.) with GitHub pages.

In this class…

  • We just want to introduce you to the basics of Git and GitHub
  • There is a lot more cool functionality in both!
  • Come chat with me if you want to learn more

Git Repositories

Git is based on repositories.

  • Think of a repository (repo) as a directory (folder) for a single project.
    • This directory will likely contain code, documentation, data, to do lists, etc. associated with the project.
    • You can link a local repo with a remote copy on GitHub.

  • To create a repository, you can start with your local computer or you can start with the remote copy.

Git Repositories

What does Git do?? (very basics)

By default:

  • Git tracks changes in any documents in a given repo
  • Git records any changes to lines in the document since the last version of the document was saved (committed)

You need to:

  • Tell Git if there are files you don’t want it to track (.gitignore)
  • Tell Git when to save changes to the repo (commit)
    • Once you do that, you can always look back on your previous versions and changes!

.gitignore

Sometimes there are files that you do not want to track.

  • A .gitignore file specifies the files that git should intentionally ignore.
    • Note that annoyingly a .gitignore is an “invisible file” in many file browsers
  • Often you want to ignore machine generated files (e.g., /bin, .DS_Store) or files/directories that you do not want to be shared (e.g., solutions/).
  • We want to ignore .Rproj files!

.gitignore example

Dr. C’s .gitignore for her STAT 331 materials repo

Actions in Git

Cloning a Repo


Create an exact copy of a remote repo on your local machine.

(typically only done once at the beginning of a project.)

Committing Changes

Tell git you have made changes you want to add (save ✅) to the repo.

  • local action

  • Also provide a commit message – a short label describing what the changes are and why they exist.

The red line is a change we commit (add) to the repo.

The log of these changes (and the file history) is called your git commit history.

  • You can always go back to old copies!

Commit Tips

  • Use short, but informative commit messages.
  • Commit small blocks of changes – commit every time you accomplish a small task.
    • You’ll have a set of bite-sized changes (with description) to serve as a record of what you’ve done.
  • With frequent commits its easier to…
    • find the issue when you mess up!
    • read back through what you changed!

Pushing Changes


Update the copy of your repo on GitHub so it has the most recent changes you’ve made on your machine.

  • local to remote ⬆ action

Pulling Changes


Update the local copy of your repo (the copy on your computer) with the version on GitHub.

  • remote to local ⬇ action

Pushing and Pulling

Workflow

When you have an existing local repo:

  1. Pull ⬇ the repo (especially if collaborating).
  2. Make some changes locally.
  3. Commit ✅ the changes to git.
  4. Pull ⬇ any changes from the remote repository (again!).
  5. Resolve any merge conflicts.
  6. Push ⬆ your changes to GitHub.

On the left is a quote from Hadley Wickham and Jenny Bryan that says Using a Git commit is like using anchors and other protection when climbing…if you make a mistake you can’t fall past the previous commit. Commits are also helpful to others, because they show your journey, not just the destination. On the right, two little monsters climb a cliff face. Their ropes are secured by several anchors, each labeled Commit. Three monsters on the ground support the climbers.

Artwork by Allison Horst

Merge Conflicts

Merge Conflicts

These occur when git encounters conflicting changes.


Merge Conflicts

  1. Maybe you are working in real time on the same line of code or text as a collaborator.
  2. Maybe you forgot to push your changes the last time you finished working.
  3. Maybe you forgot to pull your changes before you started working this time.

Merge Conflicts

We will work on resolving merge conflicts today!


But when all else fails…

delete your local repo and clone again.

A bunny and a mouse, both looking stressed and sweaty, look on at a smoking laptop as flames start to grown from it. Text reads: Plan on it.

Artwork by Allison Horst

Tips for Avoiding Merge Conflicts

  • Always pull before you start working and always push after you are done working!
    • If you do this, you will only have problems if two people are making local changes to the same line in the same file at the same time.
  • If you are working with collaborators in real time, pull, commit, and push often.
  • Git commits lines – lines of code, lines of text, etc.
    • Practice good code format – no overly long lines!

Connect GitHub to RStudio

Install + Load R Packages

Work in your console or an Rscript for this.

  1. Install and load the usethis package.
install.packages("usethis")
library(usethis)
  1. Install and load the gitcreds Package.
install.packages("gitcreds")
library(gitcreds)

Configure git

  1. Tell git your email and GitHub username.
use_git_config(user.name = "JaneDoe2", user.email = "jane@example.org")

(Nothing should happen.)

Generate your Personal Access Token

  1. Generate a PAT.
create_github_token()
  • This will open GitHub and ask you to log in.
  • Fill in a Note and an Expiration (AT LEAST 60 days from now).
  • Click Generate Token.

Store your PAT

  1. Copy your PAT.
  1. Run the following code.
gitcreds_set()

When prompted to Enter password or token:, paste your PAT.

Verify your PAT

  1. Let’s verify.
git_sitrep()

PA 6: Merge Conflicts

You will be completing this activity in groups of 3-4.

IMPORTANT

This activity will only work if you follow the directions in the exact order that I have specified them. Do not work ahead of your group members!

Cartoon of the GitHub octocat mascot hugging a very sad looking little furry monster while the monster points accusingly at an open laptop with MERGE CONFLICT in red across the entire screen. The laptop has angry eyes and claws and a wicked smile. In text across the top reads gitHUG with a small heart.

Artwork by Allison Horst

To do…

  • PA 6: Merge Conflicts
    • Due Monday, 5/4 at 11:59pm – TODAY.
  • Midterm Exam
    • Wednesday, 5/6.

Office Hours

Tuesday from 9:30-11am and 2-3:30 pm.

None scheduled on Thursday but available upon request.