O que é Git e por que você deve usar o controle de versão se você é um desenvolvedor

Propaganda

Como desenvolvedores da Web, na maioria das vezes tendemos a trabalhar em sites de desenvolvimento local, depois carregamos tudo quando terminamos. Isso é bom quando é apenas você e as alterações são pequenas, mas quando você lida com mais de um pessoa que trabalha em algo ou em um projeto grande com muitos componentes complicados, que simplesmente não é factível. É quando passamos a algo chamado controle de versão.

Hoje vou falar sobre um software de controle de versão de código aberto chamado Git. Isso permite que mais de uma pessoa trabalhe com segurança no mesmo projeto sem interferir entre si, mas é muito mais do que isso também.

Por que usar o software de controle de versão?

Em primeiro lugar, o nome deve denunciá-lo. O software de controle de versão permite que você tenha "versões" de um projeto, que mostram as alterações feitas no código ao longo do tempo e permite voltar atrás, se necessário, e desfazer essas alterações. Somente essa capacidade - de poder comparar duas versões ou reverter alterações, torna bastante inestimável ao trabalhar em projetos maiores.

Você provavelmente já fez isso em algum momento, salvando cópias de um projeto em pontos diferentes para ter um backup. Em um sistema de controle de versão, apenas as alterações seriam salvas - um arquivo de patch que pode ser aplicado a uma versão, a fim de torná-lo igual à próxima versão. Com um desenvolvedor, isso é suficiente.

Mas e se você tiver mais de um desenvolvedor trabalhando em um projeto? É aí que surge a idéia de um servidor de controle de versão centralizado. Esse é o padrão há muito tempo, pelo qual todas as versões são armazenadas em um servidor central, e desenvolvedores individuais fazem check-out e enviam as alterações de volta para esse servidor. Se você já examinou o histórico de edições de uma página da Wikipedia, terá uma boa idéia de como isso funciona em um cenário do mundo real:

Os benefícios de um sistema como esse é que vários desenvolvedores podem fazer alterações e cada alteração pode ser atribuída a um desenvolvedor específico. Por outro lado, o fato de tudo estar armazenado em um banco de dados remoto significa que nenhuma alteração pode ser feita quando esse servidor fica inativo; e se o banco de dados central for perdido, cada cliente terá apenas a versão atual do que quer que esteja trabalhando.

Isso nos leva ao Git, e outros chamados sistemas de controle de versão distribuídos. Nesses sistemas, os clientes não apenas verificam a versão atual dos arquivos e trabalham com eles - eles refletem todo o histórico da versão. Cada desenvolvedor sempre tem uma cópia completa de tudo. Um servidor central ainda é usado, mas, se o pior acontecer, tudo poderá ser restaurado a partir de qualquer cliente que tenha as versões mais recentes.

O Git funciona especificamente tirando instantâneos de arquivos; se os arquivos permanecerem inalterados em uma versão específica, simplesmente vinculará aos arquivos anteriores - isso mantém tudo rápido e enxuto.

Também pode ser interessante saber que o Git é usado para gerenciar e desenvolver o núcleo do linux - o bloco de construção base sobre o qual todas as distribuições linux são construídas.

O que é o Github?

Embora você possa executar seu próprio servidor Git localmente, Github é um servidor remoto, uma comunidade de desenvolvedores e uma interface gráfica da web para gerenciar seu projeto Git. É gratuito para usar até 5 repositórios públicos - ou seja, quando qualquer pessoa pode visualizar ou dividir seu código - com planos de baixo custo para projetos privados. Eu sugiro fortemente que você se inscreva em uma conta gratuita para poder começar a brincar com seus próprios projetos ou forjar outros.

Bifurcação e ramificação

Esses são os conceitos principais da experiência do Git; portanto, vamos tirar um momento para explicar a diferença.

Você provavelmente já ouviu o trabalho "fork" ao lidar com distribuições linux. Se você estiver familiarizado com o aplicativo Plex do media center, saberá que ele era originalmente uma bifurcação do código-fonte aberto semelhante Xbox Media Center Aeon Nox 3.5: Tema bonito e personalizável para XBMCConfigure o seu centro de mídia exatamente como você deseja. O Aeon Nox 3.5 é a versão mais recente do que talvez seja o melhor tema para o XBMC, e é uma combinação rara: bela ... consulte Mais informação . Isso significa simplesmente que em algum momento no passado, alguns desenvolvedores pegaram o código do XBMC e decidiram seguir seu próprio caminho; que se tornou Plex.

Obviamente, isso é totalmente permitido quando o projeto é de código aberto - você pode pegar o código, fazer o que quiser com ele. Com o Git, se você sentir que suas alterações são boas o suficiente para serem revertidas para o projeto "mestre", você pode fazer uma "solicitação de recebimento" ao autor, solicitando que ele retorne as alterações para o original projeto. Isso permite que você tenha centenas de milhares de desenvolvedores trabalhando em um projeto a qualquer momento, nenhum dos quais deve precisam ser aprovados para acesso ao código - eles apenas copiam o código, fazem alterações e solicitam a reversão no mestre. Obviamente, cabe ao proprietário do projeto original se ele decidir aceitar suas alterações ou não.

Ramificação é algo feito internamente em um projeto pelos desenvolvedores autorizados. Ele permite que você separe facilmente problemas ou recursos específicos e trabalhe neles sem interromper os arquivos principais. Quando estiver satisfeito com o fato de sua filial ter resolvido o problema, você o mesclará novamente ao mestre. A qualquer momento, pode haver quantos ramos você desejar; eles não interferem um no outro. Você também pode mesclar alterações entre ramificações sem tocar no mestre.

Aqui está um ótimo diagrama de um exemplo de fluxo de trabalho Vincent Driessen:

Da próxima vez, veremos como configurar um exemplo de Git funcional e fazer alterações de código nas ramificações. O controle de versão é um tópico enorme. Eu dei apenas uma breve visão geral aqui, mas como desenvolvedor que está acostumado a fazer alterações e desfazê-las se elas não funcionarem, todo o conceito me surpreendeu - espero que faça o seu também.

Você é um desenvolvedor experiente com experiência no Git? Você está começando e acha que gostaria de experimentar? Som desligado nos comentários!