Artigo original: Learn the Basics of Git in Under 10 Minutes
Escrito por: Gowtham Venkatesan
Sim, o título é clickbait. Não tem como entender o básico da tecnologia do Git em apenas 10 minutos. Mas você pode chegar bem perto disso em cerca de 25 minutos. Esse é o objetivo deste artigo.
Se quer começar a aprender sobre a tecnologia do Git, você veio ao lugar certo. Este é um guia abrangente para iniciantes no Git. Existem muitos clients para Git. A tecnologia é a mesma, não importando o client. Neste guia, porém, usaremos o GitHub para entender o Git.
Vamos começar!
O que é o controle de versão?
O controle de versão é um sistema que registra alterações em um arquivo ou conjunto de arquivos ao longo do tempo para que você possa recuperar versões específicas posteriormente. Então, idealmente, podemos colocar qualquer arquivo que esteja no computador dentro do controle de versão.
Umm… certo… mas para que fazer isso?
Esse é o motivo:
Um Sistema de Controle de Versão (VCS) permite que você reverta arquivos de volta a um estado anterior, reverta todo o projeto de volta a um estado anterior, revise as alterações feitas ao longo do tempo, veja quem modificou pela última vez algo que possa estar causando um problema, quem introduziu um problema e quando e muito mais. Usar um VCS também significa que, se você estragar tudo ou perder arquivos, geralmente conseguirá recuperar tudo facilmente. Às vezes, você só quer saber "quem escreveu essa porcaria", e ter acesso a essa informação vale a pena.
O que é o Git?
Git é um sistema de controle de versão para rastrear alterações em arquivos de computador e coordenar o trabalho nesses arquivos entre várias pessoas. Git é um sistema de controle de versão distribuído. Portanto, ele não depende necessariamente de um servidor central para armazenar todas as versões dos arquivos de um projeto. Em vez disso, cada usuário "clona" uma cópia de um repositório (uma coleção de arquivos) e tem o histórico completo do projeto em seu próprio disco rígido. Esse clone tem todos os metadados do original enquanto o próprio original é armazenado em um servidor auto-hospedado ou em um serviço de hospedagem de terceiros, como o GitHub.
O Git ajuda você a acompanhar as alterações feitas em seu código. É basicamente a guia de histórico do seu editor de código (sem modo de navegação anônima). Se, a qualquer momento durante a codificação, você encontrar um erro fatal e não souber o que está causando isso, você sempre poderá voltar ao estado estável. Por isso, é muito útil para depuração (debugging). Ou você pode simplesmente ver quais alterações você fez no seu código ao longo do tempo.
No exemplo acima, os três cartões representam versões diferentes do mesmo arquivo. Podemos selecionar qual versão do arquivo queremos usar a qualquer momento. Assim, posso pular para qualquer versão do arquivo na linha do tempo do git.
O Git também ajuda a sincronizar o código entre várias pessoas. Então, imagine que você e seu amigo estão colaborando em um projeto. Vocês dois estão trabalhando nos mesmos arquivos do projeto. O Git pega essas alterações que você e seu amigo fizeram de forma independente e as mescla em um único repositório "master"/"main". Portanto, usando o Git, você pode garantir que ambos estejam trabalhando na versão mais recente do repositório. Assim, você não precisa se preocupar em enviar seus arquivos uns para os outros e trabalhar com um número absurdo de cópias do arquivo original. Colaborar à distância se torna tão fácil quanto escrever em HTML.
Fluxo de trabalho do Git:
Antes de começar a trabalhar com os comandos do Git, é preciso entender o que eles representam.
O que é um repositório do Git?
Um repositório (também conhecido por "repo") nada mais é do que uma coleção de código-fonte.
Existem quatro elementos fundamentais no fluxo de trabalho do Git.
Diretório de trabalho, área de "staging", repositorio local e repositório remoto.
Se você pensar em um arquivo no seu diretório de trabalho, ele pode estar em três estados diferentes.
- Staged: significa que os arquivos com as alterações atualizadas estão marcados para serem confirmados no repositório local, mas ainda não foram confirmados.
- Modificado: significa que os arquivos com as alterações atualizadas ainda não estão armazenados no repositório local.
- Confirmado: significa que as alterações feitas em seu arquivo estão armazenadas com segurança no repositório local.
git addé um comando usado para adicionar um arquivo que está no diretório de trabalho à área de teste (staging).git commité um comando usado para adicionar todos os arquivos que estão na área de staging no repositório local.git pushé um comando usado para adicionar todos os arquivos confirmados no repositório local ao repositório remoto. Portanto, no repositório remoto, todos os arquivos e alterações estarão visíveis para qualquer pessoa com acesso ao repositório remoto.git fetché um comando usado para obter arquivos do repositório remoto para o repositório local, mas não para o diretório de trabalho.git mergeé um comando usado para obter os arquivos do repositório local para o diretório de trabalho.git pullé o comando usado para obter arquivos do repositório remoto diretamente no diretório de trabalho. É equivalente a umgit fetche umgit merge.
Agora que sabemos o que é o Git e suas terminologias básicas, vamos ver como podemos colocar um arquivo no Git.
Vamos fazer do jeito certo e do jeito difícil. Sem nenhuma aplicação de GUI.
Estou assumindo que você já tenha um arquivo que deseja colocar sob controle de versão. Caso não tenha nenhum arquivo, crie uma pasta de teste com o nome 'MuskCult' e adicione algum arquivo de código nele.
Passo 0: faça uma conta no GitHub. Dã.
Se você ainda não tem uma, você pode criar a sua aqui.
Passo 1: certifique-se que você tem o Git instalado na sua máquina.
Se você é usuário Mac, abra o terminal e digite o seguinte comando:
$ git --versionIsso solicitará a abertura de um instalador se você ainda não tiver o Git. Então, configure-o usando o instalador. Se você já tiver o Git, ele apenas mostrará qual versão do Git você instalou.
Se você é usuário Linux(deb), digite o seguinte comando no terminal:
$ sudo apt install git-allSe você está no Windows:
$ compre um macBrincadeira… calma… a quantidade de gente brava comigo agora… poxa vida…
Vá nesse link ou nesse link para mais informações.
Passo 2: diga ao Git quem você é.
Apresente-se. Sério, mencione seu nome de usuário e endereço de e-mail ao Git, já que todo commit do Git usará essas informações para identificar você como autor.
$ git config --global user.name "SEU_NOME_DE_USUÁRIO"
$ git config --global user.email "seu_email@email.com"
$ git config --global --list # Para conferir as informações que você acaba de fornecer
Passo 3: gere/verifique se sua máquina tem chaves SSH pré-existentes. (Opcional)
Por quê? Ao usar o protocolo SSH, você pode se conectar e autenticar com servidores e serviços remotos. Com chaves SSH, você pode se conectar ao GitHub sem fornecer seu nome de usuário ou senha a cada visita.
Para aprender mais sobre SSH, clique neste link.
Clique aqui para checar se você tem uma chave SSH.
Clique aqui para gerar uma chave SSH.
Clique aqui para adicionar a chave SSH à sua conta GitHub.
Por fim, clique aqui para testar sua conexão.
Se você de fato configurou seu SSH, substitua todos os comandos git que tenham um link por:
Em vez de : https://github.com/nome_do_usuário/nome_do_repositório
Use : git@github.com:nome_do_usuário/nome_do_repositório.git
Obs, : você pode usar qualquer uma das maneiras. Você escolhe.Eu usarei o protocolo SSH neste tutorial.
Passo 4: hora de usar o Git
Crie um novo repositório no GitHub. Siga este link. Agora, localize a pasta que você deseja colocar no Git no seu terminal.
$ cd Desktop/MuskCultInicialize o Git:
E para colocar algo no Git, digite:
$ touch README.md # Para criar um arquivo README no repositório
$ git init # Inicia um repositório do Git vazio
Agora, edite o arquivo README.md para fornecer informações sobre o repositório.
Adicione arquivos à área de staging para confirmação:
Para adicionar os arquivos ao repositório do Git para confirmação:
$ git add .
# Adiciona todos os arquivos no repositório local na área de staging para o commit
OU se quiser adicionar um arquivo específico
$ git add README.md
# Para adicionar o arquivo específicoAntes de confirmar, vamos ver quais arquivos estão em staging:
$ git status # Lista todos os arquivos novos ou modificados que farão parte do commit
Faça o commit das mudanças que você fez no seu repositório do Git:
Agora, para confirmar os arquivos que você adicionou ao repositório do Git:
$ git commit -m "Primeiro commit"
# A mensagem entre aspas (" ") é fornecida para que outros usuários possam lê-la e ver que mudanças você fez
Retirar de um commit as mudanças que você fez no seu repositório do Git:
Agora, imagine que você acabou de cometer algum erro no seu código ou colocou um arquivo indesejado dentro do repositório. Você pode remover os arquivos que acabou de adicionar usando:
$ git reset HEAD~1
# Remove o commit mais recente
# Faça o commit novamente depois de ajustar!
Adicione uma "origem" remota e faça um push:
Uma coisa importante: toda vez que você fizer alterações em seus arquivos e salvá-los, eles não serão atualizados automaticamente no GitHub. Todas as alterações que fizemos no arquivo são atualizadas no repositório local. Agora, para atualizar as alterações no repositório "master"/"main":
$ git remote add origin URL_do_repositório_remoto
# Define o novo repositório remotoO comando git remote permite que você crie, visualize e exclua conexões com outros repositórios.
$ git remote -v
# Lista as conexões remotas que você tem com outros repositórios.O comando git remote -v lista os URLs de conexões remotas que você tem com outros repositórios.
$ git push -u origin master # faz o push das alterações para "origin"O comando git push envia as alterações em seu repositório local para o repositório remoto que você especificou como origem (em inglês, origin).
E agora, se formos verificar nossa página de repositório no GitHub, ela deve ser algo assim:
E é isso. Você acabou de adicionar os arquivos ao repositório que acabou de criar no GitHub.
Verifique as mudanças que você fez em seu arquivo:
Depois de começar a fazer alterações em seus arquivos e salvá-los, o arquivo não corresponderá à última versão que foi confirmada no Git por meio de um commit. Para ver as alterações que você acabou de fazer:
$ git diff # Mostra as alterações de arquivos que ainda não estão em staging
Revertendo para a última versão confirmada para o repositório do Git:
Agora, você pode optar por reverter para a última versão confirmada por commit digitando:
$ git checkout .
OU se quiser fazer isso para um arquivo específico
$ git checkout -- <nome_do_arquivo>
Visualizando o histórico de commits:
Você pode usar o comando git log para ver o histórico de commits que você fez nos seus arquivos:
$ git log
Cada vez que você faz mudanças que você deseja que estejam presentes no GitHub, o fluxo de comandos a seguir é o mais comum:
$ git add .
$ git status # Lista todos os arquivos novos ou modificados que farão parte do commit
$ git commit -m "Segundo commit"
$ git push -u origin master
Agora, se formos ver nosso repositório, podemos identificar se o commit foi bem-sucedido observando a mensagem de commit de cada arquivo.
Passo 5 : muito bem, mas... como eu faço o download e trabalho com outros repositórios do GitHub?
Clonando um repositório do Git:
Localize o diretório em que deseja clonar o repositório. Copie o link do repositório desejado e digite:
$ git clone URL_do_repositório_remotoSinta-se à vontade para clonar o repositório que criei acima usando: https://github.com/Gothamv/MuskCult
Fazendo o push das alterações para o repositório do Git:
Agora, você pode trabalhar nos arquivos que deseja e fazer o commit das alterações localmente. Se quiser enviar as mudanças para um repositório, precisa ser adicionado como um colaborador do repositório ou criar algo conhecido como "pull request". Você pode verificar como elas são feitas aqui e me enviar um pull request com seu arquivo de código.
Colaborando:
Imagine que você e seu amigo estão colaborando em um projeto. Vocês dois estão trabalhando nos mesmos arquivos de projeto. Cada vez que você faz algumas alterações e as envia para o repositório master/main, seu amigo precisa extrair as alterações que você enviou para o repositório do Git. Ou seja, para garantir que vocês estarão trabalhando na versão mais recente do repositório do Git toda vez que você começar a trabalhar, um comando git pull será necessário.
Abaixo temos um exemplo de um projeto em que meu amigo e eu estamos colaborando:
Portanto, para garantir que essas alterações sejam refletidas na minha cópia local do repositório:
$ git pull origin master
Aqui estão mais dois comandos úteis do Git:
$ git fetch
E
$ git mergeDe forma simplificada, git fetch seguido por um git merge é igual a git pull. Mas, então, por que eles existem?
Quando você usa git pull, o Git tenta automaticamente fazer seu trabalho por você. Ele percebe o contexto, então o Git mesclará quaisquer commits cujo pull foi realizado na branch em que você está trabalhando no momento. git pull mescla automaticamente os commits sem que você precise revisá-los primeiro.
Quando você usa git fetch, o Git reúne todos os commits da branch de destino que não existem em sua branch atual e os armazena em seu repositório local. No entanto, ele não os mescla com sua branch atual. Isso é particularmente útil se você precisar manter seu repositório atualizado, mas estiver trabalhando em algo que pode quebrar se você atualizar seus arquivos. Para integrar os commits em sua branch master, use git merge.
Para concluir:
.gitignoreO que é isso?
O .gitignore diz ao Git quais arquivos (ou padrões) ele deve ignorar. Geralmente, ele é usado para evitar o commit de arquivos transitórios do seu diretório de trabalho que não são úteis para outros colaboradores, como produtos de compilação, arquivos temporários criados pelas IDEs, etc.
Assim, no exemplo acima, arquivos como __pycache__ e .DS_Store são usados pelo sistema para armazenar informações para acesso mais rápido. Eles não são úteis para os outros colaboradores. Então, podemos dizer ao Git para ignorá-los adicionando-os a um arquivo .gitignore.
Use o comando touch (no Linux ou no Mac) para criar o arquivo .gitignore:
$ touch .gitignoreVocê pode adicionar ao .gitignore os seguintes padrões para dizer ao Git para ignorar esses arquivos.
/*.cmake
/*.DS_Store
/.user
/build
etc. dependendo dos arquivos que você quer que o Git não acompanheÉ basicamente isso que tínhamos sobre o básico do Git. Fique atento à parte 2, que se concentrará em branch, merge, stash, rebase e outros.
Se você gostou do artigo, não se esqueça de compartilhar com quem puder e quiser e de seguir o autor para saber quando chegar a parte 2.
Referências:
Adicionando o código localmente hospedado no GitHub - documentação do usuário
How to undo (almost) anything with Git (texto em inglês)
Git on the commandline - Don't be afraid to commit 0.3 documentation (texto em inglês)
Start using Git on the command line | GitLab (texto em inglês)
What is the difference between 'git pull' and 'git fetch'? (texto em inglês)