Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Git
Code

Focando no Trabalho em Equipe Com Git

by
Difficulty:BeginnerLength:ShortLanguages:
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Portuguese (Português) translation by Erick Patrick (you can also view the original English article)

O Git traz inúmeros benefícios para um desenvolvedor, mas também brilha quando se trata de colaboração em equipe.

A comunicação é a chave para criar um ótimo fluxo de trabalho em equipe com o Git. O Git é versátil, flexível e acomoda uma variedade de padrões de uso. Decidir de antemão as "regras de uso" para o fluxo de trabalho ajudará a eliminar problemas e confusões, e permitirá que a equipe aproveite o que o Git faz de melhor: aumentar a produtividade.

Dito isso, não teríamos um tutorial se esse artigo não provesse um fluxo de trabalho para equipes, baseado no Git e tangível, para você conhecer. O exemplo a seguir é baseado no famoso fluxo de trabalho com Git, criado por Vincent Driessen e chamado de Git-Flow, embora ele seja um pouco diferente em alguns aspectos chaves. Há inúmeros fluxos de trabalho disponíveis para o Git pela web—sugiro que você leia o máximo que puder e escolha o conjunto que melhor se encaixa em seu trabalho.

Comecemos sua pesquisa com o fluxo de trabalho a seguir:

A Regra Máxima

O ramo master sempre será publicável. Sempre.

Um ramo master publicável é importante por vários motivos. Primeiro, permite que qualquer pessoa nova no projeto possa obtê-lo e executá-lo sem erros, imediatamente. Nada é mais frustrante que não ser capaz de executar um projeto que não somos familiarizados.

Segundo, o master mostra o estado atual do código para produção ou do código lançado. Se ajustes precisarem ser feitos, fica claro de onde devemos criar novas ramificações.

Por último, um master publicável é retorno garantido. Se o master sempre for publicável, sempre poderemos publicar sem medo. Medo causa estresse e estresse causa indigestão. Ninguém precisa disso.

Estratégias de Ramificação

O ramo develop deve ser o principal ramo do desenvolvimento corrente. Ramificações de funcionalidades são criadas e fundidas de volta (merged) no ramo develop, e o ramo develop representa o estado mais avançado do código.

Uma vez que os ramos master e develop são permanentes e bastante trafegados, nunca se deve trabalhar diretamente neles. Ao invés disso, todo o trabalho deve ser realizado em ramificações de funcionalidades. Ao implementar uma nova funcionalidade, ramifique a partir do develop e crie o código que implementa a funcionalidade.

E O Que Tem o Nome?

Não há regras fixas para a nomeação de ramificações, principalmente para ramos de funcionalidades. Agora, se o ramo é de ajustes, é costume utilizar o prefixo "fix-". Se o ramo é de lançamento, geralmente é encorajado seguir o formato: "release-X.X.X".

No geral, nomes de ramos devem ser descritivos. Até divertidos. Uma piadinha ocasional e na hora certa, jamais será esquecida.

Você diz “Merge”, Eu digo “Rebase”

Assim que sua nova funcionalidade estiver codificada, é hora de colocá-la de volta ao ramo compartilhado (assumamos que fundiremos ao ramo develop). Mas, antes de fundir ao ramo develop, tenha certeza que sua ramificação possui as últimas atualizações do ramo develop, já que pode haver conflitos.

Todas as soluções de conflito devem ser realizadas na sua ramificação. Se você ramificou para realizar algum ajuste pequeno e não enviou para o ramo remoto, ajuste o ramo develop como a base da sua ramificação, usando rebase e, só então, funda-a com o ramo develop. Envie para o ramo remoto e sinta-se livre para apagar sua ramificação local.

Se tiver enviado sua ramificação para o ramo remoto, primeiro funda o ramo develop em sua ramificação (resolvendo os conflitos) e, depois, funda sua ramificação no ramo develop novamente. Envie para o ramo remoto e sinta-se livre para apagar sua ramificação local.

Ao usar o rebase, tenha em mente que é um comando destrutivo. Então, tenha cuidado! O rebase é bastante útil para limpar históricos de envio de códigos, mas não se quer reescrever o histórico de qualquer coisa que tenha sido compartilhado com outra pessoa.

Eis algumas regras para se ter em mente ao utilizar o rebase:

  • Nunca utilize rebase que tenha sido enviado para o ramo remoto. A ramificação que está trabalhando está somente local? Então é perfeito para usar o rebase. Caso contrário, não use rebase.
  • Use rebase com ramos compartilhados e ramificações locais. O ramo develop é um ramo compartilhado. A ramificação my-awesome-feature é local. Já estou pronto para fundir my-awesome-feature no ramo develop, mas quero ter certeza que todas as mudanças que surgiram no ramo develop sejam fundidas primeiro à minha ramificação:

Una-se A Um Amigo

Criamos a ramificação, codificamos a funcionalidade, fundimos/fizemos rebase do develop e estamos prontos para fundir nosso código de volta no develop. Mas, será que devemos mesmo? Talvez alguém devesse revisar nossas alterações primeiro...

