Commit Procedures

In order to aid in organization, the MegaMek projects have several policies when it comes to making commits.

Commit Messages

First, commit messages should try to include issue/pr numbers in the commit messages, so that commits can easily be linked to tracked issues. We also try to mention commits in the issues as well.

In addition, the project maintains a history.txt in the docs directory. This history.txt is used to create the changelog when new releases are created. Not every commit necessarily needs an entry in this file, but each a bug fix, new feature, or change that may impact a user is made there should be a corresponding entry in the history.txt, preferably with a reference to a related issue/pr number.

Branching and committing to master

A good practice with version control is to make each change small and self contained. Git supports this especially well with staging commits and branches. Issues that only require a single commit can be made directly into master, however if a bug or feature request requires multiple commits then it should ideally be done in a separate branch, which then will get merged into master, preferably with a pull request so there can be some code review and discussion. The project does not maintain any hard rules on this, and much of it is up to the judgment of the developer.