Um simples resumo sobre git e gitHub, para quem não sabe nada de git e

giitHub

Me segue lá https://github.com/MarcosMthJr
^^
 Instalando o Git
Basta entrar no site baixar e seguir os passos, é bem simples.

Configurações básicas do Git

para configurar o git para o usuária de forma global, siga os passos:

• para configurar username:

◦ git config --global user.name “Seu Nome”

• para configurar email:

◦ git config --global user.email “SeuEmail@mail.com”

• para configurar o editor padrão (passa o comando no terminal que abre o editor, no meu caso
o vscode é code):
◦ git config --global core.editor code

Para saber a informação que você colocou, basta digitar:

git config user.(campo desejado)
ex: git config user.name (vai aparecer o username)
se quiser ver todas as informações digite: git config --list

Inicializando um repositório
Acesse o diretório do seu projeto pelo terminal, ou crie esse diretório caso não exista.
E para inicializar o repositório e ele fazer parte do ecossistema do git, você digita:
git init
ele vai criar um diretório dentro do que você criou, essa pasta criada ela vai armazenar informações do
seu repositório, como configuração, branches e etc…

Commit
Commit é quando você cria uma versão dos arquivos no seu diretório.
Só é criado um commit dos arquivos que estão em stage!

Ciclos de vida de arquivos Git

Untracked : Arquivos marcados como untracked são arquivos não monitorados pelo Git. Os arquivos
que acabaram de ser criados sempre estarão com esse estado.
Stage: Os arquivos marcados como stage são os arquivos novos ou modificados que serão salvos no
próximo commit. O que o comando anterior git add faz é adicionar os arquivos de untracked e
modified para stage.
Unmodified: Quando realizamos um commit, os arquivos saem de stage para unmodified, isso significa
que, na linha do tempo, seu arquivo está igual ao estado salvo no último commit.
Modified: São os arquivos já monitorados pelo Git que sofreram alguma alteração desde o último
commit.
Manipulando arquivos
(criando, modificando e commitando)
Para ver o status do repositório, basta digitar git status
(se o diretório estiver vazio, ele vai aparecer “ nothing to commit” )
Caso não exista, crie um arquivo qualquer, pode ser um Readme.md por exemplo.
Se você digitar um git status depois de criar esse arquivo, você vai perceber que ele está no seu
primeiro estágio (Untracked files)

Para adicionar esse arquivo ao stage para ser possível realizar commit , basta digitar git add arquivo,
nesse caso: git add Readme.md
Se der um git status, ele vai retornar que você tem um novo arquivo que já pode ser possível realizar o
commit
new file: Readme.md
Nesse momento ele tá em Stage

Mas se você editar esse arquivo, e der o git status ele vai mostrar que um arquivo foi modificado
modified: Readme.md
para que ele possa salvar a modificação nesse arquivo, basta dar o comando git add Readme.md
Assim ele voltará para Stage e pode realizar o commit.
Realizando commit
Para realizar um commit, digite:
git commit -m “Mensagem”
assim ele vai realizar o commit de todos os arquivos que foram adicionados ao git (git add)
Uma boa prática é colocar na mensagem qual alteração você fez antes de realizar o commit.
Exemplo se eu adicionei um novo arquivo, eu colocaria
git commit -m “Add Readme.md”
é uma forma de criar um log para as pessoas se localizarem com mais facilidade.
Depois de dar esse comando, ele vai retornar o diretório que você tá, também vai retornar uma
hash(codigo) e um comentário, essa hash é o código daquela versão, é a partir desse número que você
consegue voltar para a versão desejada.
Se você digitar git status, ele vai dizer que não há nada para realizar o commit, porém se você editar
ele vai entrar em modified e para realizar o commit precisar dar o git add novamente no arquivo
desejado, e assim vai criando, modificando, adicionando ao stage e criando versões .

IMPORTANTE LEMBRAR DO CICLO:

UNTRACKED, UNMODIFIED, MODIFIED E STATGE.
Se for possível volte até a parte de Ciclos de vida de arquivos Git

Visualizando Logs
Para visualizar o log da forma mais básica é só digitar o comando git log, vai ser apresentado uma
hash do commit, autor a data e mensagem do commit.
O comando git log --decorate mostra algumas informações, como de qual branch e ele saiu e para qual
branch ele foi, tags geradas e etc…
Outra opção bem interessante é filtrar pelo autor:
git log --author=”Nome do Autor”
(caso procure de alguém que não exista ele não retornará nada )

Para ver o número de contribuições e listá-las, basta digitar: git shortlog

