Eu trabalho em uma equipe que usa git, onde mais de 40 desenvolvedores estão trabalhando em vários repositórios de código (mais de 100) em qualquer ponto do tempo. Também começamos com muito poucos desenvolvedores, aumentando o tamanho da equipe em alguns anos. No começo, porém, com poucas pessoas, você pode se dar ao luxo de conhecer apenas um mínimo de git. Com o tempo, você aprimorará seu git fu, descobrindo recursos poderosos.
- Você precisará de um local para hospedar seu código. Considere usar github ou gitorious . Ambos são gratuitos, mas seus repositórios serão públicos e visíveis para outros. Se você deseja repositórios particulares, você pode hospedá-los gratuitamente no github ou instalar e hospedar seu próprio servidor monitorado .
- No começo, é melhor não se preocupar com fluxos de trabalho avançados que envolvem solicitações de bifurcação e recebimento. Você pode começar usando o git de maneira centralizada (estremecer!). Trate sua cópia hospedada como a cópia autorizada do seu código-fonte. Vamos chamar esse repositório
upstream
.
- Um de vocês compromete todo o código em um repositório git local e o envia para este
upstream
repositório.
- O outro membro da equipe pode clonar este repositório.
- Um conjunto de comandos mínimos que você precisa aprender são
clone
, pull
, push
, add
, commit
, log
, status
, diff
, branch
, stash
, apply
, reset
, format-patch
, branch
. Saiba mais sobre eles no gittutorial .
- Agora você pode trabalhar em qualquer parte do código. Não se preocupe com o que acontece quando os dois editam o mesmo arquivo. O Git é realmente bom em lidar com fusões e corrigir conflitos.
- Faça pequenas confirmações atômicas e escreva boas mensagens de log . Use o tempo presente para logs de confirmação. Você pode fazer qualquer número de confirmações conforme desejar na sua cópia local, pois isso não afeta o trabalho da outra pessoa.
- Quando você achar que seu código está pronto para ser compartilhado com outras pessoas, publique-o no
upstream
repositório. Uma boa prática é sempre puxar antes de empurrar . Dessa forma, você mantém seu repositório sincronizado com outras alterações.
- Repita as etapas
7
e 8
.
Quando estiver confortável com esse fluxo de trabalho, você poderá progredir para itens mais avançados, como - ramificações tópicas, bifurcação, solicitações de recebimento, mesclagem, reestruturação interativa de confirmações etc.
Se você realmente deseja revisões de código, é possível apenas com git e email. Quando o tamanho da sua equipe cresce acima de 10 ou mais, isso é idealmente melhor com algum tipo de ferramenta on-line. Portanto, na prática, existem muitas maneiras de fazer isso, e esta é apenas uma maneira simples:
- Crie um conjunto de confirmações a serem revisadas com
git format-patch
. Isso irá gerar um conjunto de arquivos de patch. Envie esses patches por e-mail para o revisor.
- O revisor pode aplicar os patches com
git apply
. Isso aplica o patch, mas não cria uma confirmação.
- Revise o código e envie um e-mail com sugestões.
- Repita 1-2-3 até satisfatório.
- O revisor confirma que os patches podem ser enviados
upstream
.