Git and Pull Requests

One person on the team does this once. Everyone else clones the result.

1. Open the Workshop folder in the WPILib VS Code and open Source Control with Ctrl+Shift+G.
2. Click Initialize Repository. You should see: every project file listed under Changes, and no build folder among them.
3. Type Generated project in the message box and click Commit. Answer Yes when it offers to stage all your changes.
4. Click Publish Branch, sign in to GitHub when asked, and choose a private repository.

A teammate gets a copy with Git: Clone from the command palette, then Clone from GitHub, then the repository name. Clone into Downloads or another plain local folder, for the same reason as the project.

Every change starts from an up to date main. Pull first, then branch, so your work starts from what the team has now.

1. Click the branch name at the bottom left of the window. Check it says main, then open … in Source Control and choose Pull.
2. Click the branch name again, choose Create new branch, and name it for the change: arm-intake-angle, not my-branch.
3. Make the change and build it. Then commit with a message that says what the code now does: Lower the intake angle to 0.48.
4. Click Publish Branch. Later commits on the same branch go up with Sync Changes.

Commit whenever the project builds and one thing is finished. Five small commits are easier to read in review, and easier to undo, than one commit holding a whole evening.

git switch main
git pull
git switch -c arm-intake-angle
git add -A
git commit -m "Lower the intake angle to 0.48"
git push -u origin arm-intake-angle

1. Open the repository on GitHub. A banner offers Compare & pull request for the branch you just pushed. Click it.
2. Check the base is main. In the description, write what changed and how you tested it: "Ran in hardware simulation, arm stops at the new angle."
3. Add a teammate under Reviewers and click Create pull request.
4. The reviewer opens Files changed, leaves a comment on any line they question, and chooses Approve or Request changes. New commits pushed to the branch join the same pull request.
5. Once approved, click Merge pull request, then Delete branch. Back in VS Code, switch to main and pull.

The reviewer checks that the change does what the description says and nothing else, and that it follows the conventions below. When a line is unclear, they ask. The answer usually belongs in a comment in the code, where the next reader will find it.

Every branch of Workshop-Code formats itself with Spotless, using the same Google Java Format that WPILib uses. Add it to your build.gradle once: the plugin line goes inside the existing plugins block, and the rest goes at the bottom of the file.

1plugins {
2    // ...the three plugins already here
3    id "com.diffplug.spotless" version "8.9.0"
4}
5
6spotless {
7    lineEndings = 'PRESERVE'
8    java {
9        target fileTree('.') {
10            include 'src/**/*.java'
11            exclude '**/build/**', '**/bin/**'
12        }
13        toggleOffOn()
14        googleJavaFormat('1.35.0')
15        removeUnusedImports()
16        trimTrailingWhitespace()
17        endWithNewline()
18    }
19}
20
21// Format on every build.
22tasks.withType(JavaCompile).configureEach {
23    dependsOn 'spotlessApply'
24}

With that last block, every Build Robot Code formats the project first, so nobody argues about indentation in review. To format without building, run .\gradlew spotlessApply in the VS Code terminal. .\gradlew spotlessCheck only reports.

The rest of what this course already does, written down:

• A mechanism class is named for the thing: Arm, Flywheel. Its command methods are named for the result: vertical(), runFast().
• A method that answers yes or no starts with is, like isAtTarget().
• Lambdas are written () -> stopMotor(), never this::stopMotor.
• One change per pull request, on a branch named for it.
• Nobody commits to main directly, including mentors.

• Merge conflict. GitHub says the branch has conflicts, because two branches changed the same lines. In VS Code, switch to main and pull, switch back to your branch, then …, Branch, Merge, and pick main. Each conflict shows both versions between <<<<<<< and >>>>>>> markers. Pick Accept Current, Accept Incoming, or edit by hand, then build, commit and sync.
• Build output in the commit. Files under build/ or .gradle/ appear in Changes. The generated .gitignore excludes both, so it is missing or the project sits inside another repository. Copy .gitignore back from a fresh project, run git rm -r --cached build, and commit.
• Forgot to pull. The push is rejected and VS Code says to pull first, because the remote branch has commits you do not. Pull, build, then push again. A branch made from a stale main shows up later as a conflict, so the branch step starts with a pull.

Make one small change on a branch, such as a comment above Robot, and take it all the way through review.