Se quiser visualizar somente a quantidade de commit da pessoa, digite: git shortlog -sn

Pra visualizar de forma gráfica o que esta acontecendo com seus branches e suas versões digite:
git log - -graph

Para obter informações de determinado commit(versão), copie a hash do commit desejado, e digite:
git show hashCopiada
E você vai ver suas alterações

(IMPORTANTE) Visualizando Diff (IMPORTANTE)

Você pode visualizar as modificações antes de fazer o git add ou antes de fazer um commit, isso é
importante para dar uma revisada antes de fazer uma versão! Sempre use-o antes de fazer um commit.
Basta digitar: git diff
você pode filtrar também apenas pelo nome do arquivo modificado, digitando: git diff --name-Only
 Desfazendo Coisas
Para voltar um estado de um arquivo, para o estado antes dele ser modificado basta digitar:
git checkout nomeDoArquivo
Caso você já tenha dado o git add nesse arquivo, e queira tirá-lo do stage, digite:
git reset HEAD nomeDoArquivo
dessa forma ele vai sair do stage, e voltará para o estado que estava antes do comando git add, porém
ele ainda não foi resetado, para resetar precisa dar o comando git checkout novamente.

Já fiz o commit! Subi errado e agora ?

Calma .. tudo tem um jeito! Relaxa …
existe três comandos de reset: git reset --soft, -- mized ou --hard
IMPORTANTE
Você só vai passar a hash do commit que está antes do(s) commit(s) que deseja dar um comando de
reset.
Pois ele vai entender o seguinte: “ a partir de qual commit pra cima você quer dar o reset?”
se tiver mais de um commit acima da hash do commit que você quer manter como ultimo, ele vai fazer
o reset em todos acima do selecionado.
--soft: ele vai tirar o arquivo do commit, mandando ele de volta para stage para ser realizado o commit
novamente.
Ex: git reset --soft hashDoCommitQueDesejaManterComoUltimo

--mixed: ele vai tirar o arquivo do commit, mandando ele de volta para antes do stage (para o
modified)
Ex: git reset --mixed hashDoCommitQueDesejaManterComoUltimo

- -hard: ele vai ignorar a existência desse commit e tudo que foi feito nele, ele vai apagar o commit
completamente!(tenha muita certeza que nunca mais vai querer acessar arquivo antes de dar esse
comando!)
Ex: git reset --hard hashDoCommitQueDesejaManterComoUltimo
 Criando Repositório no gitHub
Entre no site do gitHub, crie um conta e logue.
• Ao fazer login, você terá acesso a uma opção que tem um ícone de + ao lado da sua foto de
perfil, clique nele e selecione New repository.
• Escolha um nome para seu repositório, esse nome tem que ser único para você, não pode ter
um repositório com o mesmo nome.
• Digite uma descrição
• Selecione a opção de visualização de código(public: qualquer um pode ver seu código, private:
só você e quem você compartilhar que poderá ver)
• Você também pode escolher se quer ou não inicializar seu repositório já com o Readme,
gitignore e licença. (como ao decorrer desse material você já criou um repositório local, não
vamos marcar essa opção)
• Clique em create repository
Pronto Repositório criado!

Criando chave SSH

