Uma introdução ao Git

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á um código sendo executado – esteja você usando WordPress, WooCommerce, Drupal, Magento, NextJS ou até mesmo HTML codificado à mão. Existem conjuntos de arquivos necessários para tornar cada página renderizada e exibir conteúdo para o mundo.

O que você descobre rapidamente é que precisa de uma maneira de rastrear as 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.

É aí que entra o Git. Continue lendo para aprender sobre o Git, trabalhar com repositórios Git remotos e muito mais.

Entendendo o Git

Git é um sistema de controle de versão que permite que desenvolvedores e qualquer outra pessoa que esteja trabalhando com arquivos criem e armazenem facilmente versões de suas alterações, vejam um histórico dessas alterações e compartilhem 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 esses problemas, o projeto Linux levou Linus Torvald a implementar uma ideia bastante inovadora para um projeto para compartilhar toda a base de código entre os desenvolvedores e tirar "instantâneos" de suas alterações, chamados de commits, que poderiam ser compartilhados e mesclados com qualquer outra cópia do o código, em qualquer lugar do mundo. Imediatamente isso ajudou na comunicação, pois todas as mudanças do projeto podiam ser vistas como um único histórico.

Esse método para capturar esses instantâneos é o Git, que rapidamente ganhou vida própria e foi 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 momento. O livro Git, em git-scm.com, descreve a estrutura de um snapshot.

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 na parte superior do gráfico. Nota — este exemplo está usando a GUI do GitKraken Git para visualizar o gráfico.

Construindo o gráfico Git

O Git cria 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 poder submeter as alterações, no entanto, você precisará informar especificamente ao Git o que deseja adicionar a esse instantâneo, ou confirmar como é corretamente referido no Git.

Ao trabalhar localmente, todas as alterações que você está salvando 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 ao Git explicitamente quais alterações deseja confirmar usando um comando chamado “git add” para adicionar esses arquivos específicos à “área de teste” do Git.

Depois de ter as alterações de arquivo que você deseja confirmar no gráfico de instantâneos do projeto, você pode usar o comando “Git commit” para criar permanentemente esse instantâneo no gráfico.

Voltando no tempo

Uma das vantagens do Git e de ter todo o histórico do seu 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 você 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 você quiser voltar no tempo e fazer parecer que nunca fez um commit, você pode usar “Git reset” para fazer isso.

O poder de ramificar e mesclar 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 escolher fazer linhas paralelas de commits, chamadas branches, a partir de qualquer ponto do seu histórico. Uma ramificação Git recém-criada é independente do histórico principal, o que significa que você é livre para fazer as alterações que desejar e isso não afetará seu outro trabalho. 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 recurso, você pode aplicar todas as alterações na ramificação principal realizando uma 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, pode ter certeza de que a ramificação principal é segura. Trabalhar em ramificações 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 mesclagem do Git também permite que você puxe as alterações da ramificação principal para uma ramificação de recurso. Isso lhe dá a capacidade de garantir que as atualizações feitas na ramificação principal ainda funcionem com as alterações propostas antes de tentar mesclá-las com “principal”.

Se você estiver trabalhando com uma equipe, uma estratégia de ramificação do Git pode garantir que sua equipe possa testar as alterações completamente antes de chegar à 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ído no Git está a noção de um repositório remoto.

Um repositório Git é toda a pasta do projeto onde você armazena seu trabalho e é o que o Git está rastreando ao longo do tempo. Cada repositório pode ser clonado usando o comando Git clone 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 precisará armazenar uma cópia totalmente nova desse documento. As alterações são armazenadas como pequenos pacotes de informações chamados de “deltas”, e apenas as linhas modificadas individualmente de um arquivo e um pouco de dados sobre a alteraçã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, em seguida, certificar-se de que seus commits cheguem a essa cópia.

Isso funciona de outra maneira também. Ao colaborar com outras pessoas, você pode fazer pull das 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 em compartilhar código e rastrear alterações ao longo do tempo, existem alguns trabalhos que não são adequados para o modelo. Felizmente, o Git nos dá uma maneira prática de dizer a ele para ignorar as coisas, chamado de arquivo “.gitignore”.

Se um arquivo “.gitiginore” estiver presente, o Git o verificará para ver se deveria estar observando 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ê quisesse excluir todos os arquivos .png e .jpg e toda a sua pasta “wp-content/uploads”, em seus arquivos “.gitiginore” você simplesmente escreveria:

 *.png *.jpg wp-content/uploads

Por que excluir arquivos de mídia do Git?

O Git armazena instantâneos de um projeto e apenas passa os “deltas” de volta. Mas se o arquivo em questão for um “blob” de dados, como uma imagem, vídeo ou qualquer outro arquivo binário, cada alteração do arquivo criará um novo blob de dados. O Git então precisa lembrar o estado do blob antigo e do novo blob, adicionando muito tamanho desnecessário ao repositório. Isso se acumula com o tempo, e os repositórios logo se tornam difíceis de manejar à 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, há um velho ditado com 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 é facilmente especificado ao instalá-lo. Você absolutamente pode armazenar uma instalação inteira do WordPress no Git, mas não há muito valor em fazê-lo em determinadas situações. Você realmente só quer rastrear alterações no código que está manipulando, como seus plugins personalizados e temas filhos. É uma boa ideia verificar com seu provedor de hospedagem para obter conselhos sobre esse tópico.

Em segundo lugar, se você planeja contribuir de volta para o WordPress, descobrirá que ele é realmente mantido por meio de um sistema de controle de versão mais antigo chamado SVN. Esse modelo requer uma infraestrutura de servidor central e é muito menos popular comparado ao Git, mas, novamente, o WordPress é mais antigo que o Git. Trabalhar com o sistema de patches SVN é um pouco diferente e você deve consultar a documentação deles para saber mais sobre isso.

Conclusão

Espero que agora você tenha uma melhor compreensão do que é o Git e como ele pode ser aproveitado para trabalhar com o código do seu site. O Git pode ser usado para todos e quaisquer arquivos que você alterar ao longo do tempo, mesmo que não seja um código de computador.

O Git se refere a seus usuários-alvo como “trabalhadores do conhecimento”, um termo antigo emprestado da IBM. Para tudo, desde anotações em sua área de trabalho até receitas e livros inteiros, o 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 foi feita.

O poder de poder voltar no tempo e ver suas alterações, misturado com a capacidade de trabalhar em universos paralelos ilimitados com ramificação e mesclagem, torna o Git uma ferramenta indispensável para quem trabalha com código. O Git também é a principal maneira pela qual as equipes colaboram em projetos de código.

O Git é gratuito e a maioria das GUIs do Git, como o GitKraken, tem 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

- Git Hooks

- O que é um site de desenvolvimento?

- Cache para WordPress