Git e controle de versão no desenvolvimento móvel: o que é, comandos básicos e como funciona

Controle de versão e Git: o que é?

Git é um sistema de controle de versão distribuído (VCS) criado por Linus Torvalds em 2005 para o desenvolvimento do kernel Linux. Ao contrário dos sistemas centralizados (SVN, CVS), o Git armazena uma cópia completa do histórico do projeto em cada computador do desenvolvedor. Isso significa que você pode fazer commits, navegar pelo histórico e criar branches mesmo sem conexão com a internet.

O Git funciona com instantâneos (snapshots) — cada commit salva o estado de todos os arquivos do projeto no momento do salvamento. Se um arquivo não mudou, o Git cria uma referência à versão anterior, economizando espaço. De acordo com a análise do GitHub (2025), o repositório médio contém 1.200 commits e 15 branches.

Na IT Sectr, usamos o Git desde 2017 em todos os projetos. Nossa experiência mostra que a configuração adequada do Git desde o primeiro dia economiza até 30% do tempo da equipe em mesclagem e resolução de conflitos. O Git se tornou o padrão de fato — é suportado por todos os IDEs modernos (Android Studio, Xcode, VS Code) e sistemas CI/CD.

# Configuração básica do Git
git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

# Criando um novo repositório
git init my-project
cd my-project

# Adicionando arquivos e fazendo commit
git add README.md
git commit -m "Initial commit"

# Trabalhando com um repositório remoto
git remote add origin https://github.com/user/my-project.git
git push -u origin main

O código acima mostra a sequência básica: inicializar um repositório, primeiro commit e publicação em um servidor remoto. O comando git init cria uma pasta .git oculta que armazenará todo o histórico do projeto. Cada git commit cria um ponto de restauração ao qual você pode retornar a qualquer momento.

Conceitos básicos: Repository, Branch, Commit

Entender os três conceitos básicos — Repository, Branch e Commit — é essencial para trabalhar com qualquer sistema de controle de versão. Um repositório é um contêiner para todo o projeto. Um commit é um estado salvo dos arquivos. Um branch é uma linha de desenvolvimento separada.

Repository (repositório) pode ser local (no seu computador) ou remoto (em um servidor GitHub, GitLab). Cada desenvolvedor clona o repositório remoto em sua máquina e trabalha com uma cópia local. As alterações são sincronizadas via push (enviar) e pull (puxar). No controle de versão distribuído, cada desenvolvedor armazena uma cópia completa do histórico.

Branch (ramo) é um ponteiro para um dos commits. Os branches permitem desenvolvimento paralelo: um desenvolvedor trabalha em uma nova funcionalidade (feature branch), outro corrige um bug (hotfix branch), um terceiro prepara um lançamento (release branch). De acordo com o GitLab Flow (2025), o projeto médio tem de 3 a 5 branches ativos simultaneamente.

Commit é uma unidade de alteração. Cada commit contém um hash único (SHA-1), uma mensagem, um autor e um carimbo de data/hora. Uma boa prática é fazer commits pequenos e significativos com mensagens descritivas — isso simplifica o Code Review e a reversão de alterações. O controle de versão por meio de commits fornece o histórico completo do projeto.

Feature Branch

Feature Branch (ramo de funcionalidade) é um branch temporário criado a partir de develop ou main para desenvolver uma tarefa específica. Após concluir o trabalho, o branch é mesclado via Pull Request e excluído. Essa prática permite isolar alterações sem afetar a estabilidade da base de código principal.

Fluxo de trabalho típico: criar branch feature/add-login → fazer vários commits → criar Pull Request → passar pelo Code Review → mesclar em develop. Na IT Sectr usamos exatamente essa abordagem: cada tarefa do Jira corresponde a um feature branch separado. Isso simplifica o rastreamento de alterações e a reversão, se necessário.

Rebase vs Merge

Merge cria um commit de mesclagem que combina dois branches. Ele preserva o histórico completo, incluindo linhas de desenvolvimento paralelas. Rebase reescreve o histórico: pega commits de um branch e os "reaplica" sobre outro, criando um histórico linear.

Merge é mais adequado para branches públicos e equipes grandes onde a cronologia é importante. Rebase é conveniente para branches de funcionalidade pessoais antes de criar um PR — torna o histórico mais limpo e compreensível. No entanto, rebase nunca deve ser aplicado a branches em que outros desenvolvedores estão trabalhando, pois reescreve o histórico.

# Criando e alternando para um feature branch
git checkout -b feature/add-login main

# Trabalhando no branch
git add login-screen/
git commit -m "Add login screen layout"

# Rebase no main mais recente antes do PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push para o repositório remoto
git push origin feature/add-login

