Git Flow

[ullrichd21]

Github Flow

The Github Flow of the project will work as follows.

• Main - This branch will contain the combined work of all the groups. All features, bug fixes, and documentation will be branched off this branch. All feature pull requests should merge into this branch.

Branch Conventions

Branches will be named with the proper team prefix, followed by the type of branch it is, followed by a short descriptive name.

Team Prefixes

• Generate -> gen
• Input -> in
• Output -> out
• Integration -> integ

For example, a branch for the generate team that is adding a feature for generate a yaml file might use the following name:
gen_feature_generate_yaml_file
Note: this branch would merge into the main branch.

Commit Messages

Please follow these guidelines when committing contributions:

• Commit messages should not exceed 50 characters (soft limit - exceptions include co-author or function names for example)
• Commit messages should be in imperative mood
• Should be void of all grammar and spelling mistakes
• Commits should be small and targeted.

Pull Requests

When filling out the template, please fill out all the prompts. When it comes to test coverage please include the test coverage percentage provided by pytest-cov after running the test suite on the project with your changes. This is important because it helps us know how your additions affect the overall test coverage as well as the test coverage of your contributions.

[Michionlion]

I would highly suggest using path separators / in the git branch naming scheme between "topics" like team or type of branch (e.g. gen/ would be the prefix for the generate team's branches), as this allows for better readability, autocompletion, and understanding. Additionally, it is slightly more conventional to use - for word separation, versus _. However, the opinion on that can be pretty varied.

Lastly, it may be useful for commit messages to allow an optional "body", such that a commit message would look like this:

Write the summary of the commit in imperative

Add descriptive body if changes are especially complex,
issues should be linked, a bug described, or other information
added might be useful for people looking through the history.

Then, the summary would have a limit of 50 characters (which is often enforced/warned about by git tooling), and the body would provide additional space for more information if needed.

Regarding test coverage, there are many services and GitHub Actions that can automatically provide comments or reports on test coverage, obviating the need for maintainers to manually run coverage and add the percentage. GatorGrader uses Codecov, which has worked out so far. It may be useful to look into this for added developer convenience.

[laurennevill]

Considering @Michionlion and his input on the git branch naming format, we should aim to take his advice for any new branches by using a path separator / after team specification and - to separate words instead of _. However, don't worry too much about older branches that follow the original suggested format.

[laurennevill]

GitHub Flow not Git Flow

Additionally, it has been brought to attention that for this project we will be following GitHub flow not Git Flow. So to reflect this change, all future pull requests should be merged into main and the develop branch will be removed. Hope this clears up any confusion.