O funcionamento é bastante simples. Vou explicar o workflow e, logo em seguida (nas partes seguintes desta série), como aplicá-lo.

A princípio, é criado e inicializado um repositório git (quando este repositório for criado, você talvez perceba o surgimento de uma pasta oculta chamada .git – não mexa em nada dentro dela, pois são arquivos que devem ser gerenciados pela própria ferramenta). Em seguida, você pode ir criando arquivos. Contudo, estes arquivos ainda não estão sendo rastreados (na staged/staging area) pelo git e deverão ser adicionadas posteriormente para que a ferramenta possa trabalhar apropriadamente.

Uma vez que estes arquivos estão sendo rastreados, você poderá confirmar alterações (é o que chamamos de “commit“, do verbo “comitar” – risos). Estes arquivos comitados poderão ser “empurrados” (você fará um pushgrave este termo) para um servidor remoto (seja Github, Gitlab, Bitbucket ou o seu servidor local).

Agora, imagine que entrou mais uma pessoa no time. Como ela poderia ter acesso ao conteúdo do projeto? É simples, ela vai realizar uma clonagem deste projeto em sua máquina para que possa trabalhar, realizar suas alterações, comitar e empurrar para o servidor. Talvez você tenha se perguntado: “Eita, mas como irei manter o projeto atualizado se eu e esta outra pessoa estamos trabalhando em estações diferentes?”. Para resolver este problema, existe a possibilidade de você “puxar” (você fará um pulltambém grave este termo!) o que está no servidor. Ou seja, de tempos em tempos você deverá solicitar a última versão do projeto. Uma rotina que alguns usuários costumam seguir é a de realizar um pull ao início do trabalho e fazer um push ao término.

Agora imagine se, além de trabalhar com o mesmo arquivo, você e seu colega estão trabalhando no mesmo trecho de código/texto. O que aconteceria se você e ele tentassem realizar o push no servidor? Haveria sobrescrita? Você perderia o que fez? Não! O Git irá lhe comunicar que há um conflito no conteúdo do seu push em relação ao de seu colega. Desta forma, ele permitirá que o último a realizar o push possa integrar ambas alterações para criar um arquivo corrigido (é o que chamamos de merge).

 

Recapitulando, os arquivos do seu diretório de trabalho (working directory) precisam ser adicionados em uma área de rastreio (staging/staged area) que será confirmada para o repositório (commit). Este conteúdo “commitado” poderá ser empurrado (push) para um servidor remoto para que outras pessoas possam replicá-lo em suas máquinas (clone) e tanto você quanto estas pessoas possam estar enviando atualizações, além de atualizar o seu projeto (pull) também, claro.

Leia também a parte um.

Deixe uma resposta