Team collaboration

Version control

Git keeps a history of code changes. A commit is a saved point in that history. A remote is a shared copy, often on GitHub, that teammates can fetch from and push to.

Before a new programmer edits the robot project, agree on who owns the shared repository and how the team checks changes on the robot. A successful code build does not prove that motors, servos, and sensors behave correctly.

Git workflow

Use these commands in your team's project folder. If you use Android Studio's Git buttons, the same ideas still apply.

1. Get the latest team work: git pull. If Git reports a conflict, stop and resolve it with a teammate before editing more files.
2. Make one focused change. For example, adjust one arm limit and test the arm safely.
3. See what changed: git status lists changed files; git diff shows changed lines. Review these before saving a commit.
4. Stage only relevant files: git add TeamCode/src/main/java/org/firstinspires/ftc/teamcode/Arm.java. Staging selects exactly what goes into the next commit.
5. Save the change: git commit -m "Limit arm power during homing".
6. Share it: git push sends your local commits to the shared remote.

This example path is only illustrative; use your actual file path. A commit message should say what behavior changed. If a change needs context, explain the reason in the commit body or team review.

Branches and reviews

For a larger task, create a branch. A branch is a separate line of work that teammates can review before it joins the main branch.

git switch -c feature/arm-homing
# Edit, test, review, and commit your change.
git push -u origin feature/arm-homing

Open a pull request or use your team's agreed review process. Ask another programmer to read the change and, when relevant, watch the robot test. Merge only after the team understands what the new behavior does.

If two people change the same lines, Git may show a merge conflict. Read both versions, decide what the final code should do, then build and test that result. Do not automatically keep one side without understanding the other.

Review checklist

• Does the code compile, and is the changed behavior tested on the robot?
• Do hardware names match the Robot Controller configuration?
• Are motor direction, power, and servo limits safe for this mechanism?
• Can another student understand the intent from names and short comments?
• Did the commit include only the intended files?

Keep generated build files and personal secrets out of commits. The FTC SDK project includes a .gitignore; review it before adding a new kind of generated file. If a team accidentally commits a secret, remove or rotate the secret in its original service as well as correcting the repository history.

Onboarding

Pair on one small task: one student edits while the other asks what each line does and watches the test. Switch roles after the first working change. Keep a short README with the robot configuration names, how to build the project, and the steps for a safe test.