Create a branch ruleset

Repo: Settings → Rules → Rulesets → New ruleset → New branch ruleset.

• Name ruleset: protect-main
• Enable status: Active
• Bypass list (optional): who may skip the rule
• Target branches: add target → Default (or pattern ~DEFAULT_BRANCH)
• Rules — turn on:
  • Restrict deletions
  • Require a pull request before merging
    • Require 0 approvals: You can merge your own PR
    • Require 1 approval: Someone else must approve
  • Block force pushes

Clone it locally

cd ~/github
git clone <paste-url>
cd REPO-NAME

Try pushing to main

Make a small change directly on main, commit it, and try to push — it should be refused.

• Positron/ VS Code / RStudio: edit any file → stage + commit → push / sync.

The push is rejected:

remote: error: GH013: Repository rule violations found for refs/heads/main.

That’s the protection working. Nothing reaches main without a PR.

Install Air — Positron / VS Code

1. Extensions (Cmd+Shift+X) → search “Air” (by Posit) → Install.
2. Open user settings JSON (Cmd+Shift+P → Open User Settings (JSON)) and add:

{
  "[r]": {
    "editor.defaultFormatter": "posit.air",
    "editor.formatOnSave": true
  }
}

Note: You can enable or disable Air per-workspace, and turn formatting off later by setting "editor.formatOnSave": false. Useful when editing an unformatted file, to avoid a whole-file diff.

Install Air — RStudio

Air isn’t tightly integrated with RStudio. Use the styler package instead:

install.packages("styler")

Then Addins → Style active file before each commit, and enable Tools → Global Options → Code → Saving → Ensure source files end with a newline.

Create & triage an issue

Create an issue for the small task you’ll do today:

• Title: “Add [name]’s greeting function”

• Body: what & why, plus a checklist:

  - [ ] Add greet() to team/yourname.R
  - [ ] Have it return a greeting for a given name

• Sidebar: set an Assignee (yourself), a Label (enhancement), and optionally a Milestone.

Create a branch from the issue

On your issue, in the Development section (right sidebar) → Create a branch. Keep or change the suggested name — either way the branch is linked to the issue.

Now get that branch onto your machine:

• Positron / VS Code / RStudio: click the branch picker → fetch/refresh, then switch to the new branch.
• Terminal:

git fetch
git switch <issue-branch-name>

Make a change

Create a new file named after you so we don’t overlap — e.g. team/yourname.R:

