Explorar o controle de versão usando o Git

Concluído

Há diferentes tipos de VCS (sistemas de controle de versão), mas geralmente eles podem ser categorizados como centralizados e distribuídos. Nos últimos anos (parcialmente devido à crescente popularidade do DevOps), a última categoria ganhou popularidade significativa, com o Git se tornando o padrão de fato no desenvolvimento de software moderno. Esse VCS em particular seria a opção mais adequada para a organização em nosso cenário de exemplo, especialmente considerando sua intenção de usar o GitHub como a plataforma de destino para sua transição de DevOps. Nesta unidade, explore o uso do Git como controle de versão.

Captura de tela de uma tabela comparando os benefícios dos sistemas de controle de versão centralizados e distribuídos.

Controle de versão centralizado versus distribuído

Os sistemas de controle de versão centralizados (CVCS) e os DVCS (sistemas de controle de versão distribuída) oferecem a capacidade de gerenciar e acompanhar alterações em projetos de desenvolvimento de software. As principais diferenças entre eles estão relacionadas à maneira como implementam repositórios e colaboração. Em particular:

  • Local do repositório: em sistemas centralizados, há uma única instância centralizada do repositório que contém o histórico completo do projeto. Em sistemas distribuídos, cada membro da equipe normalmente teria uma cópia local totalmente funcional de todo o repositório, potencialmente incluindo seu histórico de versão completo.
  • Conectividade de rede: em sistemas centralizados, o acesso à instância centralizada do repositório é necessário para executar muitas ações, incluindo atualizações e recuperação de histórico. Em sistemas distribuídos, todas as atividades podem ser executadas na cópia local do repositório.
  • Modelo colaborativo: em sistemas centralizados, os desenvolvedores fazem check-out de arquivos da instância centralizada do repositório enquanto estão conectados a ele em uma rede antes de fazer modificações e confirmar as alterações. Isso impede que alterações sejam retiradas dos arquivos por outras pessoas. Em sistemas distribuídos, os desenvolvedores fazem e confirmam alterações em sua cópia local do repositório, que, em algum momento posterior, são sincronizadas com outras cópias.
  • Modelo de ramificação e mesclagem: em sistemas centralizados, a ramificação e a mesclagem normalmente exigem coordenação com outras pessoas. Em sistemas distribuídos, as ramificações podem ser criadas independentemente em cópias locais e mescladas posteriormente.

Vale a pena observar que, embora o modelo distribuído não dependa de ter um repositório central (no sentido tradicional), é comum implementar uma cópia do repositório, que é hospedada por serviços como GitHub, GitLab ou Bitbucket. Essa instância serve como o ponto focal de colaboração e sincronização.

Captura de tela de repositórios e colaboração de sistemas de controle de versão centralizados e distribuídos.

Terminologia do Git

Para se tornar proficiente em trabalhar com o Git, é importante se familiarizar com sua terminologia. Alguns dos conceitos são exclusivos do Git, distinguindo-os de outros DVCS. Os termos mais fundamentais do Git incluem:

  • Árvore de trabalho: uma estrutura de diretório que contém todos os arquivos do projeto.
  • Repositório (geralmente conhecido como repositório): o diretório localizado no nível superior de uma árvore de trabalho, hospedando todos os arquivos do projeto junto com o histórico de versão desses arquivos.
  • Clone: a ação de criar uma cópia de um repositório remoto em um computador local para trabalhar em um projeto ao qual você tem acesso.
  • Bifurcação: a ação de criar uma cópia hospedada no GitHub de um repositório remoto para trabalhar em um projeto ao qual você não tem acesso. Normalmente, um fork é usado se você pretende contribuir com o projeto de alguém ou criar sua própria versão desse projeto. Embora você não tenha acesso de gravação ao repositório original, você pode gerenciar totalmente seu fork.
  • Confirmação: um instantâneo das alterações feitas nos arquivos em um repositório em um ponto específico no tempo. Os commits são usados ​​para registrar e salvar alterações.
  • Área de preparo um local intermediário (que não faz parte do repositório) em que as alterações nos arquivos na árvore de trabalho são preparadas antes de serem confirmadas. Ele permite que os desenvolvedores selecionem as alterações que pretendem confirmar.
  • Branch: uma série nomeada de confirmações vinculadas. Em termos simples, um branch representa uma versão distinta de um projeto. Isso permite trabalhar em diferentes partes de um projeto ao mesmo tempo sem afetar sua versão principal. O commit mais recente dentro de uma ramificação é chamado de head. O branch padrão gerado automaticamente quando você inicializa um repositório é chamado principal ou mestre.
  • Mesclar: o processo de combinar alterações de uma ramificação (ou confirmação) em outra. Isso integra as alterações de um ramo em outro.
  • Objeto: um dos quatro tipos de entidades disponíveis em um repositório. Essas entidades incluem blobs que representam arquivos individuais, uma árvore que representa uma árvore de trabalho, uma confirmação que representa uma versão específica da árvore de trabalho e uma *tag, que é um rótulo atribuído a uma confirmação individual.
  • Hash: um identificador de comprimento fixo, exclusivo e gerado automaticamente que representa o conteúdo de um objeto. Sempre que esse objeto for alterado, seu hash também será alterado. Isso permite que o Git determine qual conteúdo em um repositório foi atualizado.
  • Remoto: uma referência a outro repositório (diferente do local), geralmente referindo-se à instância do repositório hospedada por um serviço. Isso serve como o padrão para operações de push e pull.
  • Pull: a ação que busca alterações de um repositório remoto e as mescla na ramificação atual.
  • Push: a ação que envia confirmações locais para um repositório remoto, atualizando-a com as alterações feitas localmente.
  • Fetch: a ação que recupera alterações de um repositório remoto sem mesclá-las automaticamente. Isso permite a revisão antes de aplicar uma mesclagem.
  • Solicitação de pull: um recurso em plataformas de hospedagem baseadas em Git (como o GitHub) que permite aos desenvolvedores propor alterações e solicitar que elas sejam mescladas em um branch de destino.

O Git também tem um amplo conjunto de comandos, que fornecem a capacidade de implementar e gerenciar totalmente o controle de versão por meio do shell de comando, como o Bash do Linux ou o Prompt de Comando do Windows. Como alternativa, você pode gerenciar o Git por meio de aplicativos da área de trabalho, como o GitHub Desktop. As plataformas de hospedagem baseadas em Git fornecem uma interface da Web que facilita a interação com repositórios do lado do serviço.

Git vs. GitHub

Conforme descrito anteriormente, o Git é um DVCS multiplataforma de software livre que facilita a colaboração usando repositórios locais, que podem ser sincronizados com repositórios remotos. O GitHub é um serviço baseado em nuvem que fornece uma plataforma de hospedagem para repositórios Git. Ele amplia o alcance dos recursos do Git, incluindo suporte para:

  • Repositórios remotos: facilitando a interação entre as equipes distribuídas.
  • Ferramentas de colaboração: fornecendo recursos como problemas, discussões, solicitações de pull, notificações, rótulos, ações, bifurcações, wikis e projetos.
  • Interface baseada na Web: minimizando a necessidade de usar comandos git
  • Proteção de ramificação: impor condições que devem ser atendidas antes que uma mesclagem possa ocorrer (como, por exemplo, revisões de solicitação de pull concluídas).