Como alterar um repositório do GitHub de privado para público

Dicas profissionais: mudar um repositório do GitHub de privado para público

1. Avalie dados sensíveis antes de o tornar público
   Revise todo o seu repositório em busca de chaves de API, variáveis de ambiente, tokens de acesso, .env e documentação interna antes de alterar a visibilidade.

2. Verifique o histórico de commits, não apenas os ficheiros atuais
   Mesmo que os dados sensíveis sejam removidos da versão mais recente, podem ainda existir em commits anteriores. Use ferramentas de histórico do Git ou os alertas de análise de segredos do GitHub.

3. Atualize o README para utilizadores públicos
   Reescreva as notas internas numa documentação clara que explique o objetivo do projeto, os passos de configuração e a utilização por contribuidores externos.

4. Adicione uma licença antes de o tornar público
   Sem uma licença, os outros tecnicamente não podem usar legalmente o seu código. Escolha uma licença de código aberto adequada, como MIT, Apache 2.0 ou GPL.

5. Revise os colaboradores do repositório e as permissões
   Garanta que todos os colaboradores são adequados para um projeto público e remova qualquer pessoa que não deva manter acesso contínuo.

6. Ative as funcionalidades de segurança do GitHub
   Ative os alertas do Dependabot, a análise de código e a análise de segredos para proteger o repositório depois de se tornar público.

7. Crie um .gitignore se estiver em falta
   Impeça futuros commits acidentais de ficheiros sensíveis ou desnecessários, configurando corretamente o .gitignore.

Armadilhas comuns ao mudar um repositório do GitHub de privado para público

1. Expor credenciais acidentalmente
   Este é o erro mais comum e grave. Depois de público, os dados podem ser indexados, clonados e armazenados em cache rapidamente.

2. Assumir que os ficheiros eliminados desapareceram para sempre
   Os ficheiros eliminados ainda podem existir no histórico do Git, a menos que sejam removidos corretamente usando ferramentas que reescrevem o histórico.

3. Esquecer-se dos serviços associados
   Pipelines de CI/CD, fornecedores de serviços na nuvem e integrações de terceiros podem ainda referenciar o repositório depois de este se tornar público.

4. Sem licença incluída
   Um repositório público sem licença cria ambiguidade jurídica e limita a adoção.

5. Documentação deficiente para novos utilizadores
   READMEs apenas internos confundem utilizadores externos e reduzem o envolvimento ou as contribuições.

6. Ignorar as definições de issues e discussões
   Manter as issues ativas sem moderação pode levar a spam ou pedidos difíceis de gerir.

7. Alterar a visibilidade sem alinhamento das partes interessadas
   Para repositórios de equipas ou empresas, mudar para público sem aprovação pode causar problemas de conformidade ou de política.