Experimente fazer cherry-pick de PRs do GitHub

• Já faz 4 meses que começamos a usar um mono-repository internamente
• Também estamos aplicando junto o trunk-based development, palavra-chave que sempre acompanha mono-repository
• Seguindo a estratégia de trunk-based development, usamos um fluxo em que fazemos commit na branch main e depois fazemos cherry-pick para a branch de release
• Montei uma GitHub Action com base no conteúdo do blog técnico do LinkedIn, mas ela não consegue resolver CONFLICT automaticamente. Quando ocorre CONFLICT, o usuário precisa executar manualmente o comando git cherry-pick no ambiente local
• Então criei eu mesmo um plugin do gh para ajudar com esse comando cherry-pick

Como usar

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• Com a opção -merge, é possível escolher se será feito cherry-pick do merge commit do PR ou dos commits originais do PR
  • Se não for especificado, ou se for usada a opção -merge=auto, a estratégia usada no merge do PR é inspecionada automaticamente e aplicada
• Com a opção -push, há suporte para fazer push automático para o remoto quando o cherry-pick for bem-sucedido

Impressões

• Ao desenvolver um programa que interage continuamente com processos e estados externos, criei um repositório de testes separado para gerar um conjunto de dados de teste
  • A experiência anterior contribuindo para os projetos libgit2 e refined-github ajudou bastante
• Vários estudos para melhorar a experiência de CLI
  • O estudo que fiz para tentar criar sozinho um docker-cli foi útil
• Criar um programa de CLI exige bem mais esforço do que eu imaginava
  • Gerenciar muitos valores de estado em um formato de pipeline
  • Fornecer uma interface de entrada intuitiva para o usuário
  • Fazer validação de entrada o mais cedo possível
  • Restaurar o sistema do usuário ao estado original, entre outras coisas..
  • Eu esperava conseguir fazer isso em cerca de um dia, mas levou aproximadamente 5 dias para ficar pronto (embora o desenvolvimento para melhorar o GitHub Actions Workflow tenha acontecido em paralelo, ainda assim levou muito mais tempo do que o esperado)

[qncnxnlrla]

Olá~ como vocês costumam lidar quando é necessário fazer revert de um commit que já foi mergeado na branch main(trunk)?

• Se fizer revert na branch main, também faz cherry-pick para a branch release?
• Em vez de usar revert, adiciona um commit de correção?

Como já há muitos commits acumulados, imagino que em alguns casos o cherry-pick possa ficar difícil por causa de conflitos; queria saber se vocês já passaram por casos assim e como lidaram com eles!

[a1eng0]

Olá~ obrigado por deixar um comentário!

Como vocês lidam com casos em que é necessário fazer revert de um commit que foi mergeado na branch main(trunk)?

No PR de revert aberto na branch main, especificamos o cherry-pick. Como todo o histórico de cherry-pick fica registrado no link do PR original, não há dificuldade para rastrear. Não fazemos nenhuma checagem mecânica separada haha

Quando há muitos commits acumulados e surgem conflitos, há casos em que o cherry-pick fica difícil

Em primeiro lugar, quando se adota trunk-based development, cada PR é pequeno, então conflitos não acontecem com frequência. Se houver conflito, aí é preciso escrever o código manualmente. Fazemos releases com bastante frequência para descontinuar rapidamente o suporte a versões muito antigas e evitar que a estrutura do código mude demais.

[lamanus]

Não entendo muito bem por que essa estratégia é necessária...

[a1eng0]

Se você ler o conteúdo apresentado em release-from-trunk, acho que pode ajudar a entender, haha