Difference between revisions of "Git Guidelines"

From Minetest Developer Wiki
Jump to navigation Jump to search
Line 27: Line 27:
 
# Commit messages must start with a capital letter and be in the present tense (look at the commit log)
 
# Commit messages must start with a capital letter and be in the present tense (look at the commit log)
 
# Do not modify history older than 10 minutes
 
# Do not modify history older than 10 minutes
# Do not rush with anything, unless our user's data is about to be corrupted otherwise
 
 
# Use rebase, not merge, to get linear history. [3]
 
# Use rebase, not merge, to get linear history. [3]
 +
# Do not rush with anything, unless our users' data is about to be corrupted otherwise
  
 
==== Notes ====
 
==== Notes ====

Revision as of 14:58, 27 February 2015

This page is mostly directed to core developers with commit access to upstream repositories.

For instructions on basic usage, see Git.

For determining who is allowed to do what, see Organisation.

For guidelines about overall pull request quality, see Merging core pull requests to upstream.

Rules

Upstream branch rules

Freature freezes take effect in the master branch, and while the freeze is active, a separate development branch ("dev", or some other suitable name) is made into which pull requests are merged. It is then rebased onto master once the freeze is over. (It can be extended to be a more complete release model later, but this is the important part for now.) (https://forum.minetest.net/viewtopic.php?f=3&t=11172)

Note that 0.4.12 was freezed differently and the freeze will not be made in the same way in the future.

The minetest and minetest_game contain the stable-0.4 branch, which has to be updated to the latest stable 0.4 series version at each release.

Upstream pull requests and issues

  • If a pull request or an issue does not get a response from its author in one month (when requiring more details), it is closed.
  • If an issue is a duplicate, refer to the first one and close the later ones.
  • People considering merging pull requests are not required to look anything up anywhere else than the pull request and its comments. If there is something blocking the merging of a pull request, the reason must be added as a comment to the pull request. This goes both ways: If you check a pull request to be mergeable, write a simple "+1" comment to it.

Upstream commit rules

  1. You can push something to upstream [1] only if two members of the core team [2] or the subsystem maintainer agrees on it. (See Organisation.)
  2. Commit messages must start with a capital letter and be in the present tense (look at the commit log)
  3. Do not modify history older than 10 minutes
  4. Use rebase, not merge, to get linear history. [3]
  5. Do not rush with anything, unless our users' data is about to be corrupted otherwise

Notes

[1] Upstream is at https://github.com/minetest

[2] The team: https://github.com/minetest?tab=members

[3] For a github pull request, this is easiest done by appending .patch to the pull request URL, wgetting it to your project directory and doing git am whatever.patch. Similarly for single commits.