Commit Procedures - MegaMek/megamek GitHub Wiki

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

Pull Request Titles

Release notes are generated automatically from pull request titles, so the title is what players end up reading in the release notes. Give every pull request a title in this shape:

  • Bug fixes start with Fix and the issue number: Fix #1234: NPE when loading an ASF with engine damage from the MUL
  • Everything else starts with Close and the issue number: Close #1234: Properly calculate armor crit slot count for superheavy meks

More than one issue can be listed: Close #111, #5329: Added automatic tracking of unit history.

Write the description for a player rather than for a reviewer. "Fix #1234: Fixed the thing" tells nobody anything once it reaches the release notes.

Closing the Issue

Putting the issue number in the title does not close the issue. GitHub only acts on closing keywords in the pull request description, or in commit messages - never in the title. The description needs its own line:

Fixes #1234

Any of these keywords work:

  • Close / Closes / Closed
  • Fix / Fixes / Fixed
  • Resolve / Resolves / Resolved

Closing more than one issue needs the keyword repeated in front of each number:

Fixes #1234, fixes #5678     closes both
Fixes #1234, #5678           closes only #1234

For an issue in another repository of the suite, qualify it: Fixes MegaMek/mekhq#1234.

history.txt

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:

  1. The history.txt file will be updated by the release engineer during the release process
  2. Content will be copied from GitHub's automatically generated release notes
  3. 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 Release Notes and History.txt Process wiki page.

Branching and committing to main

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 main, 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 main, 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.