Philip Withnall philip.withnall@collabora.co.uk 2015 Controle de versão de código-fonte com git Rafael Fontenelle rafaelff@gnome.org 2017 Controle de versão Resumo

git é usado para controle de versão para todos os projetos do GNOME. Essa página presume que tenha um bom conhecimento em trabalhar com git; algum material introdutório está disponível aqui e um folha de dica está aqui.

Faça commits atômicos e reversíveis. ()

Inclua toda a fundamentação nas mensagens de commit, junto com links para especificações e relatórios de erros relevantes. ()

Mantenha alterações grandes, como renomeações, em commits separados. ()

Mescle alterações de ramos de recursos por meio de rebase. ()
Uso do Git

A maioria dos repositórios do GNOME seguem essas regras:

Nenhum push forçado. Exceto para ramos com o prefixo wip/ (trabalho em progress), o histórico de commits não deve ser modificado, pois contribuidores dependem dele.

Faça rebase nos commits em vez de merge, para ter um histórico linear (que é mais fácil de seguir).

Trabalhe em ramos de recursos no git do GNOME em ramos wip/ e então aplique rebase no master e merge em fast-foward nas alterações. Também é uma boa prática adicionar seu apelido ao nome do ramo, como wip/apelido/recurso.

Oculte “fazimento de salsicha” (do inglês, “sausage making”) compactando commits antes de mesclá-los.
Diretrizes para fazer commits

Commits devem ser tão pequenos quanto possível, mas não menores. Cada commit deve resolver um único problema, contendo apenas alterações relacionadas àquele problema. A mensagem para cada commit deve descrever o problema, explicar o que o causa e explicar como ele foi corrigido, se isso não foi óbvio. Se o commit está associado com um relatório de erro, a URI completa para o relatório de erro deve ser colocado em uma linha dedicada na parte inferior da mensagem de commit. Similarmente, o ID para o commit do git (do git log --oneline) deve ser compiado para o relatório de erro uma vez que o commit tenha sido enviado, com push, de forma que seja fácil localizar um por meio do outro.

As alterações em cada commit devem ser fáceis de ler. Por exemplo, eles não devem desnecessariamente alterar espaços em branco e recuo. Alterações grandes e mecânicas, tal como renomear um arquivo ou função, devem ser colocadas em commits separados das modificações do código dentro daquele arquivo ou função, de forma que as alterações posteriores não sejam enterradas ou perdidas na anterior.

Os princípios a seguir fundamentam todos os conselhos acima:

Cada commit deve levar o repositório a partir de um estado de trabalho para outro, do contrário bissecção é impossível.

Cada commit deve ser individualmente reversível. Se posteriormente o commit acabar sendo uma ideia ruim, git revert ID do commit deve levar o repositório de um estado de trabalho para outro.

A fundamentação de cada commit, e sua relação com recursos externos como especificações e relatórios de erro, deve estar clara de forma que aqueles commits escritos por um desenvolvedor no passado devem ainda ser entendíveis por um segundo desenvolvedor sem ter que seguir todo rastro de alterações e descobrir o que eles fazem.

Cada commit deve ser escrito uma vez e projetado para ser lido muitas vezes, por muitos revisores e futuros programadores.
Procedimento de mesclagem

Para mesclar um ramo de recursos chamado meu-ramo no master, use os seguintes comandos:

git checkout master git pull git checkout wip/meu-ramo git rebase --interactive master # Certifique-se que o rebase funcione com sucesso; teste as alterações git checkout master git merge wip/meu-ramo git push # wip/meu-ramo agora pode ser excluído git push origin :wip/meu-ramo git branch -D wip/meu-ramo