It&#x27;s a perfectly defensible decision. The standard cryptographer&#x27;s reply at this point would be, what is your threat model?<p>If &quot;A developer could have their GitHub account broken into&quot; or &quot;Someone could break into GitHub deeply enough that they could access private repos&quot; are in your threat model, you shouldn&#x27;t be using GitHub at all for <i>anything</i>, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that&#x27;s not a useful threat model.<p>If &quot;You might do a git commit to remove them, then push the repo somewhere&quot; is in your threat model, then the answer is just &quot;Don&#x27;t do that&quot; (or more precisely, &quot;Make sure everyone on the team understands that can&#x27;t be done without precautions&quot;). The easiest way to don&#x27;t-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there&#x27;s going to be stuff in your git history you don&#x27;t want to be public (like, oh, git commit -m &quot;Implementing this stupid feature because this customer is stupid&quot;) because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit.<p>And the other part of the cryptographer&#x27;s reply is, where <i>else</i> are you going to store the secrets and what are its security properties?