Git Workflow

[DRAFT] This is a draft proposal and should be treated as such. Nothing below this line is official yet.

Team 1816 The Green Machine uses Git for its version control system. This year, there will be some effort toward maintaining a clean Git repo structure and workflow.

The master branch

This branch is the holy grail. You never push to master directly. You never force push to master. All code must be tested before merging to master. We should be able to deploy master to our robot at any time and be competition ready. All merges to master will come from the develop branch, and a pull request will be opened that is reviewed by at least one veteran member or mentor.

The develop branch

This is the branch where most active development takes place. It does not neccessarily have to be stable. All members can push to this branch. However, you never force push to develop. However, for larger features, it is recommended to create a feature branch.

Feature branches

This is a branch that has been branched from develop to contain changes that can be logically grouped as one feature or set of features. All feature branches should start with the prefix feature/.

Stable version tagging

When a stable point in the robot code is reached, for example, a competition, the code should be merged to master and an annotated Git tag should be created, for example nsr-day1. Annotated tags are created from the command line like this:

$ git tag -a nsr-day1 -m "Stable code for day 1 of North Star Regional"

This allows us to easily revert or check out previous stable code without having to remember commit IDs or search the commit history.

Pull Requests

Pull requests should be grouped into smaller sets of logically related changes. Try to avoid 'monolith' pull requests, as these are difficult to review. Having several smaller pull requests allows for freedom and choice in which changes to implement. Pull request messages should be descriptive and describe exactly what the changes would do if merged.