(para que o gitHub te reconheça e possibilite que você suba seus arquivos para o repositório)
SSH é um protocolo que serve para autenticar um usuário remoto ao um servidor, ele é baseado em
chaves onde existe uma chave publica e uma chave privada, onde a chave privada abre a chave publica!
Confuso neh ? Mas não liga não, o negócio é seguir os passos que vai dar certo. ;)
(obs: se quiser saber mais, ou seguir essa parte pelo site do gitHub tá aqui o link:
https://help.github.com/en/articles/connecting-to-github-with-ssh )
E são somente dois passos!
1- Gerar a chave de ssh / 2 - adicionar essa chave a conta do gitHub
Gerando a chave:
• Copie esse comando e cole em seu terminal, substitua o e-mail, pelo e-mail que você criou sua
conta no gitHub
◦ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
• Vai aparecer o texto dizendo que a chave foi criada “> Generating public/private rsa key
pair.” é só dar ENTER

• Vai pedir para selecionar onde quer salvar a chave “Enter a file in which to save the key (/
home/you/.ssh/id_rsa): [Press enter]” pode deixar a padrão, só apertar ENTER

• Vai pedir para colocar uma passphrase para aumentar a segurança, e logo pede para
confirmar “> Enter passphrase (empty for no passphrase): [Type a passphrase]> Enter
same passphrase again: [Type passphrase again]” é só apertar ENTER e deixar tudo
padrão
 Localizando a Chave e Adicionando no gitHub
• para localizar sua chave ssh na sua maquina: basta digitar
• digite o comando cd ~/.ssh/ no seu terminal para navegador até o diretório que estão as
chaves criadas. (~ é sua home e o .ssh é porque é um diretório oculto)
◦ dê um ls e veja se as chaves estão ai
◦ A chave id_rsa.pub é a chave que vamos colocar no nosso gitHub.
• Copie essa chave com o comando cat id_rsa.pub (ou pode abrir com um editor de texto)

• Abra seu navegador

◦ acesse o gitHub
▪ Navegue até a opção settings
• Clique na opção “ SSH and GPG keys”

◦ Clique em “New SSH key”

◦ Title: Coloque um titulo para sua chave (pode ser o nome do computador para
ficar fácil de identificar a chave, ou pode ser “home” e “work” para separa
computador pessoal com o do serviço, isso não é muito importante)
◦ Key: cole a chave que você copiou
◦ Clique em Add SSH key
◦ pronto!
Ligando Repositório local a um remoto
• Abra seu repositório no gitHub
◦ navegue até seu repositório que foi criado. (tem até um passo a passo na página)
◦ você tem duas opções: crie um novo repositório na linha de comando ou envie um repositório
existente a partir da linha de comando
▪ selecione a opção desejada (vou escolher a opção que diz para enviar um repositório
existente. )

▪ Navegue até seu diretório que tem seus arquivos pelo terminal.
▪ Copie o código e cole no seu terminal
• git remote add origin https://github.com/seuUsuario/seuRepositorio.git
◦ “origin” é o nome da sua pasta de origem no gitHub, você pode mudar esse
nome ou deixar o padrão
• e digite git push -u origin master
◦ esse comando diz para onde vai (diretório remoto “origin”) e de onde
vem(“diretório master”) se for necessário mude esses valores conforme suas
configurações.
▪ Ao executar os comandos ele manda para o seu repositório no gitHub e exibe algumas
informações. Volte para seu gitHub e atualize a pagina do seu repositório, verifique se
os arquivos foram “upados” com sucesso!
 Enviando mudanças para o gitHub
Faça o commit normalmente dos seus arquivos modificados ou criados
• Abra o terminal e digite:
◦ git add arquivo / git commit -m ”mensagem” ou
◦ git commit -am “mensagem” para adiconar no stage e já realizar o commit de uma vez sófoi
▪ o commit foi feito em seu repositório local
Para que ele vá para seu repositório no gitHub digite:
• git push origin master
◦ origin = diretório remoto
◦ master = branch que você está, sempre que cria um repositório incial o branch se chama
“master”
▪ vamos ver branch mais pra frente, rlx ae ! :D
Basta dar ENTER e pronto, ele vai enviar para o gitHub

clonando repositório para sua maquina

Caso queira participar de projetos open source, ou pegar o codigo de alguém no gitHub, você pode dar
o comando git clone linkDoEndereçoSSHdoRepositorio
esse endereço você encontra dentro do repositório desejado, na opção mostrada na imagem abaixo
 Fazendo um fork de um projeto
Fork é quando você copia o projeto de outras pessoas para você, e faz as alterações e depois manda um
pull request para o dono do projeto informando as alterações que você fez.
Para criar você precisa ser membro de uma organização.
Caso seja e queira criar, você clica no botão de fork no seu repositório.

Pronto, ele vai fazer uma cópia de todo repositório da pessoa dentro do seu repositório.
A diferença entre git clone eu fork, é que se você fizer uma modificação com arquivo clonado, você não
vai conseguir enviar, pois, não tem permissão .

O que é Branch e pra que usar ?

Branch é um ponteiro móvel que leva a um commit.
Que ? Como assim ? Whats ?
Pera calma .. bora desenrolar isso!
Primeiro vamos lembrar que cada vez que faz um commit, ele gera um hash responsável por um
snapshot do projeto (uma versão ).

O que o branch faz é apontar para algum commit(para uma versão do projeto)
Vou te dar um exemplo bem besta, mas, é fácil de entender:
Quando você quer criar uma nova versão do projeto, o que você faz ? Se você for inteligente, você
vai criar um diretório com os arquivos do projeto original copiados dentro dele, e com o nome da
versão (ex: projetoX_2.0), isso para que você possa fazer as atualizações e programar novos recursos
sem modificar o código da versão que está pegando (versão projetoX_1.0).
O branch é mais ou menos isso, ele cria um “diretório” que aponta para um commit (uma versão), sem
modificar a versão que está no branch MASTER ou em outro branch que você queira manter intacto
até fazer as modificações necessárias no projeto copiado.
Branch no mesmo commit
Você pode criar um branch que aponta para o mesmo commit que outro branch está apontando, isso
funciona da mesma maneira quando você cria uma pasta no computador e tem os mesmos arquivos
de outra pasta dentro dele..
Aqui nessa imagem temos dois branches o master e o testing apontando para a mesma hash de um
commit.

Branch em commits diferentes

Também é possível criar branches em commits separados.
Aqui temos o branch master apontando para o commit C2 e o iss53 apontando para C3

Por que usar essa forma de separar os branches ?

okay! Consegui entender, mas pra que eu vou usar isso ? Se eu posso criar um commit e voltar para a
versão que estava antes se eu fizer alguma coisa erra.
Vou falar as vantagens de se utilizar branches:
• Pode modificar seus arquivos sem alterar seu local principal
◦ você pode corrigir um bug enquanto tem outras pessoas trabalhando no branch principal
(master)
• facilmente “ desligavel “
◦ você pode criar e deletar branch de uma maneira fácil e rápida, pois o git escreve um
arquivo de 41bytes, então você não precisar copiar o projeto gigantesco para um diretório
para poder ter o código e modificar sem medo.
• Multiplas pessoas podem estar trabalhando
◦ você pode ter uma pessoa trabalhando no master, e outras em outros branches, pode
separa cada branch por departamentos, como por exemplo o facebook, ele é gigante cada
equipe é responsável por um pedaço dele, então separar branches por equipe pode ser
interessante.
• Evita conflitos
◦ Como você vai estar trabalhando em um local separado, a quantidade de conflitos que
podem acontecer é bem menor do que se todo mundo trabalhasse em um branch só, por
exemplo: se eu estiver no branch Master com mais 30 pessoas, eu faria um commit da
minha versão e essas 30 pessoas também fariam das suas versões, então isso ia dar errado,
ai ser commit em cima de commit e apenas 1 ia ficar, depois você teria que ver o histórico
e os logs para colocar os commits em ordem e alinhar eles para não ter problemas. No
branch você está em um ambiente separado, depois você mescla ele com o master sem
problema algum.

Criando um branch
Para criar um branch abra seu terminal e digite : git checkout -b nomeDoBranch
Pronto ele vai criar e já vai entrar no branch para você.
Para ver os branches existentes digite: git branch
Repare que tem um branch com um * logo no inicio do nome dele, esse * é pra sinalizar qual branch
você está.

Navegando entre branches - deletando

Para ir de um branch para o outro digite: git checkout branchQueQuerIr
Se quiser voltar para o master é só digitar: git checkout master
Para deletar um branch basta passar a tag -D no comando: git branch -D branchParaDeletar
 Unindo branches
A duas formas de fazer essa união, usando merge e com rebase, vamos ver um de cada
vez:
Merge
Vamos aplicar o merge no repositório abaixo:

No estado incial você tem dois branches apontando para

o mesmo commit.

Agora criamos um novo commit no novo

branch (commit C3 no branch iss53)

Aqui criamos um
novo branch e
fizemos um novo
commit do Master
nesse novo branch
chamado hotfix.
(temos uma
ramificação, dois
branches apontando
para commit
diferentes porém
com o os arquivos do
master)
Crimos um novo commit no
branch iss53, o commit C5.
E reparamos também que o
branch hotfix não existe mais,
na verdade o seu commit agora
é o master, pois ele foi
adicionado ao branch principla
master.
O C4 pode ser unido ao master seja via
merge ou rebase, como não existe
nenhum commit antes/depois, ele vai
juntar a só o commit do hotfix mesmo.

Para jogar esses dois commits do branch ss53 para o Master usando o merge, temos que criar um
novo commit e esse commit novo vai juntar todas as modifcações feitas no outro branch (C3 e C5 vai
juntar com C4), veja na imagem abaixo, o commit novo é chamado de C6.

Ele vai criar um commit extra no master (C6) com as modificações que você fez no branch iss53
por isso C6 é resultado dos arquivos que estavam em C3, C5 e C4
Pro e Contra:
pro:
• Operação não destrutiva
◦ Ele não vai destruir nenhum commit, ele cria um novo commit para juntar tudo
Contra:
◦ commit extra, que não vai ser usado para nada além de unir arquivos
• Histórico poluído
◦ Se tiver muitos branches você acaba criando uma árvore com várias linhas e fica
complicado entender.
Rebase
Vamos agora aplicar o rebase

Aqui temos nosso estado inicial, onde temos

um repositório com dois commits feitos a partir
do C2 para branches diferentes que foram
criados nele.
(branch experiment e master)

O rebase vai pegar o commit C3 e

que estava no branch “ experiment”
e vai jogar na frente do branch que
você quer unir esse commit, no
nosso caso queremos unir com o
Master que está no C4, então ele
jogou na frente do C4 com o nome
de C3’. Dessa forma ele deixa tudo
linear.
Então ele basicamente pega tudo
que ele tem no branch separado e
coloca no início da fila sempre, esse
processo se chama fast forward,
que ele move todas as mudanças
para a frente da fila.
O C3’ que estava na linha do C4 vai para linha do C4.

Desse modo tanto o branch experiment e o branch master,

vão estar apontando para o mesmo commit, dessa maneira
você permanece de forma linear, e essa linearidade é muito
boa, pois assim você não vai se confundir de onde um
commit vem e para onde vai, só precisa ficar atento aos
passos desse commit
Pro e Contra:
Pro
• Evita commits extras
• Histórico linear
◦ como o rebase não cria commits extras, você consegue manter um histórico linear,
reduzindo sua preocupação de se confundir com seus apontamentos.
Contra
• Perde ordem cronológica
◦ Como podemos notar, nós sempre pegamos o commit e colocamos ele na frente da fila,
então usando o rebase você acaba mudando seu histórico, algo que você precisa tomar muito
cuidado ao fazer, pois, se você muda o histórico e outra pessoa também está trabalhando
no mesmo branch, ele vai dar conflito e a pessoa não vai conseguir subir as modificações
dela, então o rebase também deve ser utilizado com bastante cuidado. Aconselha-se usar o
rebase sempre que você for dar pull das notificações(git pull --rebase ) , pois, assim você
não corre o risco de fazer mudanças de histórico que não poderiam.

Qual é a maior diferença entre Merge e Rebase ?

A grande diferença é que o Merge cria um commit novo para poder fazer a união, enquanto o Rebase
move as modificações para o início da fila.

Merge na prática
Depois de ter criado outro branch sem ser o master e ter adiconado arquivos nele, e feito tudo que
queria, e ter realizado o commit, basta só digitar: git merge nomeBranchCriado
ex: git merge teste
Ele vai abrir uma tela de merge, que diz qual branch ele vai mesclar com o master “Merge branch
teste”
E dentro dele também mostra os commits feitos é só salvar e sair. E pronto.
Se digitar um git log você vai ver os commits e também vai ver um commit escrito “Merge banch”
 Rebase na prática

Depois de ter criado outro branch sem ser o master e ter adiconado arquivos nele, e feito tudo que
queria, e ter realizado o commit, você tem que mudar de branch, precisa voltar para o master ou para
outro branch destino que você quer unir as mudanças do outro branch, logo após mudar com o
comando git checkout branchDestino basta só digitar: git rebase nomeBranchCriado

Criando o .gitignore
Ele serve para ignorar alguns arquivos como senha na hora de enviar os arquivos para um repositório
no gitHub.
Ele é um arquivo que fica na seu diretório principal e dentro dele você usar alguns padrões para dizer
ao git quais arquivos ele n deve subir.
Passo a passo:
Para usar e configurar o .gitignore, você pode seguir esses passos.
1. Crie um arquivo chamado .gitignore dentro do seu diretório principal, e abrir esse arquivo com
um editor de texto.
2. Você pode ignorar por extensões, nome ou pastas.
1. Para ignorar um tipo de extensão coloque dentro do seu .gitignore a extensão desejada,
com um *. antes, dessa forma ele vai ignorar qualquer arquivo com aquela extensão ex:
*.json
2. Para ignorar um arquivo com um determinado nome coloque dentro do seu .gitignore a o
nome do arquivo, e dessa forma ele vai ignorar qualquer arquivo com esse nome ex:
arquivoX.php
3. Para ignorar arquivos de uma pasta digite no seu arquivos .gitignore o nome da pasta
acompanhado comm um ex: pastaX/*

3. Agora salve seu arquivos .gitignore, e digite git status e verifique se sua configuração
funcionou.

Você pode usar alguns templates já criados para usar o gitignore

https://github.com/github/gitignore

Uma dica. Existe um site que você coloca os editores de texto, arquivos, pastas etc que você
deseja configurar para ser ignorado e ele gera um arquivo .gitignore para você.
https://www.gitignore.io/