A colleague of mine told me that he is thinking in making our CI server to revert commits that failed the build, so the
master is always stable (as in passing the build at least).
Is this a best practice or it may be more problematic than just leaving
master broken until the developer fixes it?
My thinking is that reverting the commit will make more complex the task of readding the commit and fix (developer will have to revert the revert and then commit the fix, which will also clutter the
git log) and we should just leave the commit and then commit the fix. Although I see some advantages in having
master stable, this revert of failing commits does not convince me.
edit: Doesn't matter if it is
master or any other development branch, but the question stays the same: should the CI system revert a commit that failed the build?
another (lenghty) edit: Ok, we're using
git in a strange way. We believe that the concept of branches goes against real CI, because committing to a branch isolates you from the other developers and their changes, and adds time when you have to reintegrate your branch and deal with possible conflicts. If everyone commits to
master this conflicts are reduced to the minimum and every commit passes all tests.
Of course, this forces you to push only stable (or you break the build) and program more carefully to not break backwards compatibility or do feature-toggling when introducing new features.
There are tradeoffs when doing CI this or that way, but that is out of the scope of question (see related question for this). If you prefer, I may reword the question: a small team of developers work together in a feature branch. If one developer commits something that breaks the build for that branch, should the CI system revert the commit or not?