Git_manual

Prévia do material em texto

Manual Git
Básico
O que é o Git e Github ?
 Imagine que você é um jornalista e está escrevendo uma máteria para o jornal, para isso você conta com a 
colaboração do seu editor que avalia o rascunho inicial de um determinado assunto, após essa análise ele 
aponta algumas coisas que precisam ser corrigidas, com esse feedback você corrige o seu rascunho e envia 
novamente para o seu editor. Após repetir esse processo várias vezes você finalmente teve a aprovação dele, 
mas perceba que você guardou uma cópia de cada rascunho feito, você teria algo similar a figura a seguir:
 O modo como o trabalho foi feito facilitou a colaboração entre a equipe, além de permitir uma análise de 
versões mais antigas, podemos perceber que o texto começou de uma maneira e acabou de outra, até mesmo o 
formato do arquivo mudou quando o editor aprovou.
 Da mesma forma, durante um desenvolvimento de um projeto é preciso que a equipe colabore entre si em busca 
de uma colaboração perfeita, muitas vezes os colaboradores moram em países totalmente diferentes. Assim 
manter informações sobre o arquivo e suas versões é muito importante. Podemos ter algo como a figura a 
seguir:
w
Rascunho.docx Versões antigas que foram
avaliadas por seu editor
Versão mais recente
avaliada pelo editorw
Rascunho2.docx
Você
Versão X
src/
Editor
w
Rascunho3.docx
PDF
Final.pdf
PHP
index.php
</>
header.html
Versão Y
src/
PHP
PNG
index.php
</>
header.html
img1.png
img/
1
 Foi com esse proposito que Linus Torvalds criou o Git, com o próposito de gerenciar as diferentes versões de um 
software, bem como facilitar a colaboração entre colegas de equipe que muitas vezes editavam a mesma linha 
de código ao mesmo tempo.
 Essa necessidade nasceu pela dificuldade de versionar o Kernel do Linux e que fosse complexo o suficiente para 
comportar multiplos editores.
 Já conseguimos entender a importância de um gerenciador de versões, entretanto seria necessário que todos os 
colaboradores tivessem acesso a um único repositorio para que isso acontecesse, e foi com esse propósito que 
outras empresas, como o GitHub, surgiram.
 No entanto vale ressaltar que existe uma grande diferença entre Git e GitHub, afinal o Git apenas cria versões e 
facilita a colaboração entre membros de uma mesma equipe que estejam desenvolvendo um software, por outro 
lado o GitHub armazena o projeto do Git de forma remota, possibilitando que você consiga acessar, adicionar, 
alterar e excluir arquivos não importa onde esteja, além de fazer sugestões para outros colaboradores 
2
Você sabe quem foi Linus Torvalds?
Linus Benedict Torvalds é um engenheiro de software finlandês, nascido em 
28 de dezembro de 1969, na cidade de Helsinki. Conhecer sua biografia é 
importante, já que ele é mundialmente conhecido por ter sido o criador do 
Kernel do Linux, base fundamental sobre a qual são construídos diversos 
sistemas operacionais gratuitos, como as distribuições Linux Ubuntu, 
Debian, Fedora e etc, além de produtos do Google, como o Chrome OS e o 
Android. Mais do que criador do Linux, Torvalds é um defensor do software 
livre e do código aberto, modelo em que o produto do desenvolvimento de 
programadores é liberado de forma gratuita para uso, modificação e, em 
alguns casos, exploração pela comunidade. Uma frase famosa de engenheiro 
é: “código aberto é o único jeito certo de se fazer software”. Fiel a essa 
visão, Torvalds continua envolvido no processo de desenvolvimento do Linux 
até hoje como integrante da Linux Foundation – instituição responsável pelo 
progresso do Kernel sobre o qual o sistema operacional é construído.
Fonte: 
https://www.techtudo.com.br/tudo-sobre/linus-torvalds.html#:~:text=Linus%20Benedict%20Torvalds%20%C3%A9%20um,1969%2C
%20na%20cidade%20de%20Helsinki.&text=Al%C3%A9m%20do%20Linux%2C%20o%20finland%C3%AAs,processo%20de%20testes%20e
%20compila%C3%A7%C3%B5es.
Onde o software fica salvo ?
 Também precisamos lembrar que o GitHub não é a única empresa que oferece esse serviço para guardar os 
