Skip to Content
Course content

186: Git Workflows for R Projects

Click on the "Edit" button in the top corner of the screen to edit your slide content.

Imagine you're working in a high-end professional kitchen. The "Main Menu" is what the customers are actually eating right now—it has to be perfect. You would never just start experimenting with a new, risky sauce directly on the plate being sent to table five. Instead, you go to a side prep table. You mess around with the ingredients, taste it, maybe ruin a few batches, and only when the head chef tastes it and gives a thumbs up do you integrate that new sauce into the official menu.

In R projects, your main branch is that final plate. If you're halfway through rewriting a complex ggplot2 visualization or changing how you join two massive data frames, and you do it directly on main, you've just broken the "menu." If a colleague needs to run the analysis right now, they're getting a broken script. That's why we use a Feature Branch workflow.

Mapping the Kitchen to Git

  • The Main Menu is your main branch. It should always be "deployable"—meaning the code runs from start to finish without errors.
  • The Prep Table is your feature branch. This is where you create a copy of the code to try out that new dplyr pipeline or a different statistical model.
  • The Taste Test is the Pull Request (PR). This is where you (or a teammate) review the changes before they touch the main codebase.
  • Plating is the Merge. Once the code is verified, you move those changes back into main.

Carving Out Your Own Space

Let's say you're working on a project that analyzes quarterly sales. You realize the data cleaning script clean_data.R is missing a filter for cancelled orders. Instead of editing it on main, you create a dedicated branch. I usually name my branches based on the task, like feature/filter-cancelled-orders.

# Create and switch to a new branch
git checkout -b feature/filter-cancelled-orders

Now you're on your "prep table." You can rewrite the filter() call, break the code, and commit your progress without worrying about breaking the version of the project that your boss is currently using for a presentation.

The R-Specific Friction Point: .Rproj and .Rhistory

Here is where things usually get messy for R users. If you're working in a team, you'll often see "merge conflicts" in the .Rproj file or the .Rhistory file. These files change almost every time you open RStudio, but they don't actually contain any logic. They are noise.

I've seen too many engineers waste hours trying to "fix" a conflict in a hidden history file. Do yourself a favor: make sure your .gitignore file specifically excludes these. Your workflow will be infinitely smoother if Git only tracks your .R and .Rmd files, not the metadata RStudio generates in the background.

Bringing the Feature Home

Once your cleaning script is working and the numbers look right, you merge it back. If you're using a platform like GitHub or GitLab, you'd push your branch and open a Pull Request. If you're working locally, it looks like this:

# Switch back to the main menu
git checkout main

# Bring the changes from your prep table into main
git merge feature/filter-cancelled-orders

# Delete the prep table now that we're done
git branch -d feature/filter-cancelled-orders

By following this, you treat your R code like a professional software product. You stop saying "it worked on my machine five minutes ago" and start having a reliable, versioned history of exactly when and why a specific analytical change was made.




📋 Practical Task

Implementing a Feature Branch for a Tidyverse Pipeline Update

You have an existing R project with a script called analysis.R that calculates the mean of a variable called score. Your goal is to update this to calculate the median instead, but you must do this using a professional Git workflow to avoid disrupting the main codebase.

Perform the following steps in your terminal/Git bash:

  1. Create a new branch named feature/update-to-median and switch to it.
  2. Open analysis.R and change the mean() function call to median().
  3. Stage the change and commit it with the message: "Change score calculation from mean to median for better outlier handling".
  4. Switch back to the main branch.
  5. Merge the feature/update-to-median branch into main.
  6. Delete the feature branch to clean up your workspace.

Verification: Your main branch should now contain the median() function, and git branch should show only the main branch remaining.

Rating
0 0

There are no comments for now.

to be the first to leave a comment.