Não importa se você está construindo um novo site, desenvolvendo um tema ou plugin ou configurando estratégias avançadas de integração e implantação contínuas, você estará trabalhando com código.
Em cada site, há código sendo executado – quer você esteja usando WordPress, WooCommerce, Drupal, Magento, NextJS ou até mesmo HTML codificado manualmente. Existem conjuntos de arquivos necessários para fazer com que cada página seja renderizada e exiba o conteúdo para o mundo.
O que você descobre rapidamente é que precisa de uma maneira de rastrear alterações de código ao longo do tempo. Você precisa saber quais alterações estão na versão mais atual de qualquer arquivo e quem fez cada alteração.
É aqui que entra o Git. Continue lendo para aprender sobre o Git, como trabalhar com repositórios Git remotos e muito mais.
Compreendendo o Git
Git é um sistema de controle de versão que permite aos desenvolvedores, e a qualquer pessoa que esteja trabalhando com arquivos, criar e armazenar facilmente versões de suas alterações, ver um histórico dessas alterações e compartilhar essas alterações entre dispositivos e sistemas, ao mesmo tempo em que fornece uma maneira para desfazer essas alterações caso algo dê errado.
Uma breve história
Em 2005, uma equipe de desenvolvedores estava criando um projeto chamado Linux, o sistema operacional gratuito e de código aberto. Eles precisavam de uma maneira de comunicar facilmente as mudanças entre centenas de colaboradores. Originalmente, eles estavam distribuindo patches individuais que continham o código atualizado, mas isso se mostrou problemático em muitas frentes, especialmente ao determinar qual era a versão “verdadeira” e mais recente de qualquer conjunto específico de alterações.
Frustrado com essas questões, o projeto Linux levou Linus Torvald a implementar uma ideia bastante nova para um projeto para compartilhar toda a base de código entre desenvolvedores e tirar “instantâneos” de suas alterações, chamados commits, que poderiam ser compartilhados e mesclados com qualquer outra cópia do o código, em qualquer lugar do mundo. Isto ajudou imediatamente na comunicação, pois todas as alterações do projeto puderam ser vistas como um único histórico.
Esse método para capturar esses instantâneos é o Git, que rapidamente ganhou vida própria e tem sido desenvolvido independentemente do projeto Linux desde então.
Um gráfico de mudanças
Conceitualmente, você pode pensar no Git como um gráfico de nós, onde cada nó é um instantâneo de todo o projeto em um determinado momento. O Livro Gitem git-scm.com descreve a estrutura de um instantâneo.
Essa cadeia de instantâneos cria um gráfico ao longo do tempo, com a versão mais recente na frente ou no topo do seu histórico de alterações. Cada snapshot é chamado de “commit” no Git.
Aqui está uma rápida olhada na aparência de um projeto Git se você colocar a alteração mais recente no topo do gráfico. Nota – este exemplo está usando o GUI do GitKraken Git para visualizar o gráfico.
Construindo o gráfico Git
O Git constrói esse gráfico de alterações, também conhecido como histórico do Git, por meio de um processo de confirmação de alterações. Antes de confirmar as alterações, no entanto, você precisará informar especificamente ao Git o que deseja adicionar a esse instantâneo ou confirmar como é mencionado corretamente no Git.
Ao trabalhar localmente, todas as alterações que você salva em seu projeto estão em seu “Diretório de Trabalho”. O Git pode ver essas alterações, mas ainda não sabe quais alterações você deseja confirmar. Você precisará informar explicitamente ao Git quais alterações deseja confirmar usando um comando chamado “git add” para adicionar esses arquivos específicos à “área de teste” do Git.
Depois de fazer as alterações no arquivo que deseja confirmar no gráfico dos instantâneos do projeto, você pode usar o comando “Git commit” para construir permanentemente esse instantâneo no gráfico.
Voltando no tempo
Uma das vantagens do Git e de ter todo o histórico do projeto disponível é que você pode voltar e desfazer toda e qualquer alteração a qualquer momento.
Se o último commit que você fez quebrar alguma coisa, ou você mudar de ideia sobre o que fez, você pode fazer um “Git revert” para reverter o commit do Git. Isso cria um novo commit no gráfico que simplesmente desfaz as alterações que você acabou de fazer.
Se quiser voltar no tempo e fazer parecer que você nunca fez um commit, você pode usar “Git reset” para fazer isso.
O poder da ramificação e da fusão no Git
Um dos recursos mais poderosos que o Git nos oferece é a capacidade de criar realidades alternativas paralelas. Não mesmo.
Como você está fazendo um gráfico de commits ao longo do tempo, você pode optar por fazer linhas paralelas de commits, chamadas de ramificações, a partir de qualquer ponto do seu histórico. Um recém-criado Ramo Git é independente do histórico principal, o que significa que você é livre para fazer as alterações que desejar e isso não afetará seus outros trabalhos. A linha do tempo principal também é uma ramificação e é mais comumente chamada de ramificação “principal” ou “mestre”. Novas ramificações e ramificações diferentes da principal são comumente chamadas de “ramificações de recursos”.
Depois de fazer as alterações em sua ramificação de recursos, você pode aplicar todas as alterações à ramificação principal executando um Mesclagem do Git.
Há uma grande vantagem em trabalhar desta forma. Uma ramificação de recurso isola as alterações de código, portanto, se você introduzir erros, poderá ter certeza de que a ramificação principal é segura. Trabalhar em filiais também libera a ramificação principal caso você precise aplicar uma atualização ou correção de segurança sem interromper o trabalho de desenvolvimento em andamento.
A fusão do Git também permite que você extraia alterações do branch principal para um branch de recursos. Isso lhe dá a capacidade de garantir que as atualizações feitas no branch principal ainda funcionarão com as alterações propostas antes de você tentar mesclá-las com o “principal”.
Se você estiver trabalhando em equipe, um Estratégia de ramificação Git pode garantir que sua equipe possa testar as alterações minuciosamente antes de chegarem à produção e fornecer uma maneira direta de gerenciar o processo.
Trabalhando com repositórios remotos no Git
Um dos principais objetivos do Git é simplificar o compartilhamento de código com pessoas em todo o mundo. Construída no Git está a noção de um repositório remoto.
A Repositório Git é toda a pasta do projeto onde você armazena seu trabalho e é o que o Git acompanha ao longo do tempo. Cada repositório pode ser clonado usando o Clone Git comando e compartilhado um número ilimitado de vezes, tornando o Git muito escalável.
Outro aspecto que torna o Git muito escalável é que se você alterar um documento, não será necessário armazenar uma cópia totalmente nova desse documento. As alterações são armazenadas como pequenos pacotes de informações chamados “deltas”, e apenas as linhas modificadas individualmente de um arquivo e alguns dados sobre a alteração são o que o Git precisa armazenar ou compartilhar. Deltas são muito leves, geralmente com apenas alguns bytes de tamanho. Por exemplo, se você alterar uma única linha em um documento de 100 KB, o delta terá apenas 20 bytes ou mais.
Para manter tudo alinhado e consistente em todas as cópias de um repositório, você simplesmente precisa designar qual cópia, localizada em qual computador, é a cópia “verdadeira” do projeto, e então certificar-se de que seus commits cheguem a essa cópia.
Isso também funciona de outra maneira. Ao colaborar com outras pessoas, você pode colocar as alterações delas em sua cópia local do repositório para garantir que sua cópia local do projeto esteja atualizada.
Existem várias empresas que tornam a colaboração em repositórios remotos extremamente simples e gerenciável. Plataformas como GitHub, GitLab e BitBucket oferecem hospedagem de repositório Git online e ferramentas de colaboração. Existem muitos milhões de repositórios Git online sendo gerenciados por milhões de desenvolvedores, e o Git rastreia cada fonte de verdade, não importa quantas pessoas estejam colaborando.
O que não armazenar no Git
Vamos falar sobre o que você provavelmente não deveria fazer com o Git. Embora o Git seja incrível no compartilhamento de código e no rastreamento de alterações ao longo do tempo, existem alguns trabalhos que não são adequados para o modelo. Felizmente, o Git nos oferece uma maneira prática de instruí-lo a ignorar coisas, chamada de arquivo “.gitignore”.
Se um arquivo “.gitiginore” estiver presente, o Git irá verificar se ele deveria estar monitorando esses itens. Dentro de um “.gitiginore” você pode listar nomes de arquivos individuais, diretórios inteiros ou tipos inteiros de arquivos. Por exemplo, se você quiser excluir todos os arquivos .png e .jpg e toda a sua pasta “wp-content/uploads”, em seus arquivos “.gitiginore” você simplesmente escreveria:
Por que excluir arquivos de mídia do Git?
O Git armazena snapshots de um projeto e apenas repassa os “deltas”. Mas se o arquivo em questão for uma “bolha” de dados, como uma imagem, vídeo ou qualquer outro arquivo binário, cada alteração do arquivo criará uma nova bolha de dados. O Git então precisa lembrar o estado do blob antigo e do novo, adicionando muito tamanho desnecessário ao repositório. Isso aumenta com o tempo e os repositórios logo se tornam complicados à medida que você perde os benefícios leves do Git.
Acredite ou não, talvez você não queira acompanhar as alterações no próprio núcleo do WordPress. Existem algumas razões para isso.
Primeiro, existe um velho ditado em qualquer CMS: “Não hackeie o núcleo!” Não deve haver nada que você esteja alterando no núcleo do WordPress que precise ser rastreado. Quaisquer atualizações precisarão vir do próprio WordPress e se você quiser uma versão anterior, isso será facilmente especificado ao instalá-lo. Você absolutamente pode armazenar uma instalação inteira do WordPress no Git, mas não há muito valor em fazer isso em determinadas situações. Você realmente deseja apenas rastrear alterações no código que está manipulando, como plug-ins personalizados e temas filhos. É realmente uma boa ideia consultar seu provedor de hospedagem para obter conselhos sobre esse assunto.
Em segundo lugar, se você planeja contribuir com o WordPress, descobrirá que na verdade ele é mantido por meio de um sistema de controle de versão mais antigo chamado SVN. Este modelo requer uma infraestrutura de servidor central e é muito menos popular em comparação com o Git, mas, novamente, o WordPress é mais antigo que o Git. Trabalhar com o sistema de patches SVN é um pouco diferente e você deve consultar sua documentação para saber mais sobre isso.
Conclusão
Esperamos que agora você entenda melhor o que é Git e como ele pode ser aproveitado para trabalhar com o código do seu site. O Git pode ser usado para todo e qualquer arquivo que você alterará ao longo do tempo, mesmo que não seja um código de computador.
O Git refere-se aos seus usuários-alvo como “trabalhadores do conhecimento”, um termo antigo emprestado da IBM. Para tudo, desde notas na sua área de trabalho até receitas, até livros inteiroso Git oferece uma maneira de organizar melhor seu trabalho e deixar um rastro sólido de por que você fez cada alteração e quando ela foi feita.
O poder de voltar no tempo e ver suas mudanças, aliado à capacidade de trabalhar em universos paralelos ilimitados com ramificações e fusões, fazem do Git uma ferramenta indispensável para quem trabalha com código. Git também é a principal forma de colaboração das equipes em projetos de código.
O Git é de uso gratuito e a maioria das GUIs do Git, como Git Kraken têm versões gratuitas. Não há razão para você não usar o Git para rastrear seu trabalho, então “Git” para ele!
Recursos relacionados
– Desenvolvimento Local WordPress com XAMPP
– Uso e fluxos de trabalho avançados do Git
– Ganchos Git
– O que é um site de desenvolvimento?
– Cache para WordPress
