Ao trabalhar em uma equipe, um dos processos mais difíceis e mais envolvidos são as revisões de código. Para revisar uma grande solicitação de pull (PR), você precisa de tempo e contexto, bem como de energia para analisar e manter seus limites mentais em foco.
O mesmo não pode ser dito para pequenos PRs, no entanto, onde é muito mais fácil considerar mudanças e sugerir mudanças próprias. Então, como podemos introduzir grandes mudanças e, ao mesmo tempo, evitar sobrecarregar cognitivamente nossos colegas de equipe? É aqui que as solicitações pull empilhadas entram em jogo.
Neste artigo, vamos cobrir o que são solicitações pull empilhadas, quando e como usá-las e como converter um PR monolítico em empilhado.
O que são solicitações pull empilhadas?
PRs empilhados, também conhecidos como PRs dependentes, incrementais ou encadeados, são solicitações pull que se ramificam de outras solicitações pull. Nos termos do git , eles são branches de recursos que são retirados de outros branches de recursos para construir unidades pequenas e coerentes para representar as mudanças.
Ao trabalhar com PRs empilhados, é útil pensar em seus branches como uma camada semelhante de organização de mudança de código ao git commits. Você tem a escolha entre enviar todas as suas alterações como um único grande commit e organizar seu código em commits separados. Ter vários commits é a melhor prática. Então, de que adianta fazer o mesmo com suas filiais?
Quando e por que você deve usar PRs empilhados?
<✓TL;DR:
- Para dividir grandes PRs
- Para compartilhar um trecho de código entre vários ramos de recursos
- Para tornar mais fácil para duas pessoas trabalharem no mesmo recurso
Como afirmado anteriormente, os PRs empilhados são úteis quando se deseja dividir grandes solicitações pull. A outra situação em que os PRs empilhados realmente brilham é quando você deseja usar uma mudança específica em dois ou mais ramos.
Por exemplo, imagine querer migrar uma base de código para o TypeScript, onde você reescreve as páginas em TS enquanto seu colega de equipe reescreve os componentes. A configuração do TypeScript (instalação de dependência, tsconfig.json , etc.) teria que ser compartilhada entre vocês dois, quer comprometendo avidamente a configuração com o master (ou developers ) branch, ou empilhando seus PRs em cima de um branch de recursos ts-setup .
Isso permitiria que as duas ramificações, migrate-pages e migrate-components , compartilhassem a configuração do TypeScript em um relacionamento do tipo master com a ramificação ts-setup . Isso significa que se uma alteração ocorrer em ts-setup , migrate-pages terá que mesclar ou rebase ts-setup .
Se a migração da página depende da migração de componentes, você pode empilhar os ramos ainda mais.
Isso é especialmente útil quando duas pessoas estão tentando colaborar no mesmo recurso. Empilhar duas ramificações é mais fácil de lidar do que trabalhar na mesma ramificação.
Como empilhar solicitações pull
Para empilhar dois PRs, verifique o primeiro branch de seu master base (ou developers ) e envie suas alterações.
$ git status # estamos no mestre No mestre de filial $ git checkout-b ts-setup # checkout do mestre $ npm i-D typescript && npx tsc--init $ git add. && git commit-m'Setup TypeScript' $ git push-u origin ts-setup
No seu repositório GitHub, você será solicitado a criar uma solicitação pull de ts-setup :
Crie o PR com a base como master .
Em seguida, verifique o segundo branch do primeiro.
$ git status No branch ts-setup $ git checkout-b migrate-components # checkout from ts-setup $ mv components/Button.jsx components/Button.tsx $ git add. && git commit-m'botão Migrar para TS' $ git push-u origin migrate-components
Isso efetivamente transforma ts-setup e migrate-components em ramos empilhados prontos para se tornarem PRs empilhados.
Observe que, embora master seja definido como a base de nosso PR, as alterações de ts-setup (commit “Setup TypeScript”) estão presentes e nossa contagem de commits está às duas.
Alterar o branch base para ts-setup remove commits sobrepostos, trazendo nossa contagem de commits para apenas um.
Certifique-se de deixar claro que um PR está empilhado sobre outro. Um rótulo também pode ajudar.
O pior cenário é alguém mesclando um PR, puxando master , não encontrando as alterações e ficando confuso, o que levanta a questão, como você mescla PRs empilhados?
Como mesclar solicitações pull empilhadas
Eliminar, mesclar ou rebase?
A única restrição que você tem sobre a mesclagem ao trabalhar com PRs empilhados é que você não pode “esmagar e mesclar” ou “rebase e mesclar”. Você deve mesclar diretamente. Esta restrição não se aplica ao último PR em uma determinada cadeia de PR.
Isso se deve ao modo como a história do git funciona. Git rastreia mudanças por meio de commits por hashes de commit. Se você se lembra, mudar a base de master para ts-setup eliminou o compromisso comum entre ts-setup e migrate-components .
Git sabia fazer isso porque viu um commit com os mesmos metadados nos dois branches. A compressão e o rebasing substituem a história do Git (embora de maneiras diferentes), removendo a sobreposição que considerava os dois ramos contínuos.
Em que ordem devo mesclar?
TL; DR: Todos os pedidos são válidos. Depende de como você deseja que os commits de mesclagem apareçam no master .
A ordem em que devemos mesclar ou agrupar os PRs é totalmente subjetiva. Se fundirmos ts-setup com uma mensagem de confirmação de “Setup TypeScript” e excluirmos o ramo PR, o GitHub irá automaticamente pegar nisto e mudar a base de nossos migrate-components PR para master .
Isso nos dará a chance de mesclar com o mestre com uma mensagem de confirmação de mesclagem separada, “Migrar componentes para TS.”
Como alternativa, podemos primeiro mesclar migrate-components em ts-setup e, em seguida, mesclar ts-setup com master com uma única mensagem de confirmação de mesclagem para master de “Configurar e migrar componentes para TS.”
Dividindo um grande PR existente em uma pilha de PRs
Digamos que estejamos tentando mesclar um grande branch migrate-to-firebase com developers . O PR afeta dezenas de arquivos e provou ser difícil de revisar. Para dividi-lo em vários PRs, localmente, fazemos o seguinte:
$ git checkout migrate-to-firebase $ git reset--soft development $ git restore--staged.
Primeiro, verificamos o branch e depois descomprimimos todas as alterações que não existem no developers sem remover as próprias alterações. Isso resulta em todas as mudanças sendo testadas conforme indicado pelo git status , então nós as removemos executando git restore--staged .
Você pode renomear o branch para fornecer um relato preciso do que ele realmente faz executando:
$ git branch-M setup-firebase
Você pode então começar a adicionar, comprometer e verificar novos branches, formando uma corrente.
Usando PRs empilhados no Gitflow
Um dos problemas que você encontra ao usar o O fluxo de trabalho do Gitflow está sendo incapaz de empurrar seletivamente ramificações de recursos de desenvolver em uma determinada versão. Por exemplo, se você tiver um redesenho chegando no qual deseja trabalhar, mas não lançar ainda, você pode definir esse redesenho em um branch de recurso pai no qual os branches de recurso menores podem ser empilhados em cima e, em seguida, mesclar esse branch pai com desenvolver assim que terminar.
Conclusão
Neste artigo, aprendemos sobre PRs empilhados, por que e quando usá-los e como criá-los e mesclá-los. Também falamos sobre como eles podem aprimorar o fluxo de trabalho do Gitflow. Obrigado por ler!
A postagem Usando solicitações pull empilhadas no GitHub apareceu primeiro no LogRocket Blog .
