Em busca de um fluxo de trabalho Git melhor

Reuni algumas formas de usar o Git de maneira mais eficiente.

0. Estrutura do repositório
   • Git é um sistema de controle de versão distribuído, então pode ser organizado de várias formas, como centralizada, no estilo GitHub/GitLab, hierárquica etc.
1. Estrutura de branches
   • GitHub Flow: mantém a Main e cria branches de feature ou correção de bug, que depois são mescladas após receber feedback
   • Git Flow: mais adequado ao desenvolvimento tradicional do que a deploys frequentes
     • Cria-se uma branch de feature e ela é mesclada na branch Develop
     • Quando a branch Develop está madura o suficiente, cria-se uma branch Release (Stage), onde só se fazem correções de bugs, para depois mesclá-la em Develop e Master
     • Quando a release está pronta, ela é mesclada na branch Master, e dali em diante só entram hotfixes
   • GitLab Flow: uma forma intermediária entre o complexo Git Flow e o GitHub Flow simples demais
     • Em vez da branch Release, mantida temporariamente no Git Flow, usa-se uma branch Stage mantida continuamente
     • Hotfixes vão para Production e Stage, enquanto correções de bugs são aplicadas em Stage e Devlop
   • Perforce Stream: vantajoso quando é preciso gerenciar várias releases
     • Ao corrigir um bug em Release, a mudança é propagada para Main-Develop
     • Ao desenvolver uma funcionalidade em Develop, os conflitos são eliminados e a mudança é refletida em Main
   • Baseado em trunk: uma tentativa de usar Main (Master) de forma mais eficiente, adotada principalmente por big techs
     • Mantém-se a Main por bastante tempo, e não se fazem correções de bugs separadas nas branches de release
     • Funcionalidades são mescladas já em estado Off usando flags, para manter o código sempre atualizado
2. Commits
   • Convenção: normalmente a convenção do Angular é bastante usada, mas também é possível adotar emojis e outras formas por acordo da equipe
   • Granularidade: o ideal é commitar em unidades mínimas, mas isso também exige alinhamento da equipe sobre o que é uma unidade mínima
     • É possível detalhar as mudanças em hunks para fazer staging
     • É conveniente se for possível comparar mudanças em unidades de delta
   • Commits especulativos e histórico linear: uma forma de commitar com frequência para preservar o contexto sem perder um histórico linear
     • Sempre que for necessário salvar o trabalho, como com stash ou tentativas de protótipo, faz-se um salvamento
     • Faz-se checkout onde for necessário, continua-se commitando e depois usa-se rebase para manter o histórico linear
     • Fica mais fácil usando a ferramenta git-branchless
     • git sl: rastreia branches anônimas e visualiza bem o histórico de commits
     • git prev e git next: facilitam o checkout da unidade anterior/seguinte
     • git sync: faz rebase com a Main
     • git move: permite mover commits para onde você quiser
     • git restack: restaura a ordem do histórico quando ela é quebrada por rebase, commit --amend etc.
     • git undo: permite desfazer
3. Merge
   • Patch Stack: forma de revisar algo dividido em partes, como feature[1/3], feature[2/3], feature[3/3]
   • Conflitos de primeira classe: o Jujutsu, compatível com Git, registra conflitos no commit, então conflitos já resolvidos tendem a não reaparecer depois
   • 3 Way Diff: no caso do Jujusu, quando há conflito ele mostra Base-Ours como diff e Theirs como snapshot, o que é intuitivo. Porém, pode haver necessidade de ver destaque de sintaxe da IDE/editor ou um diff Base-Their
   • Conflitos binários: quando há conflito em arquivos binários, o Git basicamente deixa por sua conta; pessoalmente, foi criada uma ferramenta simples para gerar os arquivos Base e Their
   • Patches e e-mail: uma introdução a uma forma de merge mais tradicional(?)
     • git request-pull é um comando para gerar um pull request
     • Com git send-mail é possível enviar patches por e-mail, e com git am aplicar o patch
4. Outros métodos de gerenciamento
   • Worktree: com o histórico do Git compartilhado, é possível fazer checkout dos arquivos de trabalho em vários locais, como branches no SVN, e tocar vários trabalhos ao mesmo tempo
   • Git LFS: uma forma de gerenciar arquivos grandes
   • Clone parcial e checkout parcial: faz clone parcial para reduzir o tempo de download, e checkout parcial para trabalhar apenas no diretório desejado
   • Scalar: facilita o gerenciamento de repositórios enormes graças aos esforços da Microsoft