# Git para WordPress Git WordPress é o uso do sistema de controle de versão Git para gerenciar o código de temas, plugins e customizações de sites WordPress. Versionar código WordPress profissionalmente significa manter histórico de cada mudança, possibilitar trabalho em equipe sem conflitos, ter pontos de retorno em caso de erros e automatizar deploys. É o padrão para qualquer projeto WordPress sério, especialmente em times com mais de uma pessoa codando. ## O que é Git no contexto WordPress Git é um sistema de controle de versão distribuído criado por Linus Torvalds em 2005, inicialmente para o desenvolvimento do kernel Linux. Ele rastreia mudanças em arquivos ao longo do tempo, permite reverter para estados anteriores, criar ramificações paralelas (branches), mesclar trabalho de várias pessoas e manter um histórico completo do que aconteceu no código. No contexto WordPress, Git é especialmente útil porque o CMS gera mistura de tipos de arquivo: PHP do core, do tema e de plugins, CSS, JavaScript, imagens, traduções. Sem versionamento wordpress, manter esse conjunto consistente entre dev, staging e produção é um exercício de fé. Com Git, cada mudança fica rastreada, atribuível e reversível. O git wordpress não versiona o site inteiro normalmente. Versiona o que é código fonte: temas customizados, plugins customizados, mu-plugins, arquivos de configuração específicos. Não versiona o core do WordPress (gerenciado pelos updates do CMS), nem os uploads (mídia gerada pelo cliente, vai pra storage), nem o banco de dados (gerenciado por migrations ou dumps separados). O github wordpress, gitlab e bitbucket são as plataformas de hospedagem mais usadas para os repositórios. Permitem code review via pull requests, rodar CI/CD para validar e fazer deploy, e dão visibilidade do que cada pessoa fez. Para freelancer trabalhando sozinho, GitHub privado é suficiente. Para agência ou time, com fluxo de PRs. ## Por que versionar código WordPress O motivo número um é poder voltar atrás quando algo quebra. Você fez 30 commits hoje, deu deploy, e descobriu que um deles introduziu bug. Sem Git, é caçar a mudança em meio ao código. Com Git, você compara os commits, identifica o que mudou, reverte só aquele e mantém o resto. O motivo dois é colaboração entre pessoas. Dois desenvolvedores trabalhando no mesmo tema sem versionamento é receita para sobrescrever o trabalho um do outro. Com Git e branches, cada um trabalha isoladamente, faz pull request quando termina, e o sistema mescla as mudanças sem conflitos (ou avisa quando há conflito, e a pessoa resolve manualmente). O motivo três é code review. Antes de mudança ir para produção, outro par de olhos revisa. Pull request mostra exatamente o que mudou, em que arquivos, com que justificativa. Catch de bug e manutenção de qualidade. Em projetos de cliente, é a defesa contra bugs que destroem reputação profissional. O motivo quatro é integração com fluxo de deploy. CI/CD rodando em GitHub Actions, GitLab CI ou Bitbucket Pipelines: a cada push para branch main, executa testes, verifica padrões de código, e faz deploy automático para staging ou produção. Tira o operacional manual e reduz erro humano em deploys. O motivo cinco é documentação implícita. Cada commit conta uma história. Por que essa mudança? O que ela resolve? O log do Git é a documentação viva do projeto. Quando alguém entra no time meses depois, o histórico explica decisões que documentação formal raramente cobre. ## Workflow Git para WordPress O workflow padrão começa com a estrutura do repositório. Você não versiona a instalação WordPress inteira. Versiona o que customiza: pasta wp-content/themes/seu-tema/, pasta wp-content/plugins/seu-plugin-cliente/, e wp-content/mu-plugins/. Os arquivos do core e plugins de terceiros ficam fora — gerenciados pelo Composer ou por update manual. O .gitignore de um projeto WordPress típico exclui: wp-config.php (tem credenciais sensíveis), wp-content/uploads/ (imagens do cliente, não código), wp-content/cache/ (gerado em runtime), node_modules/, vendor/ (dependências, gerenciadas por package.json e composer.json), e arquivos do sistema operacional como .DS_Store e Thumbs.db. O fluxo de branches mais usado: main (produção), staging (homologação), e branches de feature criadas a partir do main. Quando termina uma feature, você abre pull request para staging. Depois de testado, merge para main e deploy automático para produção. Esse fluxo simples cobre 90% dos projetos. Os comandos do dia a dia são poucos: git status (o que mudou), git add (preparar mudanças), git commit (registrar mudanças), git push (enviar para o repositório remoto), git pull (receber mudanças do remoto), git checkout (mudar de branch), git merge (mesclar branches). Você usa esses cinco-seis comandos 95% do tempo. Para integrar com [ambiente staging](https://full.services/glossario/ambiente-staging/), configure deploy automático na hospedagem ou via GitHub Actions. Hospedagens como Kinsta e WP Engine têm integração nativa com Git — push para branch específica dispara deploy. Combine com [WP-CLI](https://full.services/glossario/wp-cli/) em scripts de deploy para limpar cache, rodar migrations e validar saúde do site após cada deploy. ## Ferramentas e boas práticas A primeira ferramenta essencial é o cliente de Git. Linha de comando funciona perfeitamente, mas clientes gráficos como GitHub Desktop, GitKraken, Sourcetree ou Tower facilitam visualização de branches e merges. Para iniciantes, GUI é onboarding mais suave. Para uso avançado e CI/CD, linha de comando é mais rápida. A segunda ferramenta é o Composer. Ele gerencia dependências PHP, incluindo plugins de terceiros. Em vez de versionar plugins comprados (que mudam frequentemente e ocupam espaço), você declara dependências em composer.json e o Composer baixa as versões corretas em cada deploy. Mais leve, mais limpo, mais auditável. A terceira ferramenta é Bedrock, da Roots. É um boilerplate WordPress moderno com Git first-class, Composer integrado, separação clara entre core e código do projeto, suporte a múltiplos ambientes via .env. Para projetos sérios, vale considerar — ainda que adicione complexidade comparado a uma instalação WordPress padrão. A quarta ferramenta é git para temas com integração de build. Temas modernos usam SCSS/PostCSS para CSS, ES6/TypeScript para JavaScript, com bundling via Vite, Webpack ou Rollup. O Git versiona os arquivos fonte; os arquivos de produção (CSS minificado, JS bundle) são gerados via build em CI/CD ou no deploy. Isso mantém o repositório limpo e o código fonte auditável. Boas práticas finais: commits atômicos (cada commit faz uma coisa só), mensagens descritivas (não "ajustes", e sim "corrige cálculo de frete em produtos com peso variável"), pull requests pequenos (mais fáceis de revisar), tag de releases para deploy de produção, branch protection no main. Combine com [functions.php](https://full.services/glossario/functions-php/) bem organizado e plugins customizados bem isolados, e você tem uma arquitetura WordPress profissional. A FULL Services entrega a stack profissional WordPress completa com Git já configurado, ambiente staging integrado, ferramentas de deploy e estrutura modular de customização — pronto para times de desenvolvimento operarem com workflow profissional desde o primeiro dia. **Também conhecido como:** git wordpress, versionamento de código ## Termos relacionados - [WP-CLI](https://full.services/glossario/wp-cli/) - [Child Theme](https://full.services/glossario/child-theme/) - [functions.php](https://full.services/glossario/functions-php/) - [Ambiente Staging](https://full.services/glossario/ambiente-staging/) --- Glossário WordPress da FULL Services: [Git para WordPress](https://full.services/glossario/git-wordpress/)