1a vez trabalhando com git com time: tudo que você precisa saber

Mais de cinco anos que eu não abri um Pull Request ou tínhamos um issue técnico no Github, mas esta semana aprendi boas práticas e termos. Estou aqui para compartilhar tudo que eu precisei saber sobre trabalhar com Git em equipe.

Comecei atualizando o README de um projeto open source, o 4noobs da comunidade He4rt. Fiz ajustes simples como trocar um badge, organizar pastas e adicionar um índice. Não foi nada muito complexo, mas antes de começar, passei tempo nervoso pensando: "E se eu enviar diretamente para a branch principal e bagunçar tudo?"

Se você já sentiu esse medo antes de mexer em um repositório que não é seu, este artigo é pra você. Não importa se você é dev há anos ou nunca abriu terminal. A lógica por trás de contribuir sem quebrar nada é mais simples do que parece.

O Git colaborativo permite que times grandes interajam em um projeto de forma organizada. Ele resolve isso com branches que são cópias paralelas do projeto. Você pode mexer nesses branches sem afetar a versão oficial. Quando termina, envia as mudanças para o PR para revisão.

Aprendi que criar uma branch por contribuição não é burocracia. Isso garante que se algo errado acontecer, o erro fica isolado. O push só envia a branch pro GitHub. O PR é um passo separado.

Não precisa ter issue aberta para contribuir. Em documentação, uma contribuição já justifica. A descrição do PR deve ser um resumo categorizado, não uma lista linha por linha. A pasta .github pode ser local ou um padrão para a organização inteira.

O medo é o que geralmente impede nós de contribuir. Entender a ferramenta tira o poder do medo. Erros em público fazem parte do processo open source. Ninguém espera que você chegue sabendo tudo. As branches, PRs e revisões existem para que você aprenda e melhore. Comece a contribuir, mesmo com medo.