repositórios, no entanto ela é opensource, permitindo que qualquer desenvolvedor crie projetos e colabore, o 
GitHub também possui pacotes pagos onde é possível deixar um projeto privado. Outra empresas que concorrem 
com o GitHub são: GitLab, GitBucket, etc.
 Alguns benefícios que podem ser listados ao utilizar o Git e GitHub em conjunto são:
 1- Controle de versão;
 2- Armazenamento em nuvem;
 3- Melhorar seu código;
 4- Trabalhar em equipe;
 5- Reconhecimento.
 Um conceito muito importante dentro do Git é o Secure Hash Algorithm (SHA), basicamente é um conjunto de 
funções hash criptógraficas projetadas pela Agência de segurança nacional dos EUA (NSA). O SHA por meio de 
um arquivo de texta gera um conjunto de caracteres com 40 digítos único, a simples mudança de uma vírgula em 
um arquivo faz a hash voltar totalmente diferente.
 Por esse motivo de identificar de forma única e segura um arquivo o Git faz uso do SHA1, por isso é perceptível 
essa hash nos códigos de versões de um software dentro do git.
 Outro conceito básico do Git são os objetos, o objeto mais basico é o blob, sendo um bloco básico contendo 
metadados como tamanho e data além do conteúdo, já a Tree é um objeto que armazena blobs, apontando ara 
diversos tipos de blobs ou outras trees, além de guardar os nomes do arquivo. Basicamente esses dois objetos 
são responsáveis pelo encapsulamento dos diretorios conforme a figura a seguir:
 Por fim temos o objeto commit, sendo o mais importante, pois ele junta tudo e dá sentido a alteração feita, 
assim ele aponta para uma tree, para o último commit antes dele, para um autor e por fim para uma mensagem. 
Desse modo é gerada uma hash única para todos esses arquivos, sinalizando quem fez essa mudança e o motivo. 
Por fim esse objeto também leva um timestamp, indicando a data e hora em que foi criado.
 É por esse motivo que o Git identifica mudanças em suas versões, pois a simples mudança em um arquivo altera 
a hash de um blob, que por sua vez altera a hash de uma árvore e finalmente altera o hash do commit.
3
Como o Git funciona por de baixo dos panos
tree
treeblob blob
README Rakefile Lib
Simplegit.rb
 Após baixar e instalar o Git a maquina estará pronta para aceitar os primeiros comandos no terminal do git 
bash, geralmente devemos começar o nosso repositório com o comando git init, a partir desse momento um 
diretório oculto chamado .git é criado, nele vai existir os objetos que o git utiliza para versionar.
 Com o Git iniciado em um diretório é possível adicionar arquivos dentro dele, em um projeto de software real 
esses arquivos e diretorios vão compor as funcionalidades do aplicativo. Um tipo de arquivo muito comum 
encontrado em repositorios contém a extensão .md, pois ele configura uma arquivo markdown, geralmente para 
auxiliar na utilização do código.
 Quando todos os arquivos de uma versão estão prontos o colaborador pode executar um comando chamado git 
