Integrando código com Git: Qual a melhor decisão?
O desenvolvimento de projetos de software tem como característica principal o desenvolvimento paralelo entre os desenvolvedores da equipe. Esse desenvolvimento colaborativo é essencial para o sucesso desses projetos. Isso é possível através de sistemas de controle de versão, os quais permitem o trabalho simultâneo de desenvolvedores nas equipes de projetos.
Um dos mais populares é o Git, que permite que os desenvolvedores compartilhem código de uma forma gerenciada sem fazer uso de um único repositório principal. No Git, desenvolvedores tem a liberdade de trabalharem em um repositório privado sem que suas alterações afetem obrigatoriamente terceiros. Dessa maneira, é possível controlar qual parte do código irá ser compartilhada, com que repositório e em que momento. Além disso, commits podem ser editados, reordenados ou deletados.
Cada mudança feita pelo desenvolvedor tem que ser integrada ao conteúdo do repositório central do projeto para se tornar visível ao restante dos contribuintes. Através da ferramenta Git, existem diversas maneiras de realizar uma integração de código entre um repositório local e o principal. Entre as opções, as mais populares são através dos comandos: merge, rebase ou cherry-pick. Embora o objetivo final seja o mesmo, esses comandos o alcançam de maneiras diferentes e é útil saber a diferença à medida que você se torna um desenvolvedor de software com mais experiência.
Qual é a melhor alternativa para você e seu time?
Em termos de perfomance, não existe uma única maneira que totalmente prevaleça sobre as demais alternativas. É necessário analisar a situação para escolher a que mais atende as necessidades, mas, para isso acontecer, precisa-se entender os benefícios dos comandos como também suas desvantagens.
Git Merge
O comando merge é responsável por incorporar modificações feitas por uma branch secundária na branch atual de trabalho. Isso significa que o Git vai replicar as mudanças ocorridas e registrar o resultado em um novo commit. Ao registrar este novo commit, o histórico da branch não permanece de maneira linear, tornando visível a ocorrência de integração de código. Isso acontece porque o novo commit gerado aponta para outros dois, um é o último commit da branch atual e o outro é o último commit da branch que contém as modificações.
Geralmente, esta prática é comum quando é criado um branch para realização de uma atividade complementar ao projeto, como implementar um novo requisito ou corrigir algum bug, e é necessário encontrar uma maneira de integrar o trabalho realizado pelo desenvolvedor ao repositório principal do projeto de maneira que não reescreva o seu histórico.
Vantagens:
- Preserva histórico completo e ordem cronológica
- Mantém o contexto da branch
- Simples
Desvantagens:
- O histórico pode se tornar poluído por muitos commits de mesclagem
- Debuggar o histórico do git pode ser tornar uma tarefa difícil
Git Rebase
O comando rebase serve como maneira alternativa de realizar o comando merge. Ele funciona da seguinte maneira, por exemplo: o desenvolvedor termina seu trabalho em um repositório secundário, mas percebe que novas mudanças foram feitas no repositório principal e deseja atualizar sua branch atual. Então, ao efetuar o comando rebase, a primeira ação do comando é incorporar as mudanças provenientes do repositório base e, em seguida, aplicar as modificações locais já feitas na branch atual como se fossem novos commits.
Ao contrário do comando merge, que gera um único commit adicional interligado as mudanças, a ação de rebase cria novos commits para cada commit da ramificação original. Dessa forma, o comando rebase reescreve o histórico do repositório para deixá-lo de maneira linear. A consequência do uso deste comando é não conseguir identificar quando as alterações foram incorporadas na funcionalidade.
O rebase é mais comum nas situações que o desenvolvedor não está compartilhando a branch atual de trabalho com ninguém. Dessa maneira, é mais aconselhado realizar o rebase a fim de manter seu histórico organizado e atualizado com a branch principal.
Vantagens:
- Simplifica um histórico complexo
- Evita um histórico poluído pelos commits de integração (merge)
- Permite uma manipulação mais fácil no histórico de commits (por exemplo, reverter commit, reordenar)
Desvantagens:
- Não mantém o histórico completo
- Trabalhoso
- Realizar o rebase em repositórios público pode ser perigoso quando se trabalha em equipe, principalmente se o desenvolvedor forçar o push logo após o rebase. (Iria sobreescrever o branch de outro membro da equipe, podendo perder qualquer trabalho em progresso)
Git Cherry-Pick
O cherry-pick é utilizado no Git como uma maneira de reaplicar mudanças de uma branch para outra. Pode-se dizer que este comando é uma forma de realizar rebase, mas com a limitação de aplicar um único commit por vez. O processo ocorre através da cópia do conteúdo pertencente ao commit de outra branch e, logo em seguida, é realizada uma tentativa de reaplicar o conteúdo copiado na branch atual. Por fim, é criado um novo commit para cada mudança introduzida na branch atual. O resultado da ação desse comando é uma história linear no repositório atual do desenvolvedor, sem deixar rastros que aquele commit foi de fato uma cópia de outro.
Em projetos de software, é bastante comum utilizar este comando para copiar comportamentos soluções válidas de uma branch para uma outra, como por exemplo: replicar a solução de um bug da versão atual do produto para uma versão mais antiga. Já que o cherry-pick é limitado a um commit por vez, é normalmente utilizado para pequenas mudanças.
Conclusão
Não é necessário escolher apenas uma abordagem e segui-lá fielmente. Com a prática, será mais natural a percepção de qual comando se encaixará melhor em determinadas situações. Mas, não se esqueça, se trabalhar em equipe é importante alinhar qual o fluxo de trabalho que irão adotar em relação a integração de código e ao Git.
