Fluxo de trabalho Git para desenvolvedor PHP: guia completo

Fluxo de trabalho Git para desenvolvedor PHP: do caos à organização (e de volta)

Você já fez push de código para a master numa sexta à noite, rezando para tudo dar certo? Ou já pisou no erro clássico do composer.lock, quando depois de um merge tudo quebrou? Bem-vindo ao clube. Git não é apenas um sistema de controle de versão, é o seu motor diário. Mas sem um fluxo de trabalho adequado, até o melhor código PHP vira uma abóbora.

Neste artigo, vamos analisar o fluxo de trabalho Git para desenvolvedores PHP que realmente funciona: desde a escolha da estratégia de ramificação até o deploy. Nada de enrolação, apenas código, exemplos e dicas práticas. Vamos nessa!

1. Escolhendo a estratégia: Git Flow vs. Trunk-Based

A discussão entre git flow e desenvolvimento trunk-based é mais longa que a história dos frameworks PHP. Mas para a maioria dos projetos PHP (especialmente os legados em Symfony/Laravel), o Git Flow continua sendo o padrão ouro. Por quê?

\n
• Isolamento claro de funcionalidades, releases e hotfixes.
\n
• Controle sobre o que vai para produção.
\n
• Trabalho com Composer — sem precisar fazer merge da dev a cada alteração.
\n

Mas se você tem microsserviços e CI/CD turbinado, o trunk-based também é uma opção. Vamos focar no clássico.

2. Feature Branch: seu playground

Cada nova funcionalidade — uma branch separada. O nome deve ser descritivo: feature/PROJ-123-add-payment-gateway. Nada de fix-bug ou new-stuff.

Exemplo de início:

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

Enquanto escreve o código, não se esqueça do Composer. Se adicionar uma nova dependência, faça commit do composer.json e composer.lock juntos. Isso salva seus colegas do "por que não funciona aqui?"

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Adiciona predis para cache"

Importante: não faça commit da pasta vendor/! Adicione-a ao .gitignore imediatamente.

3. Pull Request: code review sem dor

Quando a funcionalidade estiver pronta, crie um PR (ou MR no GitLab) para a branch develop. Aqui está uma checklist que salva os nervos do revisor:

\n
• ✅ Código passa no phpcs e phpstan (nível mínimo 6).
\n
• ✅ Testes escritos (PHPUnit, Pest).
\n
• ✅ composer.lock atualizado.
\n
• ✅ Sem conflitos com a develop.
\n

Exemplo de script CI (GitHub Actions):

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Instalar dependências\n        run: composer install --no-interaction --prefer-dist\n      - name: Executar PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Executar testes\n        run: vendor/bin/phpunit

Este fluxo de trabalho Git para desenvolvedores PHP automatiza a verificação do código antes mesmo de alguém olhar o PR. Mágico, não é?

4. Branch de release: preparação para produção

Quando houver funcionalidades suficientes para um release, crie a branch release/x.y.z a partir da develop. Aqui você corrige bugs, atualiza o changelog e incrementa a versão no composer.json.

git checkout -b release/1.2.0 develop\n# corrige bugs, atualiza versão\nvim composer.json  # altera "version": "1.2.0"\ngit commit -am "Atualiza versão para 1.2.0"\n# faz merge na master e develop\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Versão de release 1.2.0"\ngit push origin master --tags

Repare no --no-ff. Isso preserva o histórico de ramificações, para que você sempre saiba de onde veio o código.