(Minhas) Guidelines para contribuir para um repositório Git

• #dev #git #me

Após trabalhar por 10 anos e desde o começo usando git, eu tenho muitas opniões. Sim, opniões. O que acho bom fazer ou não para um repositório de uma comunidade (uma empresa também é uma comunidade).

Proteja a branch main

Sempre proteja a branch main de git push diretamente, seja ele --force ou não. Todos os três maiores serviços de hospedagem git (Gitlab, Github, and Bitbucket) permitem que você faça isso.

main é instável SEMPRE

Se você quiser código estável crie uma branch production ou stable.

Você pode até apagar a branch production ou stable o quanto quiser e fazer cherry-pick de commits, vi isso acontecer uma empresa e funcionou muito bem, obrigado.

Sério, deixe os desenvolvedores fazerem o que quiserem com uma branch instable.

Ah, a propósito, não crie branches que são subbranches de uma funcionalidade maior, é mais fácil ver o código ficar velho.

PR them all

Certamente eu não tenho que explicar isso, mas acabei de ver gente não criando PR para enviar código.

Não faço ideia do porquê disso, posso apenas pensar sobre: talvez a pessoa ficou com medo de alguém ver o código dele(a).

Não me diga que alguém não quer enviar PR por estar com medo de enviar código ruim. Por que o que acontece é justamente o contrário.

De onde esse commit veio não é importante

Determinar um nome de branch não é importante, forçar todos a seguir o mesmo padrão, por exemplo 1234-something-logical-here, só vai fazer com quem não gosta daquele padrão mais frustado. Não forçe a barra.

Além do mais, e se alguém quiser usar um fork? Ou, e se o desenvolvedor tem o seu próprio jeito de nomear branches?

Se você realmente pensa que nome de branch é importante: executa git log aperta espaço 7 vezes, procure um commit que não seja merge branch ‘xxx’ into ‘yyy’ ou merge PR xxxx e me mostra de onde o primeiro commit na sua tela veio (tarefa ou branch) 😉.

Sério, o que é mais importante é a mensagem de commit.

Faça commits com a ID da tarefa

Commitar com a ID da tarefa é uma adição da anterior. Uma mensagem de commit deve ser complete por si mesma, porém muitas vezes uma tarefa não pode ser concluída num único commit.

git commit -m "Fix conflicts"? Primeiro que deveria usar rebase them all para não ter que criar esse tipo de commit, mas se você não está pelo menos diga qual arquito que teve conflito:

$ git commit -m "Fix conflicts in app/models/category and app/services/category_builder"

Ok, mesmo se o projeto tiver um nome para a funcionalidade que estiver trabalhando, descreva ao invés de dizer que Add feature. Exemplo: ao invés de dizer Add category merge, diga, Add ability to merge categories (including subcategories).

$ git commit -m "Add the ability to merge category and subcategory." -m "[#1234]"

Apenas Add feature or Add merge feature é muito genérico, talvez depois dessa funcionalidade pronto outra merge feature pode ser feita que envolva outros objetos.

Não mande commits para a branch de outra pessoa (NUNCA)

Cara, é a minha branch. Eu bagunço muito, as vezes crio commits temporários (git commit -m "temporary commit") e em outras eu faço um git push -f.

Se você trabalha comigo e não fala para, existe um grande risco de perder o que você fez.

Sempre mande código para a branch main

Mesmo se o código não for production-ready sempre mande para a branch main.

Eu conheço duas empresas que criam branches para a funcionalidade principal e outras branches pequenas para os PRs que vão juntos nessa funcionalidade.

Sério: não funciona, é melhor mandar o código de primeira para a branch main.

Se for um código que ainda está em andamento e só ficará pronto daqui a 3 meses, ou várias funcionalidades serão entregas juntas, faça algo como:

unless Rails.env.production?
  # The super feature that I love here
end

Or

if ENV.fetch("ENABLE_MERGE_FEATURE", false)
  # The super feature that I love here
end

–

É muita opinião para um post só, mas esse é o jeito que gosto de trabalhar, alguns pontos bônus:

  1. Code review aumenta a qualidade e compartilha experiência
  2. Proteger a branch main ajuda os programadores a não cometer erros (git push -f :/ )
  3. Mandar tudo para a branch main faz com que o código não fique antigo e evita o sentimento de “ah, mas o código está naquela outra branch… pode fazer o merge agora? Mas tem que resolver conflito”