add, ele serve para adicionar os arquivos em uma espécie de conteiner que será preparado para ser utilizado em 
um commit. Esse comando pode receber um conjunto de string para indicar qual arquivo está sendo adicionado, 
como por exemplo o README.MD, opcionalmente o colaborador pode usar o asterisco (*) como um caracter 
coringa, assim ele vai procurar qualquer arquivo que tenha pelo menos a sequencia de string passada, caso o 
asterisco seja passado sozinho o Git Bash irá adicionar todos os arquivos com alteração
4
Utilizando o Git
Você sabe o que é Markdown?
Desenvolvido em 2004 por John Gruber e Aaron Swartz para simplificar a estruturação de um texto, o 
Markdown é um sistema de formatação aberto que torna a escrita e a leitura mais simples. Com uma 
codificação mínima, além de fácil, ele é visualmente mais “limpo” e pode ser convertido facilmente 
para HTML.
Basicamente, ele marca alterações nos textos (subtítulos, negrito, itálico etc) apenas com os símbolos 
do teclado, sem usar teclas de atalho, menus, selecionando o textoe sem aquele visual complexo - para 
os que não estão acostumados - de HTML.
Para saber como utilizar ele acesse: 
https://rmiranda99.github.io/etc/tutorial-markdown/tutorial.html
PHP
index.php
.MD
README.MD
.TXT
read-rules.txt
Perceba que os arquivos read-rules.txt e README.MD foram ambos adicionadados mesmo tendo extensões diferentes, isso ocorre devido
a string passada para o comando conter o asterisco (*), assim ele buscou qualquer arquivo que tenha a expressão “read” no começo, o 
resultado foi que apenas o arquivo index.php não foi adicionado
 Quando o container estiver completo o colaborador precisará executar um comando chamado git commit, esse 
commit salva uma alteração no repositorio e marca ela na linha do tempo, dessa forma é possível retroceder 
para uma versão quando necessária. vale ressaltar que adicionalmente ao git commit é preciso passar como 
complemento a sintaxe a seguir: -m “mensagem”.
 Isso é importante para dar sentido a uma alteração, pois permite anexar uma mensagem de alteração, 
indicando as mudanças realizadas.
 Na parte anterior foi explicado comandos basicos como o git init, git add e git commit, entretanto o termo 
repositório foi usado algumas vezes sem uma explicação adequada, de fato ele vem a ser criado no momento em 
que um git init é utilizado.
 Para entender melhor um repositorio do git devemos entender que todos os itens dentro do repositorio podem 
variar de untracked e tracked (não rastreado e rastreado), dividindo o tracket em outros 3 agrupamentos 
conforme a figura a seguir:
 1: Nesse momento o arquivo foi criado dentro do repositório, então o Git não tem conhecimento de sua 
existencia, por isso ele é classificado como untracked, ou em português, não rastreado, entretando a partir do 
momento em que adicionamos ele por meio do git add movemos ele para staged, assim o Git passou a rastrear 
ele e está aguardando para que ele entre em ação por meio de um commit
2: O arquivo já faz parte de alguma versão do repositorio, por isso ele é listado como não modificado, mas a 
partir do momento em que ele é editado o git compara o seu código SHA1 e percebe a mudança, classificando ele 
como modificado.
3: O arquivo modificado é preparado para receber um commit ao ir para o estado de de staged por meio de um 
git add
4: Um arquivo já rastreado pelo git é removido, fazendo com que ele seja não rastreado
5: Todos os arquivos na área de palco (ou staged) recebem um commit e se ornão arquivos não modificados
5
Commit: 91924931
Autor: Vinícius
Mensagem: esse é o segundo commit
Data: 10/03/2021
Commit: 88d9c9924
Autor: Vinícius
Mensagem: primeiro commit
Data: 09/03/2021
O que é um repositório
Tracked
UnmodifiedUntracked Modified Staged
Adiciona o arquivo (1)
Edita o arquivo (2)
“Stage” o arquivo (3)
Remove o arquivo (4)
Commit (5)
 O repositório pode ser definido como ambiente de desenvolvimento ou como servidor, isso depende de onde ele 
está armazenado, por exemplo, em seu computador existe um repositorio local onde a suas mudificações não 
afetam em um primeiro momento os estados dos arquivos armazenados no servidor, observe o exemplo a seguir:
 Para facilitar o entendimento em que estágio os arquivos de um repositório estão o Git fornece um comando em 
que lista o estado atual de todo o repositório, para isso basta utilizar o git status.
 O git status retorna com o feedback “working tree clean” 