# team/tracey.R
greet <- function(name) {
  paste0("The best state in the nation, 
  New 
  Jersey, 
  welcomes you, ", name)
}

greet("Danielle")

Type it messily first (no spaces, odd indents), then save and watch Air reformat it to Tidyverse style.

Commit your work

In Source Control panel (Positron/VS Code) or Git pane (RStudio):

1. Stage team/yourname.R (click the + next to the file).
2. Type a clear commit message.
3. Click Commit.

Prefer the terminal?

git add team/yourname.R
git commit -m "Add Tracey's greeting function"

Push your branch to GitHub

• Positron / VS Code: click the sync arrows in the Source Control panel.
• RStudio: click the Push (green up-arrow) in the Git pane.

Prefer the terminal?

git push

Branches can be created several ways

You can create a branch from:

• github.com — from an issue (links it to the issue, like today), or the Branches page → New branch.
• Positron / VS Code — branch picker (bottom-left) → Create new branch….
• RStudio — Git pane → New Branch.
• Terminal — git switch -c your-branch.

Open the PR

After pushing, GitHub shows a “Compare & pull request” banner — click it (or Pull requests → New pull request).

• Base: main · Compare: your branch
• Title: summarize the change: “Add greeting function”
• Description: what it does and why, plus Closes #<issue-number>.

Press Create pull request. The PR is now open for review.

Assign your reviewer

Pair up: A reviews B, and B reviews A.

In your PR’s right sidebar → Reviewers → choose your partner. Our ruleset requires 1 approval before the PR can merge, so your partner’s review is what unblocks the merge.

What a reviewer is actually doing

GitHub gives three review outcomes:

• Comment — feedback, no decision.
• Approve — ready to merge.
• Request changes — specific things must be fixed first.

Reviewer requests changes

Open your partner’s PR → Files changed tab.

• Hover a line → click the blue + → leave a line comment, for example:
  • “Required: make the greeting friendlier — e.g., add an exclamation point.”
• Click Submit review → Request changes → Submit review.

You can also review in your IDE

Switch to the PR branch locally and run the code — often the only way to catch real errors.

Reviewer re-reviews & approves

Re-open your partner’s PR and look at the new commits in Files changed.

For a tiny fix, you can also just make the change yourself:

• Files changed → click the pencil ✏️ → edit → Commit changes to the PR’s branch.

When the changes look good: Review changes → Approve → Submit.

Author merges

Once approved, the green Merge pull request is enabled.

Choose a merge strategy from the dropdown menu → click Merge pull request → Confirm merge.

Because your PR said Closes #N, merging it auto-closes your issue — check the Issues tab to confirm.

Delete the merged branch

Right after merging, GitHub shows Delete branch — click it. This deletes the branch on GitHub (the remote copy).

Now clean up on your machine:

1. Switch to main and pull — Positron/VS Code/RStudio: pick main in the branch picker, click pull/sync. This brings the merged work down.
2. Delete your local branch — it still exists locally until you remove it:
   • Positron / VS Code: Cmd+Shift+P → Git: Delete Branch… → pick it.
   • RStudio / Terminal: git branch -d <your-branch>

Talk to your collaborators

Communication is the most important code review tool. On your project team, agree on the code review conventions up front.

• Who merges — author after approval, or the reviewer?
• When a reviewer edits directly vs. just leaving comments.
• How many approvals, and who reviews whom.
• How fast reviews happen, so PRs don’t go stale.
• Branch/PR scope before review.
• Who’s touching what, so two people don’t clash on a file.

Set up a conflict — with your partner

A conflict happens when multiple people change the same line. You’ll create one on purpose with your partner a shared file (e.g. sop-demo/conflict-files/partners-1.R).

It will take three steps:

1. Both partners branch from the main.
2. Partner A edits a file and merges it to main.
3. Partner B edits the same line in the same file on their branch and creates a PR — this will trigger a conflict.

First, each pair will be assigned to a file in the conflict-files folder.

Next, decide who is Partner A and who is Partner B.

Conflict: Step 1 — both branch from main

Both partners: Make sure main is up to date first:

• Positron / VS Code / RStudio: switch to main in the branch picker → pull / sync.
• Terminal: git switch main && git pull.

Both partners: Create your own branch from the main (A and B on separate branches).

Conflict: Step 2 — Partner A edits and merges to main

Partner A edits their assigned file. Partner B should not edit it yet, but prepare for Partner A’s PR.:

1. Partner A: edit the file → commit → push → PR
   
2. Partner B: review and mentally note a line that has changed → approve
3. Partner A: merge to main.

Conflict: Step 3 — Partner B edits and opens a PR

Partner B, within their branch:

1. Edit the same line in the same file, commit, and push branch
2. Open PR. GitHub will indicate a merge conflict and block the merge until it’s resolved.

Resolve conflict on github.com

Click Resolve conflicts to open the web editor:

<<<<<<< your-branch-name
  paste0("I went on a ", activity, " — best summer!")
=======
  paste0("I went on one ", activity, ", it's summer!")
>>>>>>> main

Options:

• Use buttons to choose version to keep.
• Manually delete the <<<<<<<, =======, >>>>>>> markers, keeping the correct line.

Mark as resolved → Commit merge. The PR is now mergeable.

Resolve it in Positron / VS Code

After Git: Merge Branch…, the conflicted file opens in the merge editor:

• Accept Current Change — your branch’s version.
• Accept Incoming Change — the version from main.
• Accept Both — keep both, in order.

Then save, stage, commit, push.

Resolve it in RStudio

RStudio has no merge editor — the conflicted file just shows the raw markers. Edit them by hand, then stage and commit in the Git pane.

More on conflicts in RStudio: NCEAS coreR — Collaborating with Git

Keep your branch up to date with main

Pull main into your branch often — the longer it drifts, the harder the merge.

How (with main already pulled):

• Positron / VS Code: Cmd+Shift+P → Git: Merge Branch… → pick main.
• Terminal: git switch your-branch, then git merge main.

Also: small, focused branches and PRs, and coordinate on shared files.