Closed nmcglo closed 4 years ago
Yeah I think it would make sense that we should have CODES and ROSS follow similar workflows. I think this will make it easier for us to keep track of matching versions between ROSS and CODES too.
Yeah, so the new development workflow for CODES will generally be similar to that of ROSS and what's mentioned in the link that I gave in the OP. CODES now has a develop
branch that feature branches should merge into. The only branches that should merge into master should be the develop
branch and short-lived hotfix branches that need to be committed to master in a timeframe that is shorter than that of develop
.
The master
branch should not be committed directly to it. Feature branches should be merged to develop
and develop
should be merged into master when a release is planned. Hotfixes should be completed in their own hotfix-*
branch and merged into develop
and master
simultaneously.
I haven't decided on the best practice for merge commits (squash, fast forward only, or merge commit, etc). Willing to discuss that. For now, commits should generally be self explanatory and not embarrassing for the author or the codebase (i.e. professional) so that if they're committed to the master
branch history, it doesn't look too ugly.
This is just to serve as a TODO to change the way that code is committed to the repo. Currently code is committed to remote branches and a pull request into Master is created. This is a source of instability as new code may have unintended consequences that aren't found through simple testing.
Perhaps something like this: https://nvie.com/posts/a-successful-git-branching-model/