No artigo anterior expliquei o que é um repositório: o arquivo onde vive o código do teu negócio, com um histórico de alterações e a possibilidade de recuperar versões anteriores. Agora, a pergunta seguinte é prática: como funciona tudo isto no dia a dia?
Vou usar o GitHub como exemplo porque é uma plataforma muito conhecida para guardar e gerir projectos de software. Os conceitos que vais encontrar também existem noutras plataformas, como GitLab e Bitbucket. Perceber o fluxo de trabalho é mais importante do que decorar os nomes de uma ferramenta.
O repositório: o armazém central do projeto
Um repositório no GitHub é o armazém central do código de um projeto, alojado na nuvem e acessível às pessoas com permissão. Pode conter os ficheiros do site ou da aplicação, documentação e o histórico das alterações.
A regra prática é simples: cada pessoa trabalha numa cópia do projeto no seu computador. Quando termina uma alteração, regista o trabalho e envia-o para o repositório central. Assim, várias pessoas podem contribuir sem estarem todas a mexer directamente nos mesmos ficheiros ao mesmo tempo.
É diferente de trocar anexos por email com nomes como documento_final_v7_joao_REV2.docx. Em vez de versões paralelas sem uma origem clara, há um repositório oficial e um registo das mudanças, com autoria e data.
Commit: uma alteração com recibo
Um commit é um registo de uma alteração ao código. Identifica quem a fez, quando foi feita e inclui uma breve descrição do que mudou. O histórico do projeto é, por isso, sobretudo um histórico de alterações, não apenas uma lista de ficheiros.
Pensa num commit como um recibo: mostra o que foi feito e permite localizar essa mudança no tempo. Se o programador enviar os commits para o GitHub, também os poderás consultar na plataforma. Em muitos casos, é possível comparar versões e ver que linhas foram acrescentadas, alteradas ou removidas.
Para o teu negócio, esse registo ajuda a responder a perguntas simples: quem alterou esta parte do site? Quando foi corrigido o formulário? O que mudou antes de surgir este problema?
As mensagens dos commits também dão sinais sobre a qualidade do processo. «Corrige validação do formulário» explica mais do que «ajustes finais». Não precisas de perceber o código para notar a diferença entre um histórico informativo e uma sequência de descrições vagas.
Branch: trabalhar numa linha separada
Uma branch é uma linha de trabalho paralela dentro do repositório. Parte de uma versão do projeto e permite desenvolver uma alteração sem mexer directamente na linha principal.
Por exemplo, se a equipa vai criar uma página de preços, pode trabalhar numa branch própria enquanto a versão actual do site continua intacta. Quando a alteração estiver pronta e revista, pode ser integrada na versão principal.
A analogia é preparar uma proposta num documento à parte, em vez de editar directamente um contrato já assinado. A versão aprovada fica como está enquanto a proposta é discutida.
A branch principal chama-se muitas vezes main. Pode ser a versão em produção ou a base para preparar a próxima versão, mas o nome, por si só, não garante que o site esteja actualizado. O importante é saber como o teu fornecedor usa essa branch e que controlos existem antes de lhe juntar alterações.
Pull request: uma proposta com revisão
Um pull request, ou PR, é uma proposta para juntar as alterações de uma branch a outra, normalmente à main. Na prática, é como dizer: «Preparei esta mudança. Eis o que fiz. Podes rever antes de a aprovares?»
A proposta reúne uma descrição do trabalho e uma comparação das alterações. Quem revê pode fazer perguntas, comentar partes específicas e pedir correcções. O programador pode responder com novas alterações antes de a proposta ser aceite.
Isto cria uma oportunidade de revisão antes de o trabalho chegar à versão principal. Não significa que o processo seja infalível, mas torna possível exigir um segundo olhar, em vez de depender apenas de uma conversa ou da memória de quem fez a alteração.
Um PR bem descrito também deve fazer sentido para ti: qual é o objectivo da mudança, que parte do site afecta e como foi verificada? Não precisas de avaliar cada linha de código para perceber se a proposta responde a um pedido concreto.
Issues: tarefas e problemas junto ao código
Uma issue é um registo de um problema, uma tarefa ou uma melhoria relacionada com o projeto. Pode ser algo como «o formulário de contacto não envia» ou «falta uma página com os preços».
A issue pode ter uma descrição, comentários, uma pessoa responsável e uma indicação do estado do trabalho. Também pode ser ligada à branch ou ao pull request que trata do pedido. Assim, fica um rasto: o que foi solicitado, quem trabalhou nisso e que alteração foi proposta.
Para o negócio, o valor é directo: as tarefas deixam de ficar dispersas por emails, mensagens e notas individuais. Se o teu fornecedor gere tudo por WhatsApp e email, mas mantém o GitHub apenas como arquivo de código, está a deixar de usar uma parte útil da plataforma.
Merge e conflitos: juntar alterações com cuidado
Quando um pull request é aceite, faz-se um merge: as alterações de uma branch são integradas noutra, por exemplo na main.
Às vezes, duas alterações mexem em partes incompatíveis do mesmo ficheiro. O Git identifica um conflito e pede que alguém decida o que deve ficar. É como dois editores alterarem o mesmo parágrafo de um contrato de formas diferentes: em vez de escolher às cegas, o sistema assinala a divergência para ser resolvida.
Um conflito não é, por si só, sinal de falha. É um aviso de que as alterações precisam de ser conciliadas antes de avançar. O importante é não resolver o problema à pressa, sem confirmar que o resultado continua a fazer o que o negócio precisa.
Fork: colaborar a partir de uma cópia
Um fork é uma cópia de um repositório criada noutra conta, mantendo uma ligação ao projeto original. É comum em projectos de código aberto: alguém copia o projeto, propõe uma melhoria e pode enviar um pull request para que os responsáveis pelo original decidam se a aceitam.
Um fork não significa automaticamente que alguém roubou o teu código. Mas também não elimina as questões de propriedade, acesso ou licença. Se o teu repositório for privado, só pessoas com acesso podem consultar o conteúdo; as possibilidades de criar forks dependem das permissões e das definições aplicadas.
Confirma três coisas: o repositório é público ou privado? Quem tem acesso? E quem é dono da conta ou organização onde o código está guardado? Estas perguntas são importantes quando termina a relação com um fornecedor ou muda quem mantém o site.
A segurança do negócio não deve depender apenas de esconder o código. Como expliquei no artigo sobre engenharia inversa de software, convém pensar também nos dados, nas permissões e na capacidade de manter e melhorar o produto.
GitHub Actions: controlos automáticos
As GitHub Actions permitem automatizar tarefas associadas ao repositório. Por exemplo, podem correr testes quando alguém abre um pull request, procurar erros conhecidos ou preparar uma nova versão do site.
Uma action, neste contexto, é um componente reutilizável que executa uma tarefa dentro de uma automatização. Pensa no controlo de qualidade de uma entrega: em vez de depender apenas de alguém se lembrar de verificar certos aspectos, alguns testes podem correr automaticamente sempre que há alterações.
Isto ajuda a detectar problemas antes de uma mudança ser integrada, mas não substitui a revisão humana nem garante que tudo funciona correctamente. As automatizações podem também consumir recursos. O GitHub inclui uma quantidade mensal de utilização nos seus planos para determinados repositórios privados; o limite e eventuais custos adicionais dependem do plano e do tipo de execução. Confirma sempre a página de faturação da conta. A utilização de runners standard em repositórios públicos tem condições diferentes, descritas na documentação de faturação do GitHub Actions.
O fluxo completo, sem precisares de programar
Imagina que o formulário do teu site precisa de uma correcção. Um fluxo de trabalho bem organizado pode ser assim:
- A equipa regista o problema numa issue.
- Um programador cria uma branch para trabalhar na correcção.
- Regista a alteração num ou mais commits.
- Abre um pull request para propor a integração na
main. - Outra pessoa revê a alteração e, se estiver configurado, correm verificações automáticas.
- Depois de aprovada, a alteração é integrada através de um merge. A issue pode então ser fechada.
Podes acompanhar o estado do trabalho sem ler código: ver o pedido, perceber quem está a tratar dele, consultar a descrição da proposta e confirmar se foi integrada.
O que deves perguntar à tua equipa técnica
Na próxima reunião, pergunta:
- Quem é o dono do repositório do meu site?
- Usam branches e pull requests ou alteram directamente a
main? - As tarefas e os problemas ficam registados em issues ou apenas em emails e mensagens?
- Quem revê as alterações antes de serem integradas?
- Quem tem acesso ao repositório e quando são esses acessos revistos?
Estas perguntas não exigem conhecimentos de programação. Exigem apenas que saibas onde está o activo digital do teu negócio e como o trabalho fica registado.
O GitHub, bem usado, junta o histórico das alterações, a separação do trabalho, a revisão, as tarefas e algumas verificações automáticas. O resultado é mais visibilidade sobre o que foi feito, por quem e com que propósito.
Se abrires agora o repositório do teu site, consegues ver o que mudou esta semana e quem propôs a alteração? Se nem sabes onde está o repositório, começa por essa pergunta.