Difference between revisions of "Commit Policy"

From MNE-CPP Wiki
Jump to: navigation, search
(Created page with "# If you add new functions/classes ensure everything is documented properly. # All code should follow the Coding Conventions & Style. # Write new unit tests for the bugs you f...")
 
 
Line 3: Line 3:
 
# Write new unit tests for the bugs you fixed or functionality you added.
 
# Write new unit tests for the bugs you fixed or functionality you added.
 
# Commit often! In particular: Make atomic commits. This means that each commit should contain exactly one self-contained change - do not mix unrelated changes, and do not create inconsistent states. Never "hide" unrelated fixes in bigger commits.
 
# Commit often! In particular: Make atomic commits. This means that each commit should contain exactly one self-contained change - do not mix unrelated changes, and do not create inconsistent states. Never "hide" unrelated fixes in bigger commits.
# Use task related flags in front of each commit. I.e. if your task has the task tag MX-1 (see Scrum concept), put [MX-1] in front of the commit message.
+
# Use task related flags in front of each commit. I.e. if your task has the task tag SC-1, put [SC-1] in front of the commit message.
 
# Write descriptive commit messages. Make them self-contained, so people do not have to research the historical context to make sense of them.
 
# Write descriptive commit messages. Make them self-contained, so people do not have to research the historical context to make sense of them.
 
# And most importantly: use your brain :)
 
# And most importantly: use your brain :)

Latest revision as of 11:50, 18 January 2017

  1. If you add new functions/classes ensure everything is documented properly.
  2. All code should follow the Coding Conventions & Style.
  3. Write new unit tests for the bugs you fixed or functionality you added.
  4. Commit often! In particular: Make atomic commits. This means that each commit should contain exactly one self-contained change - do not mix unrelated changes, and do not create inconsistent states. Never "hide" unrelated fixes in bigger commits.
  5. Use task related flags in front of each commit. I.e. if your task has the task tag SC-1, put [SC-1] in front of the commit message.
  6. Write descriptive commit messages. Make them self-contained, so people do not have to research the historical context to make sense of them.
  7. And most importantly: use your brain :)