Jonathan Machado
Todo mundo que trabalha com texto conhece esta pasta: proposta.docx, proposta-v2.docx, proposta-final.docx, proposta-final-REVISADA.docx, proposta-final-agora-vai.docx. E a pergunta que ninguém responde com segurança: qual é a boa, e o que exatamente mudou da terceira para a quarta?
Programadores tiveram esse problema antes de todo mundo, em escala maior, e resolveram de vez. A solução não é "salvar melhor". É separar o arquivo do histórico dele.
O que o versionamento resolve
Em um repositório, existe um único arquivo. O histórico de tudo o que já aconteceu com ele vive ao lado, e cada alteração fica registrada com autor, data, motivo e o exato conjunto de linhas modificadas.
Isso dá quatro capacidades que arquivo solto não dá. Você consegue ver a diferença entre duas versões, linha por linha. Consegue voltar a qualquer ponto do passado. Consegue trabalhar em paralelo em uma alteração experimental sem tocar na versão oficial. E consegue revisar antes de incorporar, com comentário na linha específica.
O GitHub é a plataforma que hospeda esses repositórios e adiciona a camada de colaboração: pedidos de alteração, revisão, tarefas, discussões e automações que rodam sozinhas quando algo muda.
O que dá para versionar além de código
Qualquer coisa que seja texto puro se beneficia integralmente.
Documentação e manuais. Procedimento operacional que muda com o tempo e precisa de histórico de quem mudou o quê.
Livros e cursos em escrita. Cada capítulo é um arquivo, cada revisão é um registro, e dá para comparar o antes e o depois de um trecho reescrito.
Base de conhecimento em texto. Notas em formato aberto ganham histórico, sincronização entre máquinas e cópia em nuvem, que é exatamente o arranjo descrito no artigo sobre o segundo cérebro em arquivos de texto.
Configuração de infraestrutura. Os arquivos que definem como o servidor está montado. Quando quebrar, você compara com a versão que funcionava, em vez de tentar lembrar.
Repositório privado e controle de acesso
Uma confusão comum: GitHub não significa público. Repositórios privados são o padrão para trabalho de empresa, com controle de quem acessa o quê, e a possibilidade de organizar tudo dentro de uma organização em vez de uma conta pessoal.
Esse detalhe importa pelo mesmo motivo descrito no artigo sobre arquivos que sobrevivem à saída de qualquer pessoa: o que pertence à organização não deveria depender da conta de um indivíduo.
O erro que anula o benefício
Registrar alterações sem explicar o motivo. Um histórico cheio de "ajustes", "correções" e "update" tem a mesma utilidade de não ter histórico, porque descobrir quando algo mudou continua exigindo leitura de tudo.
A regra que resolve: a mensagem de cada alteração deve responder por que, não o quê. O que mudou está visível na comparação. Por que mudou só existe na cabeça de quem fez, e é essa informação que vale dali a seis meses.
Quando não usar
Para arquivo binário grande e que muda com frequência (vídeo bruto, arquivos de diagramação pesados, imagens de alta resolução), o versionamento tradicional funciona mal e o repositório incha. Esse material vive melhor em armazenamento de arquivos, com organização e nomenclatura.
E não force a ferramenta em quem não escreve em texto puro. Para um time que trabalha em editor de texto tradicional, o custo de aprendizado supera o ganho, e o controle de versões do próprio editor resolve razoavelmente.
Onde ele entra no stack da eBuz
O GitHub guarda o que precisa de histórico auditável: código das aplicações, configuração de infraestrutura, base de conhecimento em texto e material editorial em produção. Ele é a memória de como as coisas chegaram ao estado atual.
Faz par com o servidor onde o código roda e com a base de conhecimento que ele versiona. Se você está começando a montar processo e quer saber o que documentar primeiro, comece pelo Mapa de Contexto.
Esta ferramenta faz parte do stack completo da eBuz: as 31 peças agrupadas por função, com a ordem certa de ligar cada uma.