Revisões de código são algo bom! Elas permitem você obter críticas bastante construtivas no trabalho que você fez e—se nada mais acontecer—aumentam a probabilidade de erros serem achados e ajustados.

É aqui onde as pull requests/requisições de envio do Git (e a interface do Bitbucket) são úteis (Para mais informações sobre abrir e administrar requisições de envio no Bitbucket, veja a segunda parte desta série, Usando Requisições de Envio e Revisões de Código). Requisições de envio servem muito mais que simplesmente para revisão de código. Uma vez que as requisições de envio são próprias para cada serviço, elas podem tornar-se tópicos próprios para discussão e colaboração de funcionalidades. Você pode embutir fotos para compartilhar projetos, comentar diretamente em linhas de código e até usar GIFs e emojis para descontrair um pouco.

Quando chega a hora de fundir a requisição de envio, é preferível que ela seja fundida pelo mesmo autor da requisição, que costuma ser a mesma pessoa que escreveu o código. Para que isso aconteça, os revisores devem deixar um comentário aprovando o código, mas sem apertar o botão de fundir. Uma vez que algum colega disser que o código está bom, através de um “sinal de ok” (seja figurativamente ou literalmente, através do emoji :thumbsup:), o responsável pela requisição pode fundir o código. Revisão de código e registros limpos—que coisa maravilhosa!

Eu Publico Muito, Muito!

Uma vez o ramo develop pronto para lançamento, funda-o ao ramo master:

Notou o semáforo --no-ff? Isso garantirá que a fundição não será do tipo fast-forward, isso é, não combinará os históricos, indicando que será um envio totalmente novo. Por que queremos isso? Para que possamos rotulá-lo (tag). Rotule o envio como uma nova versão:

E, então, funda o master de volta ao develop de modo que o ramo develop tenha o versionamento do envio.

Por falar em versões, deveríamos usar o versionamento semântico. Que seria algo como MAIOR.MENOR.ATUALIZAÇÃO (MAJOR.MINOR.PATCH). No geral, MAIOR é um número de versão totalmente novo—usado para mudanças muito grandes ou marcos. Aqui, é permitido criar código que não seja retro compatível. Menor é usado para novas funcionalidades. Não deveria quebrar a retrocompatibilidade. ATUALIZAÇÃO é para pequenas mudanças ou ajustes e nunca devem quebrar a retrocompatibilidade. Devemos manter nosso código em pré-lançamento (0.x.x) até que possamos lança-lo sem problemas.

Ajuste O Máximo Que Puder

Nunca deveríamos lançar erros.

...mas, quando fazemos, é melhor ajustá-los rápido. Uma vez que o ramo develop pode conter funcionalidades não finalizadas, ajustes devem ser feitos a partir do ramo do atual lançamento—que é o ramo master (uma vez que o ramo master sempre é publicável!).

Para realizar um ajuste, ramifique o master, crie o ajuste e funda sua atualização de forma não fast-forward no ramo master. Rotule-o, e funda o ramo master de volta no develop (já que queremos que o ramo develop tenha o ajuste também). Sinta-se livre para apagar o ramo do ajuste da sua máquina.

É Hora do Comprometimento

Falemos um pouco sobre o Git e as mensagens de envio de código. Aderir a um formato comum tornará a leitura dos registros muito mais fácil. Eis algumas boas regras:

  • Mensagens de envio de código devem ser escritas na forma imperativa: "Ajuste erro..." ao invés de "Erro ajustado..." ou "Ajusta erro...";
  • A primeira linha (ou linha do assunto) deve ser um resumo rápido do propósito do envio de código (preferivelmente, 50 caracteres ou menos) com a primeira letra da primeira palavra em maiúsculo;
  • Se o resumo precisar de mais conteúdo, você pode fazê-lo. Deixe uma linha em branco e escreva uma descrição completa. A descrição deve vir em formas de parágrafo, com pontuação, gramática e ortografia corretas;
  • As mensagens sobre os envios de código devem tomar, no máximo, 72 colunas, de modo que elas tenham uma boa aparência em nossas janelas de linha de comando.

Se quiser ler mais sobre uma escrita apropriada de mensagens para envio de código, veja o artigo de Tim Pope.

Personalize-o

Veja bem, o fluxo de trabalho mostrado acima serve como um guia, não como um conjunto fixo de regras a ser seguido estritamente por você e sua equipe. Se gostar de todas as regras, ótimo! Use-as. Agora, se algo não parece interessante, faça seus próprios ajustes! 

O mais importante é que sua equipe concorde com um fluxo de trabalho para o Git e se mantenha fiel a ele. Uma vez alcançado isso, colaboração aparecerá, e você aproveitará dos benefícios que o Git tem a oferecer para uma equipe.

Veja algumas alternativas ao fluxo de trabalho Git-Flow no guia de fluxos de trabalho para Git da Atlassian.

Seja o primeiro a saber sobre novas traduções–siga @tutsplus_pt no Twitter!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.