Primeiros passos com Git: um guia detalhado para iniciantes

Em vez de uma introdução

Olá futuro Engenheiro de Software Sênior. Hoje falaremos sobre o sistema de controle de versão, ou seja, Git (leia-se como GIT, e não JIT, como pode parecer pela gramática inglesa). Sim, sim, eu sei que também existe Mercurial, SVN... Mas sejamos honestos: o tempo deles já passou e não vou desperdiçar seu precioso tempo com eles. Para que você entenda a importância de conhecer o Git em nossa época, direi o seguinte: sem conhecimento/entendimento disso você não tem nada para fazer em programação. Mas a beleza é que para trabalhar constantemente você não precisa ficar com todos os comandos e possibilidades na cabeça. Você precisa conhecer um conjunto de comandos que o ajudarão a entender tudo o que está acontecendo.

Noções básicas de Git

Git é um sistema de controle de versão distribuído para nosso código. Por que precisamos disso? Equipes distribuídas precisam de algum tipo de sistema de gerenciamento de trabalho. Necessário para rastrear mudanças que ocorrem ao longo do tempo. Ou seja, passo a passo vemos quais arquivos foram alterados e como. Isto é especialmente importante quando você analisa o que foi feito em uma tarefa: isso torna possível voltar atrás. Vamos imaginar uma situação: tinha um código funcionando, estava tudo bem nele, mas resolvemos melhorar alguma coisa, ajustar aqui, ajustar ali. Estava tudo bem, mas essa melhoria quebrou metade da funcionalidade e impossibilitou o trabalho. Então, o que vem a seguir? Sem o Gita, teríamos que sentar por horas e lembrar como tudo era originalmente. E então voltamos para o commit e pronto. Ou e se houver dois desenvolvedores fazendo alterações no código ao mesmo tempo? Sem o Git fica assim: eles copiaram o código do original e fizeram o que precisavam fazer. Chega o momento e ambos querem adicionar suas alterações à pasta principal. E o que fazer nessa situação?.. Nem me atrevo a estimar o tempo para fazer esse trabalho. Não haverá tais problemas se você usar o Git.

Instalando o Git

Vamos instalar o Git no seu computador. Entendo que cada pessoa tem sistemas operacionais diferentes, então tentarei descrever vários casos.

Instalação para Windows

Como de costume, você precisa baixar o arquivo exe e executá-lo. Tudo é simples aqui: clique no primeiro link do Google , instale e pronto. Para trabalhar, usaremos o console bash que eles fornecem. Para funcionar no Windows, você precisa executar o Git Bash. É assim que fica no menu iniciar: E este já é um console no qual você pode trabalhar. Para não ir sempre para a pasta com o projeto para abrir o git lá, você pode clicar com o botão direito na pasta para abrir o console com o caminho que precisamos:

Instalação para Linux

Normalmente o git já vem instalado e incluído nas distribuições Linux, pois é uma ferramenta originalmente escrita para desenvolver o kernel Linux. Mas há situações em que isso não existe. Para verificar isso, você precisa abrir um terminal e digitar: git --version. Se houver uma resposta clara, não há necessidade de instalar nada. Abra um terminal e instale. Eu trabalho no Ubuntu, então posso te dizer o que escrever para ele: sudo apt-get install git. E é isso: agora você pode usar o Git em qualquer terminal.

Instalação no macOS

Aqui também, primeiro você precisa verificar se o Git já existe (veja acima, como no Linux). Caso contrário, a maneira mais fácil é baixar a versão mais recente. Se o XCode estiver instalado, o Git será definitivamente instalado automaticamente.

Configuração do Git

O git possui uma configuração de usuário a partir da qual o trabalho será realizado. Isso é algo razoável e necessário, pois quando um commit é criado, o Git leva exatamente essa informação para o campo Autor. Para configurar um nome de usuário e senha para todos os projetos, você precisa inserir os seguintes comandos:

git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com

Se houver necessidade de alterar o autor de um projeto específico (para um projeto pessoal, por exemplo), você pode remover --global, e isso funcionará:

git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.com

Um pouco de teoria...

Para permanecer no assunto, é aconselhável adicionar algumas palavras e ações novas à sua mensagem... Caso contrário, não haverá nada para falar. Claro, isso é um jargão e uma cópia do inglês, então adicionarei significados em inglês. Que palavras e ações?

