You're viewing a single thread.
At my workplace, we have a lint rule that reports an error if
@nocommitis anywhere in the file, plus a commit hook that blocks all commits with@nocommitanywhere in them. It works well and has saved me a few times.Works pretty well, except the lint rule and its associated tests have to do something like
"@no"+"commit"to avoid triggering it,I did the same thing with "DO NOT MERGE" back in the day. Saved some people who didn't even know about the check.
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You can't even do that if the build is failing because of linting issues.
The test release shouldn't have anything marked with
@nocommitthough... The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.Are you committing to
master? I don't see any reason why you shouldn't commit your debugging code to your own branch. Obviously clean it up before mergingMy workplace uses feature flags rather than feature branches, and a continuous deployment cycle, so we only have one branch.