Using GitHub and AI

Getting Started

From here on, your team keeps its code in a GitHub repository: one shared, versioned home for your scripts, instead of files emailed back and forth. This chapter covers the few Git moves you actually need (create a repository, clone it, then commit, pull and push), how to keep data and secrets out of it, and how AI fits into your coursework.

You can do every step in Posit Cloud, in Positron or RStudio on your own machine, or in a terminal. The commands below are shown two ways, in plain git (for a terminal) and in R with the gert package (for the R console). Use whichever you like, in R or Python projects alike.

Slides: Data Science Quick Start for Six Sigma. Activities: Code It (Create a GitHub Repository) and Code It (Commit, Pull & Push on GitHub). The worked examples below are those two activities, step by step.

Git and GitHub, in one minute

Git is the version-control engine: it runs on your computer and records snapshots of your files, called commits. GitHub is a website that hosts a copy of a Git repository online, so your whole team can share it.

  • Repository (repo): a project folder that Git is tracking.
  • Clone: make your own local copy of a repo that lives on GitHub.
  • Commit: save a snapshot of your edits, with a short message saying what changed.
  • Pull: download your teammates' latest commits from GitHub.
  • Push: upload your commits to GitHub.

If you have not installed Git or made a GitHub account yet, the Git & GitHub setup guide walks through both.

Create a repository

This is the Create a GitHub Repository activity. One repository per team is enough.

  1. Sign in to GitHub and click New repository (the + menu in the upper right).
  2. Give it a simple name, preferably all lowercase with no spaces, such as team-reliability.
  3. Tick Add a README so the repository is not empty, and pick the R or Python .gitignore template (more on that below).
  4. Click Create repository. The green Code button shows its URL, ending in .git. You will need that URL to clone it.
  5. Add your teammates: Settings › Collaborators › Add people, then type each teammate's GitHub ID. They get an invitation to accept.

Clone a repository

Cloning copies the repository from GitHub onto the machine where you work.

Posit Cloud: New Project › New Project from Git Repository, and paste the .git URL. Posit Cloud clones it for you.

A terminal (Git Bash on Windows, Terminal on a Mac):

# from the folder where you keep code:
git clone https://github.com/YOUR-ID/YOUR-REPO.git
cd YOUR-REPO

You can clone the course code repository, timothyfraser/sysen, the same way. It holds the workshops/ datasets and functions/ helpers. It is read-only for students: you pull from it, and your own work lives in your team's repository.

Commit, pull and push

This is the Commit, Pull & Push on GitHub activity.

First, a personal access token

GitHub will not take your account password for a push. It wants a personal access token (PAT) instead. On GitHub, click your profile icon, open Settings › Developer settings › Personal access tokens, and make one:

  • Fine-grained (scoped to one repository): under Permissions, set Contents to Read and write. That adds Metadata automatically.
  • Classic (all your repositories): select the repo scope.

Give it an expiration date after the end of the term. Copy it once and keep it in a password manager or a private note. Anyone holding it can act as you on GitHub, so treat it like a password.

The loop

Every working session follows the same loop: pull first, work, then add, commit and push. In R, from the console:

library(gert)
library(credentials)
credentials::set_github_pat()           # paste your PAT when prompted (once per machine)

gert::git_pull()                        # 1. get your teammates' latest commits
gert::git_add(dir(all.files = TRUE))    # 2. stage every new or edited file
gert::git_commit_all("my first commit") # 3. record a snapshot, with a message
gert::git_push()                        # 4. send it up to GitHub

The same loop in a terminal:

git pull                             # 1. get the latest
git status                           #    see what changed
git add .                            # 2. stage it
git commit -m "xbar chart: first pass"   # 3. record it
git push                             # 4. send it to GitHub

Commit often, in small pieces, with short messages. The messages are breadcrumbs, so you (or a teammate) can trace what changed and when. Always pull before you start. Two people editing the same lines without pulling is how you get a merge conflict.

A sensible .gitignore

A .gitignore file, at the top of the repository, lists the files Git should never upload. Git skips anything that matches a line in it. A good starting point for this course:

# secrets: never commit these
.env
*.pem

# R session and editor clutter
.Rproj.user/
.Rhistory
.RData
.Ruserdata

# Python clutter
__pycache__/
.venv/
.ipynb_checkpoints/

# operating-system clutter
.DS_Store
Thumbs.db

From R, usethis can do this for you:

install.packages(c("usethis", "gert", "credentials"))
usethis::use_git_ignore(".env")   # add one line to this repository's .gitignore
usethis::git_vaccinate()          # also protect .Rhistory, .RData, .env on every repo on this machine

GitHub keeps ready-made templates for every language at github.com/github/gitignore.

What to commit, and what not to

Commit: your scripts (.R, .py, .Rmd, .qmd), your README, small figures you made, and small data files your code needs to run.

Do not commit:

  • Keys, tokens and passwords. Put them in a .env file (GITHUB_PAT=...) and list .env in your .gitignore. A key that reaches GitHub has to be treated as leaked: revoke it and make a new one. Deleting the file afterwards does not remove it from the history.
  • Large data files (more than about 50 MB). GitHub rejects files over 100 MB. Leave large data where it came from, and commit the code that downloads or reads it.
  • Private or personal data, about anyone. If a dataset names people, it stays off GitHub.
  • Clutter your editor or session makes on its own: .Rhistory, .RData, __pycache__/.

Before you commit, run git status (or look at the Git pane in Posit Cloud) and read the list. If a file on it surprises you, find out why before it goes up.

Using AI for coursework

What AI you may and may not use, and where, is set by the course AI policy in the syllabus, together with the academic integrity rules. Read both. They are the rules, and this chapter does not restate or change them.

How the course itself uses AI, to give you faster feedback on your submitted code, is explained in the AI in this Course slides.

Working well with an AI assistant

Where the policy allows AI for code, it pays to use it deliberately. These habits are the ones that work:

  • Give it context. Share the script you are working on and the documentation for the package in question, not a one-line question. An assistant that can see your data's column names and the function's help page writes code that fits. One that cannot will guess.
  • Set your standards once. Most assistants accept standing instructions: a project rules file, or a note you paste at the start. Tell it your house style (for R in this course: = for assignment, %>% pipes, one library() call per package) so you are not re-correcting it every time.
  • Read, run and check every line. Run what it gives you, and compare the result with what you expected. Something that runs is not the same as something that is right. An assistant will quietly use the wrong column, the wrong test or the wrong formula.
  • Ask it to explain, not only to write. "Why does this use qnorm() and not pnorm()?" teaches you something. "Write the answer" does not, and sooner or later you will need to do it on your own.
  • Commit in small steps. Commit before you paste in a large block of generated code. If it breaks things, you can see exactly what changed and roll it back.
  • Never paste a key, a token or someone else's data into a chat. Treat an AI chat like a public page.

Checklist

  • You have a GitHub account, a personal access token saved somewhere safe, and your team's repository with your teammates added.
  • You can clone the repository in Posit Cloud or a terminal, and run pull, add, commit and push.
  • Your repository has a .gitignore that covers .env and session clutter, and git status shows nothing you did not mean to commit.
  • You have read the AI policy.