• repositório git;
• comprometer (comprometer);
• filial;
• mesclar;
• conflitos;
• puxar;
• empurrar;
• como ignorar alguns arquivos (.gitignore).

E assim por diante.

Estados no Git

O Gita possui vários estados que precisam ser compreendidos e lembrados:

• não rastreado;
• modificado;
• preparado (encenado);
• empenhado.

O que isso significa?

Estes são os estados em que os arquivos do nosso código estão localizados. Ou seja, sua trajetória de vida geralmente é assim:

1. Um arquivo criado e não adicionado ao repositório estará no estado não rastreado.
2. Fazemos alterações nos arquivos que já foram adicionados ao repositório Git - eles estão no estado modificado.
3. Dos arquivos que alteramos, selecionamos apenas aqueles (ou todos) que precisamos (por exemplo, não precisamos de classes compiladas), e essas classes com alterações entram no estado de teste.
4. Um commit é criado a partir dos arquivos preparados no estado de teste e vai para o repositório Git. Depois disso, o estado de teste fica vazio. Mas modificado ainda pode conter alguma coisa.

Fica assim (foto do documento oficial, então você pode confiar)):

O que é um commit

Um commit é o objeto principal no controle de versão. Ele contém todas as alterações desde aquele commit. Os commits são vinculados entre si como uma lista vinculada individualmente. A saber: existe o primeiro commit. Quando um segundo commit é criado, ele (o segundo) sabe que vem depois do primeiro. E desta forma você pode acompanhar as informações. O commit também possui suas próprias informações, os chamados metadados:

• um identificador de commit exclusivo pelo qual você pode encontrá-lo;
• o nome do autor do commit que o criou;
• data de criação do commit;
• um comentário que descreve o que foi feito durante este commit.

Isto é o que parece:

O que é um ramo

Um branch é um ponteiro para um commit. Como um commit sabe qual commit veio antes dele, quando um branch aponta para um commit, todos os anteriores também se referem a ele. Com base nisso, podemos dizer que pode haver tantos ramos apontando para o mesmo commit. O trabalho acontece nas ramificações, portanto, quando um novo commit é criado, a ramificação move seu ponteiro para o commit mais recente.

Introdução ao Git

Você pode trabalhar apenas com um repositório local ou remoto. Para elaborar os comandos necessários, você só pode usar o repositório local. Ele armazena todas as informações apenas localmente no projeto, na pasta .git. Se falamos de remoto, então todas as informações são armazenadas em algum lugar em um servidor remoto: apenas uma cópia do projeto é armazenada localmente, cujas alterações podem ser enviadas (git push) para o repositório remoto. Aqui e mais adiante discutiremos como trabalhar com git no console. Claro, você pode usar algumas soluções gráficas (por exemplo, no Intellij IDEA), mas primeiro você precisa descobrir quais comandos estão acontecendo e o que eles significam.

Trabalhando com Git em um repositório local

A seguir, sugiro que você siga todos os passos que fiz enquanto lia o artigo. Isso melhorará sua compreensão e retenção do material. Então, bom apetite :) Para criar um repositório local, você precisa escrever:

git init

Isso criará uma pasta .git no local onde o console está localizado. .git é uma pasta que armazena todas as informações sobre o repositório Git. Não há necessidade de excluí-lo ;) Em seguida, os arquivos são adicionados a este projeto e seu status se torna Não rastreado. Para ver qual é o status atual do trabalho, escreva:

git status

Estamos no ramo master e até passarmos para outro, tudo permanecerá assim. Dessa forma, você pode ver quais arquivos foram alterados, mas ainda não foram adicionados ao estado de teste. Para adicioná-los ao estado de teste, você precisa escrever git add. Pode haver várias opções aqui, por exemplo:

• git add -A – adiciona todos os arquivos do estado de teste;
• adicione. — adicione todos os arquivos desta pasta e todos os internos. Essencialmente igual ao anterior;
• git add <filename> - adiciona apenas um arquivo específico. Aqui você pode usar expressões regulares para adicionar de acordo com algum padrão. Por exemplo, git add *.java: isso significa que você só precisa adicionar arquivos com a extensão java.

