(My) Guidelines to contribute to a repository Git

#dev, #git, #me

After working for 10 years and since the beginning using git, I’ve got many opinions. Yes, opinions. Things that I like or not or things that I believe are better for a repository and for the community (a company is also a community).

Protect master

Always protect master from git push directly. All the three more popular git hosting (Gitlab, Github, and Bitbucket) has some mechanism to protect the master branch.

master is unstable ALWAYS

Create a production or stable branch if you want to make sure that the stable code is in one branch.

You can even delete production as much as you can and cherry-pick (stable) commits into it. I saw this in one company, and it worked very well.

For real, let the developers play as much as they want with an unstable branch.

Oh, btw, don’t create branches that are subbranches of a more significant feature, that thing is more likely to get old, and many problems can happen 😐.

PR them all

I don’t have to explain this, but I’ve seen people not creating Pull Request while sharing code.

I don’t know why I can only guess: maybe someone is afraid of getting his or her code commented?

Also, don’t tell me that someone is not sending PR because he or she is afraid to push bad code into a branch. What can happen is the exact opposite because there is no review of one’s work.

Where the commit is from is not important

Branch name like 1234-something-logical-here is not relevant.

What if someone wants to work with a fork? Alternatively, the guy has his/her way of branching?

If you think that the name of a branch is important: open git log press space 7 times, find a commit that is not merge branch ‘xxx’ into ‘yyy’ or merge PR xxxx and show me where the first commit in yor screen came from 😉.

Seriously, what is important is the message of the commit.

Commit with the ID of the task

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"? Zoeira? Se você usa rebase them all você nunca vai ter conflitos, mas se você não usa pelo menos informe os arquivos que estão envolvidos.

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

Mesmo se você commitar com o principal funcionalidade da sua tarefa, escreva também o que aquela funcionalidade é. Por exemplo, ao invés de commitar Add merge feature, escreva algum que faça sentido:

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

Apenas merge feature é muito genérico e é bem provável que essa funcionalidade se repita.

Não bagunçe com a branch de outra pessoa (NUNCA)

Cara, é a minha branch, eu estou bagunçando com ela e escrevendo git commit -m "tmp commit" e usando git push -f.

Se você trabalha comigo e mandar algum código é bem provável que ele será perdido.

Sempre envie código para o master

Mesmo que o código não está pronto para produção sempre envie o código para a branch master.

Até agora eu só vi duas empresas criando branch para a principal funcionalidade, por exemplo merge-feature e outras pequenas branches com PR para essa branch principal.

Sério: não funciona, código pronto deveria ser enviado para a branch master.

Se é um código que só vai aparecer em 3 meses escreva algo como:

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

Ou, como eu prefiro:

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

Aqui estão várias opniões sobre como eu gosto de trabalhar e você ganha alguns bônus:

  1. Code review aumenta a qualidade de código e compartilha experiências (aka, nivela todo mundo);
  2. Proteger a branch master torna o código mais seguro para os desenvolvedores para saber o que está mudando;
  3. Enviar tudo para a branch master não deixa seu código ficar velho e você ainda não tem que aquela sensação: “Ah, o código tá naquela branch… como podemos mergear?”