O trabalho em equipe nunca foi tão bem explorado quanto nesses tempos. Irei demonstrar um modelo de trabalho com o GIT baseado em Pull Requests e em boas práticas de desenvolvimento. Se você trabalha com GIT e deseja Trabalhar em grandes projetos ou contribuir para a comunidade, Chega mais!

Antes de começarmos

Para este tutorial é necessário que você possua conhecimentos básicos em GIT. Irei usar o exemplo do Bitbucket, mas nada o impede de utilizar outros serviços de repositório: a filosofia é a mesma. (Github, Gitlab, etc…) Basicamente utilizaremos o GIT, mas você pode basear se basear no conceito. Não entrarei em muitos detalhes técnicos, mas apenas o fluxo de trabalho em si. Dúvidas? Coloca nos comentários! Fique à vontade para dar sugestões.

O GIT com Pull Requests

Quando se desenvolve um projeto em equipe é interessante que todos consumam os dados de forma correta e que o repositório pertença à equipe. O Pull request é uma espécie de “envelope” contendo seus Commits. Este vira um “pedido de merge” que o dono do repositório recebe contendo um raio-x de tudo que foi alterado, removido, somado, etc. Nele, também, é o local de encontro para que os Desenvolvedores possam analisar seu código, opinar e deixar documentado seus pontos de vista. Muito bom quando se programa trabalhando com métodos ágeis. Garantir a excelência do código é fundamental para uma inteligência coletiva.

Fluxo de trabalho

De uma forma simples o processo consiste no seguinte;

1. Iniciando o processo

  • Faça um fork do repositório;

Tela com opção Menu para selecionar uma ação

Na tela do fork, Adicione informações que você ache pertinente para seu repositório. Como o repositório do exemplo é um privado, você pode determinar também se este pode ser “forkável” por outras pessoas.

Tela da opção do Fork Tela do Fork

  • Clone o repositório em sua pasta de trabalho;

Fork do repositório: progresso Progresso da clonagem: é rapidinho!

git clone git@bitbucket.org:joey_ribeiro/paymgate.git <pasta_do_projeto>;

Tela inicial do Fork Tela inicial do seu repositório “Forkado”

  • Adicione um remote chamado “upstream”. Este apontará para o repositório original;
git remote add upstream git@bitbucket.org:trilhus/paymgate.git;

Uma vez realizado o setup, vamos agora ao trabalho!

2. Ciclo de trabalho

Repita isso enquanto existir coisas pra fazer.

2.1 Faça o download das alterações mais recentes, vindas do servidor;

➜  paymgate git:(master) git pull --rebase upstream master
From bitbucket.org:trilhus/paymgate
 * branch            master     -> FETCH_HEAD
Current branch master is up to date.

OBS: O –rebase serve apenas para informar para o repositório não fazer o merge com os dados, mas baixar os commits do servidor primeiro, depois aplicar os patchs dos seus commits. O objetivo é garantir que o último commit seja o seu. (isso é uma boa prática. Vá por mim! rs)

2.2 Crie um novo branch com o a feature nova

Aqui você criará um branch novo por recurso.

➜  paymgate git:(master) git checkout -b card_32
Switched to a new branch 'card_32'
➜  paymgate git:(card_32)

É uma ótima prática nomear a branch pelo nome do cartão (caso do trello), ou id que identifique tal cartão, descrevendo o problema.

2.3 Trabalhe normalmente

Esta é a parte onde você faz os commits do seu código. É uma prática bastante interessante:

  • Utilizar pequenos commits, por recurso ou funcionalidade, por exemplo;
  • Colocar na descrição do commit realmente informações pertinentes. Não me venha com:
    • “Consertei a merda”;
    • “Porrada de ajuste”
    • Etc.

Uma vez feito seus commits, vamos enviar para seu Fork.

2.4 Faça o push de suas alterações para o repositório

Aqui você enviará o push para seu repositório (que é o remote origin, conforme padrão). No exemplo abaixo estamos enviando a branch card_32 para o nosso fork.

➜  paymgate git:(card_32) git push origin card_32
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 343 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@bitbucket.org:joey_ribeiro/paymgate.git
 * [new branch]      card_32 -> card_32

Tudo pronto para o Pull Request!

2.5 Vá até o site do seu repositório e crie um pull request

É nessa parte que você irá abrir a solicitação para mesclar o conteúdo do seus commits ao repositório padrão, fazendo com que todos os desenvolvedores façam parte do processo.

Menu para solicitar um Pull request Menu para solicitar um Pull Request

Nesse local você poderá adicionar comentários. Deixar marcado a opção close branch after pull request is merged é interessante, uma vez que você não irá mais precisar dessa branch no seu repositório, uma vez que o conteúdo será mesclado ao repositório master do projeto original. Perceba que você pode fazer pull requests entre branchs também.

Tela para criação de um Pull Request Tela para criação de um Pull Request

Coloque Revisores para analisar seu projeto. Digitar o nome deles faz com que eles recebem um e-mail pedindo a opinião. Nesse local você pode votar no PR, rejeitar ou efetuar o “merge” do mesmo. Também você pode comentar as linhas do código, dar dicas, efetuar críticas ou simplesmente explicar o porquê de ter rejeitado o seu PR.

Tela quando você abre um Pull Request Quando você “abre” um Pull Request

Adicionando comentários a linhas específicas de arquivos do Pull Request Adicionando comentários a linhas específicas do Pull Request

Comentário em cima de um trecho de código Comentário realizado em cima de um trecho de código

2.6 Caso tenha sido aprovado

Finish! Suas atualizações foram realizadas, documentadas. Finalize o cartão (movendo-o para o board concluído no trello, ou como você e sua equipe convencionou)

Sucesso no Pull Request Sucesso no Pull Request

2.6a Caso tenha sido rejeitado

Sem problemas. Volte para o branch que você estava trabalhando, adicione mais commits e gere um novo PR.

Conclusão

A grande sacada aqui é garantir que ninguém toque no repositório da equipe, enviando commits diretamente pra ele. Só assim você consegue criar uma escuta nesse repositório para que os builders vejam as modificações e façam o deploy em um ambiente de produção, testes, o que seja.

Através dos Pull requests você garante mais um canal de segurança e controle de seus projetos.