-
Notifications
You must be signed in to change notification settings - Fork 813
Submitting code
Avoid changing too many things at once, for instance if you're fixing the redis integration and at the same time shipping a dogstatsd improvement, it makes reviewing harder (devs specialize in different parts of the code) and the change time-to-release longer.
Every commit should lead to a valid code, at least a code in a better state than before. That means that every revision should be able to pass unit and integration tests ([more about testing](Submitting code#testing))
An example of something which breaks bisectability:
- commit 1: Added check X
- commit 2: forgot column
- commit 3: fix typo
To avoid that, please rebase your changes and create valid commits. It keeps history cleaner and it's easier to revert things and it makes developers happier too.
Never use git commit -m "Fixed stuff", it usually means that you will just write the very first thing that comes to mind without much thought.
Instead, the commit shortlog should focus on describing the change in a sane way (you can add a [flag] as in this other naming convention and be short (72 columns is best).
The commit message should describe the reason for the change and extra details that will allow someone later on to understand in 5 seconds the same thing you've been working on for a day.
If your commit is only shipping documentation changes or example files, and is a complete no-op for the test suite, please add [skip ci] in the commit message body to skip the build and let you build slot to someone else in need 😉
Examples, see:
- https://github.com/DataDog/dd-agent/commit/44bc927aaaf2925ef081768b5888bbb20a5bb3bd
- https://github.com/DataDog/dd-agent/commit/677417fe12b1914e4322ac2c1fd1645cb0f1de31
- and if you like extremism, this is for you
When you are ready to submit your changes, submit a pull request.
It's a good habit to run all tests locally before creating the pull request, because our CI builder will first try to run the tests and we'll try hard to merge the PR only if the build succeds.
Please try to summarize with a good title and a message describing your change (or Github will also copy the commit message for you) and cross-reference any opened bugs on the matter.