Este exemplo mostra um fluxo de trabalho típico: criar um feature branch a partir de main, vários commits e rebase para obter um histórico linear limpo antes de enviar para revisão. Essa abordagem minimiza conflitos de mesclagem.

Git Flow vs Trunk-Based Development

Git Flow e Trunk-Based Development são duas principais estratégias de controle de versão que determinam como uma equipe organiza o trabalho com Git. A escolha depende do tamanho da equipe, frequência de lançamentos e requisitos de estabilidade.

Git Flow é um modelo estrito com vários branches permanentes: main (código de lançamento), develop (desenvolvimento atual), feature/* (novas funcionalidades), release/* (preparação de lançamento) e hotfix/* (correções urgentes). Este modelo é bom para projetos com ciclos de lançamento claros (por exemplo, aplicativos móveis com versões 1.0, 2.0).

Trunk-Based Development é uma abordagem com um único branch principal (trunk/main) onde todos os desenvolvedores mesclam alterações várias vezes ao dia. Feature flags são usados para ocultar funcionalidades incompletas. Essa abordagem é popular no desenvolvimento web e startups onde a velocidade de entrega é importante.

Git Flow

Git Flow, proposto por Vincent Driessen em 2010, continua sendo um dos modelos mais populares. Sua principal vantagem é a separação estrita do código por estágios do ciclo de vida. O branch main contém apenas código de lançamento, develop contém o desenvolvimento atual e os feature branches isolam novas funcionalidades uns dos outros.

Branches hotfix são criados a partir de main para correções urgentes e após a mesclagem são mesclados de volta em main e develop. Branches release são criados a partir de develop quando a equipe está pronta para um lançamento. Apenas correções de bugs e metadados (versão, compilação) são adicionados a eles. Após o lançamento, o branch release é mesclado em main e develop. De acordo com uma pesquisa da JetBrains (2024), 37% das equipes usam Git Flow. Este modelo de controle de versão continua sendo o padrão para projetos com lançamentos fixos.

# Exemplo Git Flow: iniciar trabalho em um lançamento
git checkout -b release/1.2.0 develop

# Corrigindo bugs no branch release
git commit -m "Fix login button crash"

# Completando o lançamento — mesclar em main e develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Excluindo o branch release
git branch -d release/1.2.0

O código ilustra a criação de um branch release, sua estabilização e mesclagem nos branches principais. A flag --no-ff garante um commit de mesclagem, preservando a informação de que as alterações vieram do branch release.

Pull Request e Code Review

Pull Request (PR) é um mecanismo pelo qual um desenvolvedor propõe alterações de seu branch para o branch principal. PR é um elemento-chave do controle de versão no trabalho em equipe — não é apenas uma forma de mesclar código, mas um processo de discussão, revisão e verificação de qualidade. No GitLab, o mecanismo similar é chamado de Merge Request (MR), mas a essência é a mesma: notificar a equipe sobre as alterações e obter aprovação.

Um bom PR deve ser pequeno (até 300 linhas de código), focado em uma única tarefa e conter uma descrição do que foi feito e por quê. De acordo com um estudo do Google (2025), PRs com mais de 400 linhas levam o dobro do tempo para revisar e a probabilidade de detectar bugs diminui em 30%. Code Review é a verificação do código por outro desenvolvedor antes da mesclagem.

Na IT Sectr, praticamos Code Review obrigatório para cada PR. Isso não só melhora a qualidade do código, mas também ajuda a disseminar conhecimento dentro da equipe. O Code Review verifica: se o código segue os princípios arquitetônicos, se há bugs, se há testes suficientes, se as variáveis estão nomeadas corretamente. Todos os comentários são discutidos no PR até a mesclagem.

Plataformas: GitHub, GitLab, Bitbucket

Git é um protocolo, mas para colaboração é necessária uma plataforma de controle de versão que forneça interface web, gerenciamento de acesso, CI/CD e ferramentas de revisão. Três plataformas dominam o mercado: GitHub, GitLab e Bitbucket.

GitHub é a maior plataforma com mais de 56 milhões de desenvolvedores. Pertence à Microsoft, oferece Actions (CI/CD), Pages (hospedagem), Discussions e Copilot. O plano gratuito inclui repositórios privados ilimitados para equipes de até 3 pessoas. GitHub é popular na comunidade de código aberto.

GitLab é uma plataforma DevOps completa com CI/CD integrado, registro de contêineres e gerenciamento de infraestrutura. Ao contrário do GitHub, o GitLab pode ser instalado em seu próprio servidor (Self-Managed). Bitbucket da Atlassian é fortemente integrado com Jira e Confluence, tornando-o a escolha para equipes que já usam o ecossistema Atlassian.