For me, the minimum set of best-practices for “good” process:
- Each software developer always works on their own branch.
- Reviewed and tested software always gets merged promptly to a special, golden, integration branch
- Tags get put on integration branch nodes when a set of content is at a useful milestone. (including major feature additions, or software intended to run for an extended time ont he robot).
- Prior to merging to integration, code is checked for formatting and functionality. Run all unit tests if you have any.
Process-wise, I believe what needs to change must be established prior to starting work. This what is documented as a single Github Issue. The developer then creates a new development branch at the appropriate start point, making note in the issue which branch they used to resolve the issue.
My big key is that you don’t go changing random stuff in code that’s unrelated to your task. The branch contains the work required to resolve the issue - no more, no less. If there’s something else you want to do, make a separate branch and issue for it. It’s the discipline to prevent the “wiz-bang” attitude of “but look how much better I made it” - Better means a better-working robot, and all code changes need to be made with that mentality. Don’t play with stuff for the sake of playing with stuff.
Use the tags and milestones to categorize and group issues. For example, issues may be grouped by where the test should occur (on robot? on test bench? no test?).
After development and test, the issue should have any comments related to requirements changes or review notes, and should be closed out after merge.
It’s important to remember that, at the end of the day, all this advice is simply to help write better software. Focus on fixing pain points, and don’t put additional work in that adds no new true value. In addition, regularly review the process steps to ensure they’re all working as intended, and not causing unnecessary burden.
Some additional resources:
Git Flow - a recommendation on branching strategy in Git.
Semantic Versioning - a standard for how to ensure tag names are meaningful.