O que um flow adiciona a branches e merges

Todas as ferramentas deste curso, já na sua mão

git checkout -b feature/x, git merge --no-ff, resolver um conflito, git rebase, abrir um pull request, fazer squash no merge: "Git branching", "Git merging" e "Pull requests" já ensinaram cada um desses, e você mesmo os rodou. Este curso não ensina nenhum deles de novo.

Esses cursos deixaram uma pergunta em aberto. Depois que você sabe criar uma branch e fazer o merge, quais branches deveriam existir? Que nome cada uma deveria ter? Que regra decide onde um trabalho começa e para onde ele volta no merge? Essa regra, aplicada do mesmo jeito pelo time inteiro, é o que "um fluxo" quer dizer. O Gitflow é uma resposta com nome para ela, e quer dizer mais que "usar branches".

Um antes e depois concreto

Sem um fluxo, a lista de branches de um time pode acabar assim, porque nada decidiu o contrário:

main
fix-login-bug
branch-do-joao
coisa-nova
really-fix-login-this-time

Cada uma dessas branches foi criada do jeito certo, com comandos que os cursos anteriores ensinaram. Os nomes não dizem que tipo de trabalho elas guardam, quando dá para apagá-las, nem de onde um hotfix deveria sair sob pressão. O Gitflow troca essa lista por cinco papéis, vistos na próxima aula, cada um com uma função.

O que este curso cobre

A aula 2 cobre os cinco papéis de branch do Gitflow, a partir da descrição original do modelo. A aula 3 mostra a ferramenta de linha de comando git-flow, que roda a sequência de checkout e merge que você já conhece. A aula 4 trata de branches de release e de hotfix, incluindo o único erro que traz de volta um bug que o Gitflow devia manter corrigido. A aula 5 cobre o GitHub Flow, a alternativa mais simples, e o que o próprio autor do Gitflow diz sobre quando preferi-la. A aula 6 checa o histórico de branches deste app para ver qual modelo ele segue, e a aula 7 passa tudo isso por um cenário final.

Onde isso deixa você

No fim, "qual fluxo?" deixa de ser questão de gosto e vira uma pergunta que dá para responder com fatos. O time entrega de forma contínua ou com calendário? A produção às vezes precisa de uma correção de emergência isolada enquanto uma feature grande ainda está em andamento? Respostas diferentes apontam para modelos diferentes.