Working with git and github
Guidelines for comitting, branching and submitting pull requests when working on Desura:
- Choose a short but informative first line in every commit message, such as "module: short description."
- Changes should be verified as compiling and runnable before they are committed. If it becomes necessary to commit non-compileable code, place a note in the second line of the commit message (this will make git bisecting much easier).
- Be sure to thoroughly explain what you changes entail and why you made the choices you made. Don't rely on familiarity with the codebase to make your code understandable.
- Do not push to the master branch!
- Avoid pushing something to your local master. Keep it in sync via "git pull --rebase desura master" or a simliar git command.
- Create a new branch for every bugfix, feature or code cleanup. To help make your changes easier to review and understand, please keep your branch isolated to specific changes.
- You can use git cherry-pick to pull commits from other branches into the bugfix branch
- If you believe your branch is fully developed, you can create a pull request to merge your changes with the master branch (see below).
- For important development branches can be created in the lindenlab/desura-app repository. The above rules also apply when submitting pull requests to one of these branches ( eg: desura/Desurium/branch ). After development in the branch is completed, a pull request will be created against lindenlab/desura-app/master
A pull request against Desura is treated as an announcement that the author believes their changes are stable and ready to be merged (similar patch announcements in to mailing lists). At this point, the development community will discuss the changes and engage in testing. With no exceptions, untested pull requests will not be merged! This applies for critical bugs and trivial changes alike.
- Avoid merge commits, rebase instead.
- Create small, understandable commits rather than large indecipherable ones.
- Create test cases for every touched non-trivial function/method.
Note: The lindenlab CLA needs to be signed by the author before the pull request will be accepted
Trivial change: A single line change without effecting other lines in functions/methods, such as correcting typos, adding comments and simple single line refactoring.
Medium change: A change which does not impact on other functions/methods, such as bug fixes and code cleanups.
Big change: A change with effects in other functions/methods or changes the behaviour of Desurium, such as new features, fatal-bug-fixes, or anything else that can't be defined as medium or trivial.
trivial function/method: getter and setter or other simple assignments