É claro que as duas primeiras opções são simples, mas com a adição ficará mais interessante, por isso escrevemos:

git add *.txt

Para verificar o status, usamos o comando que já conhecemos:

git status

A partir disso podemos ver que a expressão regular funcionou corretamente e agora test_resource.txt está em um estado de teste. E por fim, a última etapa (com repositório local, com remoto haverá mais um ;)) - commit e crie um novo commit:

git commit -m “all txt files were added to the project”

A seguir, há um ótimo comando para ver o histórico de commits de um branch. Vamos usá-lo:

git log

Aqui você já pode ver que apareceu nosso primeiro commit com o texto que transferimos. É muito importante entender que o texto que passamos deve definir com a maior precisão possível o que foi feito durante esse commit. Isso ajudará muitas vezes no futuro. Um leitor curioso que ainda não adormeceu pode dizer: o que aconteceu com o arquivo GitTest.java? Agora vamos descobrir, use para isso:

git status

Como podemos ver, ele permanece no estado não rastreado e está esperando nos bastidores. Ou talvez não queiramos adicioná-lo ao projeto? As vezes acontece. A seguir, para torná-lo mais interessante, vamos tentar alterar nosso arquivo de texto test_resource.txt. Vamos adicionar algum texto lá e verificar o status:

git status

Aqui você pode ver claramente a diferença entre os dois estados - não rastreado e modificado. GitTest.java está no estado não rastreado e test_resource.txt está no estado modificado. Agora que já existem arquivos no estado modificado, podemos ver as alterações que foram feitas neles. Isso pode ser feito usando o comando:

git diff

Ou seja, você pode ver claramente aqui que adicionei olá mundo! ao nosso arquivo de texto. Adicione alterações ao arquivo de texto e confirme:

git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”

Para ver todos os commits, escreva:

git log

Como você pode ver, já existem dois commits. Da mesma forma, adicionamos GitTest.java. Agora sem comentários, apenas comandos:

git add GitTest.java
git commit -m “added GitTest.java”
git status

Trabalhando com .gitignore

É claro que queremos armazenar apenas o código fonte e nada mais no repositório. O que mais poderia ser? No mínimo, classes e/ou arquivos compilados que criam ambientes de desenvolvimento. Para que o Git os ignore, há um arquivo especial que precisa ser criado. Fazemos isso: criamos um arquivo na raiz do projeto chamado .gitignore, e neste arquivo cada linha será um padrão a ser ignorado. Neste exemplo, git ignore ficaria assim:

```
*.class
target/
*.iml
.idea/
```

Vejamos agora:

• a primeira linha é ignorar todos os arquivos com extensão .class;
• a segunda linha é ignorar a pasta de destino e tudo o que ela contém;
• a terceira linha é ignorar todos os arquivos com extensão .iml;
• A quarta linha é ignorar a pasta .idea.

Vamos tentar com um exemplo. Para ver como isso funciona, vamos adicionar a classe GitTest.class compilada ao projeto e ver o status do projeto:

git status

Claramente, não queremos adicionar acidentalmente (se usarmos git add -A) uma classe compilada ao projeto. Para fazer isso, crie um arquivo .gitignore e adicione tudo o que foi descrito anteriormente: Agora vamos adicionar git ignore ao projeto com um novo commit:

git add .gitignore
git commit -m “added .gitignore file”

E agora a hora da verdade: temos uma classe GitTest.class compilada em um estado não rastreado, que não queríamos adicionar ao repositório Git. É aqui que git ignore deve funcionar:

git status

Tudo está claro) Git ignore +1)

Trabalhando com filiais e similares

É claro que trabalhar em uma filial é inconveniente e impossível quando há mais de uma pessoa na equipe. Existe um ramo para isso. Como eu disse antes, um branch é simplesmente um ponteiro móvel para commits. Nesta parte, veremos como trabalhar em diferentes ramos: como mesclar alterações de um ramo para outro, quais conflitos podem surgir e muito mais. Para ver uma lista de todas as ramificações do repositório e entender em qual delas você está, você precisa escrever:

git branch -a

Você pode ver que temos apenas um branch master, e o asterisco na frente dele indica que estamos nele. Aliás, para saber em qual branch estamos, também podemos usar a verificação de status (git status). A seguir, existem várias opções para criação de ramificações (talvez haja mais, eu uso estas):

