O Git é minha ferramenta preferida para controle de modificações em um diretório. Como toda ferramenta, ele tem algumas formas de uso. Que variam conforme o gosto e conhecimento. Neste texto, procuro expor como eu o uso e o que me motivou a usá-lo desta forma.

Eu uso o Git, porque é muito mais prático do que ficar criando vários diretórios do tipo:

• projeto.draft
• projeto.rascunho
• projeto_rascunho_final
• projeto_v1
• projeto_v2
• projeto_v3
• projeto_vFinal
• projeto_final_pra_valer
• projeto_final_agora_vai
• projeto_final_mesmo
• …

A questão é tão particular, e interessante, que quando alguém resolveu descrever um fluxo de trabalho, teve resposta de gente grande apresentando os delas, como o GitHub flow e o Atlassian git-flow.

A parada é tão séria que chegou a gerar uma ferramenta que implementa um fluxo. E, o assunto ainda não tem um consenso. Tanto que tem gente falando disso até hoje, mais de 3 anos depois do “A successful Git branching model”…

Não tenho a pretensão de mudar a forma de trabalho dos outros, mas dar um guia para quem está começando.

O espírito do fluxo

Meu fluxo de trabalho com o Git é guiados pelas seguintes linhas:

• Menor quantidade de comandos - Pois é… Tenho dificuldade para decorar. Portanto, quanto menor a quantidade de coisas a lembrar, mais facilita o meu aprendizado;
• Menor quantidade de fluxos - Se eu tenho dificuldade com comandos simples, imagine lembrar as ordens deles e quando usar. Portanto, quanto menos passos, a serem seguidos, espero que seja mais simples de lembrar.

Como eu costumo usar o Git

• git clone
• git add .
• git commit -m ‘'
• git pull –rebase
• git push

Ao começar a trabalhar em uma tarefa, eu sigo o seguinte fluxo:

1. Atualizo minha cópia local, com as alterações do Time
2. Faço commits em que as alterações estejam associadas
3. Quanto termino minha tarefa, compartilho as minhas alterações com o Time

Atualizo minha cópia local, com as alterações do Time

Procuro trabalhar sempre com a versão mais atual do projeto. Sendo assim, a primeira coisa a fazer, é ter certeza de que estou com a última versão, compatilhada do projeto, pelo Time.

Para isso uso o seguinte comando:

$ git pull --rebase

Assim, caso eu tenha algum commit que tenha esquecido de publicar, ele será aplicado acima dos commits que já estão publicados. Mantendo a timeline mais limpinha.

Faço commits, somente, com as alterações que estejam associadas

Gosto da idéia de tratar o log do git como uma timeline que conta a história do projeto.

Para isso os commits precisam ter, somente, alterações que estejam relacionadas entre si.

Para avaliar se as alterações fazem sentido estarem no mesmo commit, observe se seria apropriado fazer uma lista de tópicos na mensgem do commit. Os casos positivos, indicam que você pode estar fazendo modificações demais em um mesmo commit.

Uma forma de ajudar é seguir o fluxo: Red-Green-Refactor, do TDD. Exemplo de correção de um bug, usando esse fluxo.

1. RED: Escreve o teste e garante que ele está falhando;
2. GREEN: Escreve o mínimo de código que permita passar no teste;
3. REFACTOR: Remove duplicações e melhora a legibilidade do código;
4. COMMIT: Grava a versão no git.

Ainda na questão de ter uma timeline do projeto, temos outro requisito: minhas mensagens devem descrevem o que levou a alteração, não o que foi alterado.

Por exemplo, prefiro:

$ git commit -m 'Impede o cadastro de usuário sem email.'

Ao, invés de:

$ git commit -m 'Adiciona validates email, presence: true no model user.'

Quanto termino minha tarefa, compartilho as minhas alterações com o Time

Aqui não tem mistério:

$ git push

Mantenha-se seu código atualizado em relação ao Time.

A cada commit é interessante que seja feita uma atualização com o que o Time andou publicando, para diminuir a quantidade de merges.

Merge é o processo de juntar alterações feitas por você com as feitas por outra pessoa no mesmo arquivo.

Faço isso a cada commit, para manter pequena a quantidade de alterações que precisem de um merge.

UPDATE Descobri que isso se chama Centralized Workflow