O que é GitHub e por que o dono do site precisa saber

Se você contrata desenvolvimento — site, sistema, loja — a palavra GitHub já apareceu em alguma conversa. Provavelmente ninguém parou para explicar, e você seguiu adiante fingindo que entendeu. É mais comum do que parece: até quem trabalha na área tem dificuldade de explicar em uma frase.

Este texto é essa explicação, escrita para quem paga a conta e não para quem escreve o código.

O que é, em uma frase#

GitHub é onde o código do seu site fica guardado, com o histórico de toda alteração já feita, quem fez e quando.

Pense no histórico de versões do Google Docs. Você escreve, alguém revisa, e a qualquer momento dá para ver o que mudou e voltar atrás. O GitHub é isso para código — só que feito para várias pessoas trabalharem no mesmo projeto sem passar por cima do trabalho uma da outra.

Git e GitHub não são a mesma coisa#

O Git é o sistema que registra as versões, criado em 2005 e usado por praticamente todo mundo que programa. O GitHub é uma empresa que hospeda projetos que usam Git, hoje pertencente à Microsoft. Existem concorrentes — GitLab e Bitbucket são os mais conhecidos — e a ideia é a mesma.

Na prática as pessoas usam "GitHub" como sinônimo de "onde o código mora". Para a conversa que interessa aqui, tudo bem.

Por que isso é problema seu, e não só do desenvolvedor#

Aqui está a razão de um dono de negócio precisar entender isso, e ela é bem concreta.

Quando alguém desenvolve seu site, o resultado existe em dois lugares diferentes: o site publicado, que os visitantes acessam, e o código-fonte, que é a receita para reconstruir e alterar aquilo. Ter acesso ao servidor não é a mesma coisa que ter o código — assim como ter o bolo não é ter a receita.

Se o código está num repositório em nome da sua empresa, trocar de fornecedor é uma conversa desconfortável e nada mais. Se está apenas na máquina do desenvolvedor que sumiu, você tem um site que ninguém consegue alterar — e a saída costuma ser refazer do zero.

Não é situação rara. É uma das razões mais comuns pelas quais uma empresa nos procura para refazer um site que estava funcionando.

O que pedir, em português#

1. Que o repositório fique numa conta da sua empresa, não na conta pessoal de quem desenvolve.
2. Que você tenha acesso de dono a essa conta, mesmo sem nunca abrir.
3. Que o desenvolvedor entre como colaborador, e não o contrário.

São três frases numa reunião. Um profissional sério não cria caso com nenhuma delas — se criar, isso por si já é informação.

As tais chaves e senhas#

Todo site tem segredos: a senha do banco de dados, a chave que conecta ao meio de pagamento, o token que integra com o WhatsApp. Existe uma confusão muito comum aqui, e ela custa caro.

O código em si nunca deveria conter essas chaves escritas. É o erro clássico: alguém deixa a senha dentro do arquivo, o repositório fica público por descuido, e robôs que varrem o GitHub encontram a chave em minutos. Acontece todo dia.

O GitHub tem um cofre separado para isso, chamado Secrets. As chaves ficam guardadas lá, o código apenas pede por elas na hora de rodar, e ninguém que olhe o código consegue lê-las. Se o seu projeto tem senha escrita dentro de arquivo, isso é dívida a pagar — independentemente de o repositório ser privado, porque privado hoje não garante privado para sempre.

As automações#

O GitHub também executa tarefas sozinho quando algo acontece — o recurso se chama Actions. É o que faz, por exemplo, o site ser publicado automaticamente assim que uma alteração é aprovada, sem ninguém subir arquivo à mão.

Para você isso significa duas coisas. A publicação deixa de depender de alguém lembrar de um passo, que é onde erro humano entra. E fica registrado o que foi publicado e quando — útil no dia em que algo quebra e a pergunta é "o que mudou?".

Por que o GitHub cresceu tanto com a IA#

Não é impressão sua. Duas coisas aconteceram ao mesmo tempo.

A primeira: as ferramentas de IA que geram código sincronizam com o GitHub. O Lovable faz isso, e os assistentes de programação também. O repositório virou o ponto de encontro entre o que a IA escreveu e o que a pessoa ajustou.

A segunda, mais importante para quem contrata: quando a IA escreve boa parte do código, o histórico de versões deixa de ser conforto e vira necessidade. Uma alteração automática que quebra algo precisa ser desfeita em segundos, e é exatamente para isso que o Git existe desde 2005. A IA não tornou o controle de versão obsoleto — tornou indispensável.

Preciso pagar?#

Provavelmente não. O plano gratuito do GitHub inclui repositórios privados ilimitados e 2.000 minutos de automação por mês, o que cobre com folga o site de uma empresa comum. Os planos pagos começam em torno de 4 dólares por pessoa ao mês e servem a equipes com necessidade de controle de acesso mais fino.

Ou seja: não ter o código num repositório da sua empresa não é uma questão de custo. É de organização.

O mínimo que vale saber#

• O código do seu site é um ativo da empresa, como o domínio. Trate igual.
• Repositório na conta da empresa, desenvolvedor como colaborador. Nunca o contrário.
• Senha e chave não moram dentro do código.
• Se você usa ferramenta de IA para construir, ligue a sincronização com o GitHub no primeiro dia.

Você não precisa saber usar o GitHub. Precisa saber que ele existe, que o que está lá é seu, e que a pergunta "onde está o código?" tem que ter resposta antes de você precisar dela.