Github
Git/Github can be complex. This guide serves to document our approach to using Git/GitHub effectively as a team.
Branches
Branches are extremely helpful for collaboration, but they can also be detrimental if they are not managed correctly.
Strategy
Our current build strategy works as follows:
- The main branch is our production known working branch.
- Code should go into main once it is thoroughly tested and follows our coding standards outline here.
- Code gets to main by being tested in "feature" branches and then merged into main via a reviewed PR.
- Code is only merged if it builds successfully via a GitHub action
Step-by-step example
- A branch is created called
fix_shooter_pidand based off of themainbranch. - The code is changed and tested on robot.
- If more changes are needed, changes are made in the
fix_shooter_pidfeature branch. - If code is successfully tested, a pull request is opened against
mainfrom thefix_shooter_pidfeature branch - If changes are needed, changes are made in the
fix_shooter_pidbranch and tested on the robot. Then those changes are committed and reviewed. - Code is merged into
mainvia the PR - The
fix_shooter_pidfeature branch is then deleted
But I need code from a different branch.
No you do not. This strategy relies on quick feature branches, and not long-lived branches. If changes are needed in a different branch in order to make your feature branch work, those changes should be merged into main first and fast-forwarded into your feature branch.
There may be times where we need to test multiple features at the same time. These should be merged into a branch which is a collection of the various features which need to be tested at the same time. These branch names should always start with qa_. Changes are NOT being committed to this aggregation branch, they are always committed back to the feature branch, then re-tested if needed. Additionally, this qa_ branch is never merged into main. Once it has served its purpose (all aggregated features are merged), it is deleted.