-
Notifications
You must be signed in to change notification settings - Fork 329
Commit Procedures
In order to aid in organization, the MegaMek projects have several policies when it comes to making commits.
NEW PROCESS: Commit messages now require specific formatting to support our automated release notes system:
- For bug fixes, start with the word "Fix:" followed by a clear description (Example:
Fix: NPE when loading ASF with engine damage from MUL) - For features or improvements, start with "PR:" followed by a clear description (Example:
PR: Properly calculate armor crit slot count for superheavy meks)
The project maintains a history.txt in the docs directory. Previously, each developer was expected to add entries to this file for bug fixes, new features, or changes that impact users. However, this process has changed. Now:
- The
history.txtfile will be updated by the release engineer during the release process - Content will be copied from GitHub's automatically generated release notes
- This eliminates the need for individual developers to make manual history entries
This new approach streamlines the release process, standardizes documentation format, automatically tracks contributors, and provides more detailed change information including links to full changelogs between versions.
For more details on this new process, please see the [Changes to GitHub Release Notes Process](link-to-your-wiki-page) wiki page.
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.