[[!meta title="Git merge policy: common rules"]]

## Documentation is not optional

When writing Tails code, one commits to adapt the design and end-user
documentations accordingly in a timely manner, writing brand new
chapters if needed.

### Design documentation

As a side note, best is generally to write specification and design
documentation before implementing changes; among other very valid
reasons to do so, it may avoid doing work that won't be applied ever,
or be reverted later, because of a faulty design that was reviewed and
diagnosed only when the implementation was up and running. On the
other hand, we're not great fans of over-engineering and we do know
proceeding like this is not always an option, as the right design
sometimes arises from erratic implementation attempts.

### User documentation

See our [[documentation guidelines|contribute/how/documentation/guidelines]].

Verify that your changes do not affect the rest of the user documentation and
FAQ. If so, fix it in your development branch so that it gets automatically
integrated when your branch get released.

Regarding the FAQ, don't write new questions in advance but make sure that the
existing ones are still correct.

## Test your code

A branch proposed for review and merge must have been tested when applied
against the target branch(es) of the requested merge.

## Do not break the build... or get reverted

Noone should ever push changes breaking the build into the shared Git
repository. On the other hand, this may happen since preliminary,
untested changes may in some circumstances land into our `devel`
branch to be reviewed and get more exposure.

If you find the `devel` branch in a non-building state and can
identify the root cause of it to a recent commit, fix it if you wish,
but don't let it disturb you otherwise: just revert the faulty commit
and inform the other developers on [[tails-dev@boum.org|about/contact#tails-dev]] so that the author knows
s/he needs to fix his/her stuff before reapplying it at a later point.
