5. GITHUB

5.1 Commits

• Cada commit deve ser uma mudança lógica simples. Não faça várias mudanças lógicas em um commit. Por exemplo, se uma alteração corrige um bug e otimiza a performance de uma funcionalidade, o divida em dois commits separados.

• Não divida uma mudança lógica simples em vários commits. Por exemplo, a implementação de uma funcionalidade e os testes correspondentes à ela devem estar no mesmo commit.

• Commit cedo e frequentemente. Commits pequenos e autônomos são mais fáceis de entender e reverter quando algo dá errado.

• Commits devem ser ordenados logicamente. Por exemplo, se commit X depende de uma mudança feita no commit Y, então commit Y deve vir antes do commit X.

• Antes de enviar uma alteração para o repositório remoto garanta que as linhas alteradas no commit sejam referêntes ao que foi descrito no resumo do commit, para isso, se estiver usando o Visual Studio Code você pode verificar cada alteração feita no código desde o ultimo commit abrindo a terceira aba do menu lateral (View-> Git).

5.1.1 Mensagens

• Escreva o texto do commit sempre em inglês

• No inicio de cada commit faça resumos descritivos com no máximo 50 caracteres

• Faça commits referêntes a mudança e não em relação ao código por se só.

• Primeira letra do commit com letra maiúscula

Descrição

Use verbos indicando o que o código está trazendo de funcionalidade para o projeto

# Não recommendado
    git commit -m 'Adding Login Page'
    git commit -m 'Added Login Page'
    git commit -m 'Add Login function'

# Recomendado
    git commit -m 'Add Login Page'

5.2 Branches

• Escolha nomes curtos e descritivos:

  # bom
  $ git checkout -b oauth-migration
  
  # ruim - muito vago
  $ git checkout -b login_fix

• Identificadores correspondentes de tickets de um serviço externo (Ex. Issues do GitHub ) também são bons candidatos para usar em nomes de branches. Por exemplo:

  # GitHub Issue #15
  $ git checkout -b issue-15

• Use traços para separar palavras.

• Quando várias pessoas estão trabalhando na mesma funcionalidade, pode ser conveniente ter um branch de funcionalidade pessoal e um branch de funcionalidade para a equipe. Use a seguinte convenção de nomenclatura:

  $ git checkout -b feature-a/master # Branch da equipe
  $ git checkout -b feature-a/maria  # Branch pessoal da Maria
  $ git checkout -b feature-a/nick   # Branch pessoal do Nick

  Realizar o merge nos branchs pessoais para o branch da equipe (ver "Merging"). Eventualmente, o branch da equipe será integrado ao "master".

• Apague seu branch do upstream do repositório depois de integrado (a menos que haja uma razão específica para não fazê-lo).

  Dica: Use o seguinte comando quando estiver no "master" para listar os branches que foram feitos merge:

  $ git branch --merged | grep -v "\*"

Referências

https://medium.com/square-corner-blog/how-square-writes-commit-messages-8e92fcbf77c9

https://github.com/agis/git-style-guide