quando o diretório de trabalho está limpo, ou seja, ele 
interpreta que todos os arquivos do repositório estão 
rastreados como não modificados.
 Esse status geralmente retorna após um commit, já que não 
existe arquivos pendentes que precisam chegar a staging area
 Perceba que todos os arquivos não rastreados e 
modificados são trabalhados no working directory, sendo 
transferidos para a staging area após receberem o git 
add, mas é só depois do commit que ele efetivamente 
pertence ao seu repositorio local.
 Mesmo que o repositório local esteja conectado com o 
repositório remoto, as mudanças só serão visiveis após um 
comando especifico que vai empurrar os dados para o 
servidor.
6
WORKING
DIRECTORY
STAGING
AREA
LOCAL
REPOSITORY
REMOTE
REPOSITORY
Ambiente de desenvolvimento
Servidor
Árvore de trebalho vazia
Movido ou renomeado
 O feedback “new file” acontece quando ele encontra um 
arquivo na sessão untracked, pois ele ainda não rastreou ele, 
encarando assim como um novo documento que foi inserido no 
repositório e está aguardando um git add para ir até a staging 
area.
Novo arquivo
 O feedback “deleted” acontece quando o arquivo é removido 
do repositório, assim ele é movido da área unmodified para 
untracked, logo no próximo commit o repositório não vai 
salvar esse arquivo, já que ele não está sendo rastreado
 O arquivo que foi movido ou renomeado merece uma atenção 
especial, pois o Git está rastreando o arquivo pelo nome, a 
partir do momento que aquele arquivo mudou de nome ou 
diretorio o sistema operacional interpreta ele como um novo 
arquivo/diretorio, enquanto o antigo nome/diretorio foi 
“deletado”. Entretando, a partir do momento em que o arquivo 
volta a ser rastreado por meio do git add o status muda, 
passando a apresentar o feedback de “renamed”
 
Deletado
 Como citado anteriormente o Git foi feito para colaborar com outras pessoas além de versionar o código, por 
isso surgiu empresas como o GitHub que armazenam em seus servidores os repositórios, assim uma equipe de 
desenvolvedores conseguem empurrar modificações de um mesmo projeto para o mesmo local.
 Ao clicar em um novo repositório ele exibirá um formulário que vai requisitar o nome desse repositório, uma 
descrição, se ele será publico ou privado, se vai criar ou não um arquivo README.md inicial além de 
configurações mais anvaçadas que permitem escolher o estilo de licença (como a creative comuns) e ignorar 
alguns arquivos ao clonar um repositório conforme na próxima imagem.
 Vale ressaltar que os nomes escolhidos precisam ser únicos dentre outros repositórios já criado por você, além 
