PT
RU
EN
ES
ZH
FR
DE
AR
HI
Fluxo de trabalho Git para desenvolvedores Swift: como não enlouquecer e não quebrar a produção
Admita honestamente: quantas vezes você viu um commit com a mensagem "correção" ou "ajustes" no branch principal? E quantas vezes um conflito de merge tomou uma hora da sua vida porque alguém esqueceu de dar pull antes do commit? Se você é um desenvolvedor Swift trabalhando em equipe — desde um projeto hobby até um aplicativo grande no nível "Tinkoff" ou "Yandex.Maps" — mais cedo ou mais tarde você enfrentará o caos no Git.
A boa notícia: um fluxo de trabalho Git correto para desenvolvedores Swift transforma o repositório de um campo de batalha em um sistema organizado. Neste artigo, vamos analisar quais abordagens realmente funcionam para projetos iOS e macOS, como configurar um code review sem dor e por que o CI/CD deve estar integrado ao seu processo desde o primeiro dia.
Vamos nessa!
1. Por que o fluxo de trabalho Git padrão frequentemente quebra no Swift
Projetos Swift têm suas particularidades: projetos Xcode, storyboards (ou SwiftUI), dependências Podfile/SPM, além de assets binários (imagens, fontes). Se em um projeto web comum um conflito de merge é resolvido em 30 segundos, no iOS pode levar meia hora por causa do .xcodeproj ou .xcworkspace.
Os principais problemas que um fluxo de trabalho Git competente para desenvolvedores Swift resolve:
- Conflitos no .xcodeproj — ao adicionar arquivos por dois desenvolvedores simultaneamente;
- Histórico de commits sujo — "WIP", "ajustes", "mais ajustes";
- Falta de code review — bugs que vão para o main e quebram a build;
- CI quebrado — testes não passam, e ninguém percebe até o lançamento.
2. Git Flow vs GitHub Flow: o que escolher para um projeto Swift?
O clássico Git Flow (branches develop, release, hotfix, feature) é uma abordagem poderosa, mas pesada. É ideal para projetos grandes com ciclos de lançamento claros, por exemplo, quando você desenvolve um aplicativo para um banco com versões 1.0, 1.1, 2.0 e um QA rigoroso.
Por outro lado, o GitHub Flow (todas as alterações através de feature branches e Pull Request para o main) é uma opção leve para startups e equipes que fazem deploy todos os dias. Para projetos Swift, também funciona, mas com ressalvas: se você tem storyboards ou XIB, o merge no main deve ser o mais limpo possível.
Quando usar Git Flow no Swift
- Grandes projetos enterprise com ciclos de lançamento longos (ex.: banco, telemedicina);
- Várias versões paralelas (v1.0 em suporte, v2.0 em desenvolvimento);
- Requisitos rigorosos de estabilidade do branch main.
Quando usar GitHub Flow no Swift
- Startups e projetos médios com deploy rápido;
- Equipes de até 10 pessoas;
- Projetos em SwiftUI (menos conflitos em referências).
Pessoalmente, recomendo um híbrido: Git Flow com um branch develop simplificado — é o equilíbrio ideal para projetos Swift de complexidade média.
3. Configuração do feature branch: regras que salvam os nervos
Cada nova funcionalidade é um branch separado a partir do develop (ou main, se você usa GitHub Flow). Aqui está um modelo simples que uso nos meus projetos:
git checkout developgit pull --rebase origin developgit checkout -b feature/SPT-123-tela-loginImportante: sempre faça rebase antes de criar o branch, para não carregar commits antigos. E não se esqueça dos prefixos: feature/, bugfix/, hotfix/, release/. Isso simplifica a busca no histórico.
Com que frequência sincronizar com o develop
Faça rebase uma vez por dia ou antes de cada commit. Isso minimiza conflitos. Comando:
git checkout feature/SPT-123-tela-logingit rebase developSe os conflitos forem inevitáveis (por exemplo, devido ao .xcodeproj), use git mergetool
Blogs
Book Recommendations
Leia também
