The Git workflow for the 6220_2025 software uses 3 types of branches: "main", "dev", and Issue specific branches. All code changes are tracked by using the GitHub "Issues". Descriptions of the different branches, use of Issues, and development process are presented below.

The "main" branch is meant to contain competition ready software. The code should be cleaned up, free of any test code, commented properly, and follow the Google Java coding style. The "main" branch is updated by system testing the "dev" branch on Nessie, then merging it to "main" if all tests pass.

The "dev" branch is meant to contain working, unit tested code. The code should be cleaned up, free of any test code, commented properly, and follow the Google Java coding style. The "dev" branch is updated by unit testing an Issue specific branch on Nessie, then merging it to "dev" if all tests pass.

Issue specific branches are used to develop and test code changes. Each Issue should have its own corresponding branch. During development, there are no restrictions on the type or quality of code that can be checked into these branches. However, in order to merge the changes into the "dev" branch, the code must be cleaned up and unit tested.

All code changes are initiated by creating an Issue. The issue is used to create Issue specific branches, where code changes can be developed and tested. The code changes are then propagated to the "dev" and "main" branches. An overview of the process is shown below.

The 6220 software uses the following procedure for checking changes into the "dev" branch:

1. Create an Issue describing what you're working on.
   • Go to the Issues tab and click on [New issue].
   • Fill out title and description. May include links, pictures, background information, conversations, thoughts, etc.
2. Create an Issue specific branch (example video link).
   • Open your Issue and click on the "create a branch" link on right hand panel.
   • Click on [Create branch] button.
   • Note: Pull requests from this branch will automatically be linked to this Issue.
3. Do work on your Issue specific branch until you're ready to commit your changes. Make sure to only stage changes related to your Issue.

     git add <filenames>
     git commit -m "your commit message"

4. If the "dev" branch has changed while you were working and you haven't done a previous pull request from the Issue specific branch, then rebase your Issue specific branch first. Here's a tutorial video on rebasing.

     git fetch origin
     git rebase origin/dev

5. If you have a merge conflict, resolve all of them. Here's a tutorial video on how to do it. Commit the changes that resolved the merge conflict.

     git add <filenames>
     git commit -m "your commit message"

6. Unit test your changes on Nessie.
7. Push your changes.

     git push

9. Do a pull request to merge your changes into the "dev" branch.
   • Go to the Pull Requests tab and click on [New pull request].
   • Select your Issue related branch and click on [Create pull request].
   • In the description or comments, write Fixes #<IssueNum> to link the pull request to the Issue and automatically close the Issue after the merge. Optionally, write See #<IssueNum> instead to link to the Issue but not close it. Example:

     Fixes #123

10. The 2025-reviewers team is automatically assigned to review your pull request. Wait for one of them to approve.
    • Optional: Add additional code reviewers.
11. Click on [Squash and merge] to merge your changes to "dev". All your changes will be squashed into a single commit.

Note: Avoid making multiple pull requests from a single Issue specific branch. If you try to rebase after you've already merged a commit to the "dev" branch, it will mess up the history of the "dev" branch.

The 6220 software uses the following procedure for checking changes into the "main" branch:

1. Perform system test with "dev" branch on Nessie.
2. If all tests pass, do a pull request to merge the "dev" branch into the "main" branch.
3. Click on [Merge commits] to do the merge.

1. Make small, focused commits – Try to make each commit a single logical change (e.g., "Tune Elevator PID filter", not "Get robot working").
2. Stage intentionally – Selectively stage files to control what’s included.
3. Test before committing – Ensure your changes work and don’t break existing code.
4. Keep history clean - Avoid committing debug/temporary code. Consider squashing commits before merging.
5. Write clear, concise commit messages – Use imperative mood (e.g., "Add PID filter to Elevator motor control", "Clean up comments in Constants.java").