de evitar caracteres especiais (espaço, ç, *, !, @, #, $, %, etc), repositórios privados também exigem que o autor 
pague por ele
 Com a conta no GitHub criada o desenvolvedor pode criar um novo repositório clicando no botão new destacado 
em vermelho na imagem a baixo, além de verificar repositórios criados anteriormente na seção destacada em 
amarelo.
 Por fim, um dos status mais comuns é o “modified”, ele ocorre 
sempre que você alterar o conteúdo de um arquivo e salvar, 
assim ele deixa a área unmodified para o modified, para que 
esse status seja modificado ele vai precisar ser adicionado ou 
retornar para o seu estado original.
7
Arquivo modificado
 
GitHub
Você sabe configurar seu usuário no Git?
Com o objetivo de evitar problemas futuros recomenda-se que você configure o git com o mesmo nome 
de usuário e e-mail que você cadastrou no https://github.com/, para isso é necessário utilizar o 
terminal de comando do git.
git config --global user.name “seu nome/nick” --- Configura o seu nome no Git
git config --global user.email “seu e-mail” --- Configura o seu e-mail no git
Para alterar essa configuração posteriormente utilize a flag --unset junto da --global e o dado que 
deseja excluir, depois basta executar novamente o comando acima
 Com o repositório remoto criado precisamos indicar para o Git onde está a origem do protocolo HTTP daquele 
repositório remoto, para isso o GitHub forcene a URL que deve ser utilizada no comando git remote add origin 
[seu-link-vem-aqui]. Note que o terminal do Git não aceita o atalho do Ctrl + v, para isso utilize a tecla insert de 
seu teclado.
 Após isso o Git vai identificar o seu repositório, a partir desse momento apresentamos o conceito de empurrar 
os arquivos do repositório local para o remoto, pois o comando em inglês do Git que faz isso pode ser traduzido 
como empurrar, visto que o comando se chama git push origin master. Por convênçãoutiliza-se a palavra 
master para identificar o ramo principal do repositório, enquanto o origin é uma variável que está armazenando 
a URL do repositório.
 Além disso o Git ainda permite clonar repositórios remotos para o ambiente de desenvolvimento, isso é 
essêncial para que exista a colaboração entre duas pessoas, para isso basta utilizar o comando git clone 
[link_do_repositório_remoto]. vale ressaltar que o git clone configura automaticamente a origin do repositório 
local, assim não é necessário utilizar o git remote.
 Após fazer isso você pode colaborar empurrando suas modificações para o servidor usando git push, além de 
obter a versão de seus colaboradores ao usar o git pull origin master. O GitHub só vai permitir as alterações do 
código caso o autor tenha aceitado você como colaborador ou se como colaborador você aceitar uma sugestão 
de outros usuários.
8
 
 As vezes durante a edição de código pode surgir conflitos, os conflitos ocorrem quando duas ou mais pessoas 
editam o mesmo arquivo, principalmente quando essa edição for feita na mesma linha, assim eles não estão 
sincronizados, criando conflitos de merge, para entendermos melhor vamos observar o exemplo a seguir:
 Perceba que o commit foi rejeitado, na sequencia o git até mesmo deu uma dica dizendo que “a atualização foi 
rejeitada porque o repositório remoto contém trabalho que você não possui no repositório local”, ele até mesmo 
sugere realizar um git pull para atualizar o repositório.
 Observe nesse exemplo que no período 0 existe um código no servidor remoto do GitHub, tanto o contribuidor 
azul quanto o contribuidor vermelho possuem o mesmo código, sejá porque um deles empurrou o código para o 
servidor e o outro clonou, ou porque ambos clonaram aquele repositório, assim no momento 1 percebemos que 
os arquivos são identicos, entretando no momento seguinte (2) ambos fazem uma alteração na mesma linha do 
código, fazendo com que o repositório de ambos sejam diferentes, mais adiante o contribuidor vermelho decide 
enviar a alteração para o servidor (3), enquanto o contribuidor azul faz mais uma mudança (4), depois disso ele 
resolve enviar para o servidor sua alteração, no entanto o GitHub vai retornar a informação de que existe uma 
versão mais recente no servidor do que a sua, e isso gera um conflito (5), nesse momento o arquivo contém a 
diferença de ambos os colaboradores, logo o Git permite que você resolva esse conflito de merge manualmente 
(6).
 Esse tipo de conflito é muito comum, geralmente o colaborador é notificado ao realizar um git push, aparecendo 
a mensagem a seguir:
9
 
1
0
0
2
3
5
4
6
23dfta
23dfta ftg33r rtxa45
23dfta t34gh1
t34gh1
Resolvendo conflitos
 Note que o próprio Git tentou corrigir o erro automáticamente, entretanto ele notou que a mesma linha tinha 
sido editada, e por isso disse que a “automatic merge” falhou, nesse caso é preciso abrir o arquivo indicado pelo 
Git com conflito e resolver manualmente.
 O arquivo acima é o README.md do seguinte repositório: https://github.com/ViniciusBazan/livro-receitas . 
Quando o git pull foi realizado o git automáticamente pegou a linha com conflito e adicionou essa estrutura 
contendo <, = e >, perceba que a linha indicada com a seta vermelha tem a palavra “HEAD”, significa que ela é a 
parte mais recente do repositório local, ou seja, as suas alterações que entraram em conflito, sendo separada 
pelo conjunto de iguais (=) indicado na seta amarela, pois dali em diante até a seta verde é o que estava no 
servidor, daí em diante basta escolher o que manter e apagar essa estrutura, podendo até mesmo mesclar 
ambas, gerando o seguinte resultado:
 Após resolver o conflito manualmente basta usar o git add, seguido do git commit e por fim refazendo o git push 
que deu o problema anteriormente, perceba também que ao dar um git status o conflito é apresentado como 
both modified.
10
 
 Inicia um repositório dentro de um diretorio
 git init
 Configura dentro de um repositório Git a URL do repositório remoto
 git remote add origin [link]
 Clona um repositório remoto para o seu ambiente de desenvolvimento, trazendo a configuração do git remote 
no momento da clonagem
 git clone [link]
 Move um ou mais arquivos que estejam nos estágios untracked e modified para o estágio staged, preparando os 
arquivos para um commit. Pode receber caracteres curinga como asterisco (*) para expecificar de modo 
gênerico arquivos que devem ser afetados
 git add [arquivo]
 Cria uma nova versão do projeto no repositório por meio do objeto commit, utilizamos a flag -m para 
especificar na sequência uma mensagem curta que resume as mudanças feitas
 git commit -m ”mensagem”
 Empurra para um repositório remoto as versões locais do seu ambiente de desenvolvimento para uma árvore em 
especifico do git, geralmente especificamos a branch como master para a árvore principal que deve receber as 
versões em produção.
 git push origin [branch]
 Traz para um repositório local as versões remotas do servidor de uma árvore em especifico do Git, geralmente 
especificamos a branch como master para a árvore principal que deve enviar as versões em produção.
 git pull origin [branch]
 Cria um relatório no terminal que indica as mudanças dentro de um repositório, indicando arquivos untracked, 
modifieds e staged.
 git status
 Move um ou mais arquivos para o estágio untracked, preparando os arquivos para serem removidos do indice do 
Git em um commit. Pode receber caracteres curinga como asterisco (*) para expecificar de modo gênerico 
arquivos que devem ser afetados
 git rm [arquivo]
A1
 
Apêndice A - Comandos Git
 Permite navegar entre as diversas branchs criadas, caso a flag -b seja passada na utilização do comando uma 
nova branch é criada.
 git checkout -flag [branch]
 Permite deletar ou listar todas a branchs dependendo da flag utilizada, -D para deletar e -L para listar todas as 
branchs, além de exibir com um asterisco em verde (*) a branch atual.
 git branch -flag [branch]
 Lista todos os commits em ordem cronologica, opcionalmente algumas flags podem ser utilizadas para alterar a 
forma em que ela é listada, --oneline resume os commits em uma linha, enquanto o --graph mostra um grafico 
das versões.
 git log --flag
 Permite alterar uma série de variaveis padrões do Git respeitando a hierarquia conforme as flags --local ou 
--global são utilizadas, permite-se utilizar também apenas a flag -l ou --list para ver todas as possíveis 
configurações, além da flag --unset para desatribuir um valor. Recomenda-se que faça as alterações nos valores 
apenas do user.name e user.email caso não tenha conhecimento de outras configurações.
 git config --flag [atributo] “valor”
A2
 
 Lista o historico de comando utilizados no terminal.
 history
 Limpa a tela do terminal.
 clear
 Lista todos os arquivos e diretorios dentro da pasta atual.
 ls
 Mostra o caminho do diretorio atual.
 pwd
 Cria um arquivo em branco.
 touch [nome]
 Cria um arquivo podendo ter ou não conteúdo.
 echo “conteúdo” > nome
 Move ou renomeia um arquivo.
 mv [caminho] [novo_caminho]
 Remove um arquivo.
 rv [arquivo]
 Navega entre os diversos diretorios do sistema operacional, utiliza-se dois pontos (../) para subir um nível do 
diretorio.
 cd [caminho]
B1
 
Apêndice B - Comandos do terminal GitBash