• criar uma nova filial baseada naquela em que estamos (99% dos casos);
• crie um branch baseado em um commit específico (1%).

Crie um branch baseado em um commit específico

Contaremos com o identificador de commit exclusivo. Para encontrá-lo, escrevemos:

git log

Destaquei o commit com o comentário “adicionei olá mundo...”. Possui um identificador exclusivo - “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Quero criar um branch de desenvolvimento a partir deste commit. Para isso vou escrever:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

É criado um branch que contém apenas os dois primeiros commits do branch master. Para testar isso, primeiro vamos nos certificar de que mudamos para outro branch e observar o número de commits nele:

git status
git log

E é verdade: descobrimos que temos dois commits. A propósito, um ponto interessante: ainda não existe um arquivo .gitignore neste branch, então nosso arquivo compilado (GitTest.class) agora está destacado no estado não rastreado. Agora podemos revisar nossos ramos novamente escrevendo:

git branch -a

Percebe-se que existem dois ramos - master e desenvolvimento - e agora estamos em desenvolvimento.

Crie um branch baseado no atual

A segunda maneira de criar um branch é construir em outro. Quero criar um branch baseado no branch master, então preciso mudar para ele primeiro, e o próximo passo é criar um novo. Vamos olhar:

• git checkout master - vá para o branch master;
• git status - verifique se está no master.

Aqui você pode ver que mudamos para o branch master, git ignore já está funcionando aqui e a classe compilada não aparece mais como não rastreada. Agora criamos um novo branch baseado no branch master:

git checkout -b feature/update-txt-files

Se você tiver alguma dúvida de que este branch não será igual ao master, você pode facilmente verificar isso escrevendo git log e olhando todos os commits. Deveria haver quatro deles.

Resolver conflitos

Antes de entendermos o que é um conflito, precisamos falar sobre fundir (mesclar) um ramo em outro. Esta imagem pode mostrar o processo quando uma ramificação é mesclada com outra: ou seja, existe uma ramificação principal. Em algum momento, é criado um secundário a partir dele, no qual ocorrem mudanças. Depois que o trabalho estiver concluído, você precisará mesclar uma ramificação em outra. Não descreverei vários recursos: quero transmitir apenas o entendimento dentro da estrutura deste artigo, e você mesmo descobrirá os detalhes, se necessário. Então, em nosso exemplo, criamos o branch feature/update-txt-files. Como está escrito no nome da agência, atualizaremos o texto. Agora você precisa criar um novo commit para este assunto:

git add *.txt 
git commit -m “updated txt files”
git log

Agora, se quisermos mesclar o branch feature/update-txt-files no master, precisamos ir para master e escrever git merge feature/update-txt-files:

git checkout master
git merge feature/update-txt-files
git log

Como resultado, agora o branch master também possui um commit que foi adicionado a feature/update-txt-files. Esta funcionalidade é adicionada para que você possa excluir a ramificação do recurso. Para fazer isso escrevemos:

git branch -D feature/update-txt-files

Até agora está claro, certo? Vamos complicar a situação: agora digamos que precisamos alterar novamente o arquivo txt. Mas agora este arquivo também será alterado no assistente. Ou seja, isso mudará em paralelo e o Git não conseguirá entender o que precisa ser feito em uma situação em que queremos mesclar o novo código no branch master. Ir! Criamos um novo branch baseado em master, fazemos alterações em text_resource.txt e criamos um commit para este assunto:

git checkout -b feature/add-header
... делаем изменения в файле

git add *.txt
git commit -m “added header to txt”

Vá para o branch master e atualize também este arquivo de texto na mesma linha do branch feature:

git checkout master
… обновor test_resource.txt

git add test_resource.txt
git commit -m “added master header to txt”

E agora o momento mais interessante: você precisa mesclar as alterações do branch feature/add-header para master. Estamos no branch master, então tudo que precisamos fazer é escrever:

git merge feature/add-header

Mas obteremos um resultado com um conflito no arquivo test_resource.txt: E aqui podemos ver que o Git não conseguiu decidir de forma independente como mesclar esse código e diz que primeiro devemos resolver o conflito e só então fazer um commit. Ok, vamos abrir o arquivo que contém o conflito em um editor de texto e ver: Para entender o que o git fez aqui, você precisa lembrar o que escrevemos onde e comparar:

1. entre “<<<<<<< HEAD” e “=======” estão as alterações master que estavam nesta linha no branch master.
2. entre “=======” e “>>>>>>> feature/add-header” há mudanças que estavam no ramo feature/add-header.

Assim, Git mostra que neste ponto ele não conseguiu descobrir como mesclar esse arquivo, dividiu esta seção em duas partes de ramos diferentes e sugeriu que decidíssemos por nós mesmos. Ok, com muita vontade decido remover tudo, deixar apenas a palavra cabeçalho: Vamos ver o status das alterações, a descrição será um pouco diferente. Não haverá estado modificado, mas não mesclado. Então poderíamos adicionar com segurança um quinto estado... Mas acho que isso é desnecessário, vejamos:

git status

Estávamos convencidos de que este era um caso diferente e incomum. Vamos continuar:

git add *.txt

Na descrição você notará que eles apenas sugerem escrever git commit. Nós ouvimos e escrevemos:

git commit

E isso é tudo: foi assim que fizemos - resolvemos o conflito no console. Claro que em ambientes de desenvolvimento você pode fazer isso um pouco mais fácil, por exemplo, no Intellij IDEA tudo está tão bem configurado que você pode realizar todas as ações necessárias nele. Mas o ambiente de desenvolvimento faz muitas coisas nos bastidores e muitas vezes não entendemos exatamente o que aconteceu lá. E quando não há compreensão, podem surgir problemas.

Trabalhando com repositórios remotos

A última etapa é entender mais alguns comandos necessários para trabalhar com um repositório remoto. Como já disse, um repositório remoto é algum lugar onde o repositório está armazenado e de onde você pode cloná-lo. Que tipos de repositórios remotos existem? Existem muitos exemplos:

• GitHub é o maior repositório para repositórios e desenvolvimento colaborativo. Já descrevi isso em artigos anteriores.
  Inscreva-se na minha conta do Github . Muitas vezes exponho meu trabalho lá nas áreas que estudo durante meu trabalho.

• GitLab é uma ferramenta de ciclo de vida DevOps de código aberto baseada na web que fornece um sistema de gerenciamento de repositório de código para Git com seu próprio wiki, sistema de rastreamento de problemas , pipeline de CI/CD e outros recursos.
  Após a notícia de que a Microsoft comprou o GitHub, alguns desenvolvedores duplicaram seu trabalho no GitLab.

• BitBucket é um serviço web para hospedagem de projetos e seu desenvolvimento conjunto, baseado no sistema de controle de versão Mercurial e Git. Ao mesmo tempo, ele tinha uma grande vantagem sobre o GitHub, pois tinha repositórios privados gratuitos. No ano passado, o GitHub também disponibilizou esse recurso gratuitamente para todos.

• E assim por diante…

A primeira coisa que você precisa fazer ao trabalhar com um repositório remoto é clonar o projeto em seu local. Para este caso, exportei o projeto que fizemos localmente e agora todos podem cloná-lo escrevendo:

git clone https://github.com/romankh3/git-demo

Agora existe uma cópia completa do projeto localmente. Para ter certeza de que a cópia mais recente do projeto está localizada localmente, você precisa, como dizem, despejar os dados escrevendo:

git pull

No nosso caso, nada mudou remotamente agora, então a resposta é: já está atualizado. Mas se eu fizer algumas alterações no repositório remoto, o local será atualizado após extraí-los. E, finalmente, o último comando é enviar dados para o repositório remoto. Quando fazemos algo localmente e queremos transferi-lo para um repositório remoto, devemos primeiro criar um novo commit localmente. Para fazer isso, vamos adicionar algo mais ao nosso arquivo de texto: Agora é algo comum para nós - criamos um commit para este assunto:

git add test_resource.txt
git commit -m “prepated txt for pushing”

E agora o comando para enviar isso para o repositório remoto:

git push

Isso é tudo que eu queria te contar. Obrigado pela sua atenção. Inscreva-se na minha conta GitHub , onde posto diversos exemplos de projetos interessantes do que estudo e uso no trabalho.

Links Úteis

• O documento oficial do Git está em russo . Eu o recomendo como um guia de referência.
• Git