Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
At my workplace, we have a lint rule that reports an error if @nocommit is anywhere in the file, plus a commit hook that blocks all commits with @nocommit anywhere 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,
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 @nocommit though… 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 merging
At my workplace, we have a lint rule that reports an error if
@nocommit
is anywhere in the file, plus a commit hook that blocks all commits with@nocommit
anywhere 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
@nocommit
though… 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.