User Tools

Site Tools


contribution_guidelines

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
contribution_guidelines [2020/04/21 12:59]
be.ing [Core team]
contribution_guidelines [2020/04/22 22:46] (current)
be.ing [All contributors]
Line 4: Line 4:
   * Commits should be as small as they can while still building. The smaller the commit, the easier it is to review. It also makes it easier to revert if it is later identified as the source of a bug. If you have lots of changes that you need to commit, a [[https://​git-scm.com/​downloads/​guis|GUI Git client]] can be helpful for picking out specific changes for multiple small commits.   * Commits should be as small as they can while still building. The smaller the commit, the easier it is to review. It also makes it easier to revert if it is later identified as the source of a bug. If you have lots of changes that you need to commit, a [[https://​git-scm.com/​downloads/​guis|GUI Git client]] can be helpful for picking out specific changes for multiple small commits.
   * Every commit should build. This is important so [[https://​git-scm.com/​book/​en/​v2/​Git-Tools-Debugging-with-Git#​_binary_search|git bisect]] works.   * Every commit should build. This is important so [[https://​git-scm.com/​book/​en/​v2/​Git-Tools-Debugging-with-Git#​_binary_search|git bisect]] works.
 +  * Commit messages should succinctly describe what is changed in that commit and why. For example, this is a good commit message:
 +<​code>​
 +DlgPrefEffects:​ add QListWidget to set order of chains
 +
 +This order will soon be used by new ControlObjects to load them
 +from controllers.
 +</​code>​
 +The first line should be <= 50 characters and the body should line wrap at 72 characters. ​
 +This is not a good commit message:
 +<​code>​
 +address comments from PR review
 +</​code>​
 +Refer to [[https://​chris.beams.io/​posts/​git-commit/​|How to Write a Git Commit Message]] for more details.
   * Generally, prefer merging to rebasing. Do not rebase unless you have discussed that with whoever is reviewing the pull request. When you rebase a branch with an open pull request, prior review comments made inline in the code on GitHub lose their connection to that spot in the code. If you want to correct minor mistakes with a rebase or ''​git commit %%--%%amend''​ within a few minutes of pushing commits, that is okay as long as no one has started reviewing those commits yet.   * Generally, prefer merging to rebasing. Do not rebase unless you have discussed that with whoever is reviewing the pull request. When you rebase a branch with an open pull request, prior review comments made inline in the code on GitHub lose their connection to that spot in the code. If you want to correct minor mistakes with a rebase or ''​git commit %%--%%amend''​ within a few minutes of pushing commits, that is okay as long as no one has started reviewing those commits yet.
   * If you are helping with someone else's pull request that is not yet merged, open a pull request targeted at their fork. Leave a comment on the upstream pull request (which targets mixxxdj/​mixxx) with a link to your pull request so other Mixxx contributors are aware of your changes.   * If you are helping with someone else's pull request that is not yet merged, open a pull request targeted at their fork. Leave a comment on the upstream pull request (which targets mixxxdj/​mixxx) with a link to your pull request so other Mixxx contributors are aware of your changes.
contribution_guidelines.txt ยท Last modified: 2020/04/22 22:46 by be.ing