O documento discute os conceitos fundamentais do Git, incluindo que Git é um sistema de controle de versão de arquivos distribuído, que permite que várias pessoas contribuam para projetos simultaneamente de forma segura. O documento também explica os principais comandos e fluxos de trabalho do Git como iniciar repositórios, fazer commits, branches, merges e resolução de conflitos.
3. ● GIT não é um sistema de controle de versão de código
● GIT é um sistema de controle de versão de ARQUIVOS
● Permite que pessoas possam contribuir para projetos
de forma simultânea, editando, criando e removendo
sem riscos de sobrescrita.
● GIT não se resume apenas a código e usar um sistema
de versionamento é uma decisão sábia não só para
Devs.
● Versiona arquivos PST, Imagens, Documentos,
Binários e até mesmo… folhas de código :)
# git log
O QUE É GIT
4.
5. ▸Criado por Linus Torvalds para substituir um VCS
(Version Control System) chamado Bit Keeper - Todos
os arquivos são requisitados ao servidor
▸Criado a partir da necessidade de gerenciar o
projeto do Kernel Linux com a comunidade.
▸Focado em performance e confiabilidade
▸Mais tarde se tornou um DVCS (Distributed Version
Control Systems) - Todo cliente possui uma cópia
completa do repositório.
O QUE É GIT
7. ▸GIT é apenas um serviço, em um servidor que
manipula as informações e versões do repositórios.
▸O Github é uma hospedagem de Git. Ele fornece
ferramentas para melhorar a usabilidade em um
servidor de Git compartilhado com opções
gratuitas e privadas.
O GIT NÃO É O GITHUB
15. OS OBJETOS DO GIT - BLOBS
▸O Git usa um modelo de armazenamento uniforme
para todos os seus objetos.
▸Cada objeto é identificado com o seu hash, mas o
tipo do objeto é armazenado em metadados
juntamente com o objeto.
▸Sempre que criamos ou modificamos um arquivo
trackeado, é gerado um BLOB para o mesmo.
16.
17.
18. OS OBJETOS DO GIT - TREES
▸Como o GIT sabe, qual arquivo está na minha branch
atual, e qual pertence a qual?
▸Os blobs são organizados em trees, o que
corresponde aos diretórios em uma estrutura de
diretórios.
▸A tree representa uma arvore de diretório diretório,
contendo uma mistura de blobs e outras trees. Caso
seja um blob de tree dentro de uma tree, podemos
identificar um subdiretório, e assim em diante...
19. OS OBJETOS DO GIT - COMMITS
▸Um commit também é um objeto de hash,
armazenado exatamente nos mesmos mecanismos
em que blobs e trees.
▸Um commit é um hash da mensagem de commit,
com um tipo de identificação das modificações.
24. USANDO O GIT NO GITHUB COM
AUTENTICAÇÃO DE DUAS ETAPAS
▸Copie sua chave pública.
▸No Github vá em Settings -> SSH and GPG keys
▸Clique em New SSH Key e cole sua chave.
▸Pronto :)
25. USANDO O GIT NO GITHUB COM
AUTENTICAÇÃO DE DUAS ETAPAS
▸cat ~/.ssh/id_rsa.pub
26. USANDO O GIT NO GITHUB COM
AUTENTICAÇÃO DE DUAS ETAPAS
28. ▸O repositório é onde o sistema de controle de versão
mantém o rastreamento de todas as alterações
realizadas no projeto.
▸Armazenam o estado atual do código, o histórico de
alterações, quem fez, e um log que explica o porquê
da alteração ter sido realizada.
▸De forma geral o repositório precisa ter tudo que é
essencial para o projeto, tanto para codificar,
modificar quanto para construir as versões.
REPOSITORIO
29. ▸WORKING DIRECTORY - Onde estão os arquivos
vigentes, ainda não adicionados nem commitados
▸INDEX (STAGE) - É uma árvore temporária de
arquivos adicionados.
▸HEAD (Ta valendo) - Area que aponta o ultimo
commit de alterações confirmadas que você realizou.
FLUXO DE TRABALHO NO GIT
30. ▸Commited: O arquivo está sob controle de versão e
não apresenta nenhuma modificação.
▸Commit candidate: Quando você adiciona as
modificações (commit), esses serão os arquivos
incluídos.
▸Modified: Arquivos que foram modificados.
▸Untracked: Arquivos novos, que ainda não estão
sendo monitorados pelo Git.
OS 4 ESTADOS DOS ARQUIVOS NO GIT
31. INICIANDO UM REPOSITORIO LOCAL
$ git init
▸Cria um repositório LOCAL com a estrutura do git
▸A pasta que contém a pasta “.git”
▸Contém todos os metadados do seu repositório e as
versões disponíveis
$ git remote add origin <servidor>
32. CLONANDO UM REPOSITORIO REMOTO
$ git clone https://github.com/user/repositorio.git
VIA HTTPS
$ git clone git@github.com:user/repositorio.git
VIA SSH
34. CRIANDO E DANDO CHECKOUT NAS
BRANCHES
$ git checkout -b novabranch branchorigem
PARA CRIAR UMA BRANCH A PARTIR DE OUTRA
$ git checkout branch
TROCANDO DE BRANCH
35.
36. IDENTIFICANDO AS BRANCHES
$ git branch
PARA VERIFICAR AS BRANCHS UTILIZADAS
$ git branch --all
VERIFICAR TODAS AS BRANCHES EXISTENTES NO PROJETO
37.
38. O COMANDO MAIS IMPORTANTE DO GIT
$ git status
▸Exibe o status da branch, e todos os arquivos.
▸Deve se usar sem moderação.
▸Exibe o status das árvores, branch atual, histórico de
arquivos modificados, adicionados, criados e
apagados
39.
40. ADICIONANDO UM ARQUIVO / TODOS
$ git add arquivo.php
$ git add pasta/
$ git add *
▸Adiciona os arquivos para o Index (Stage)
41.
42. REMOVENDO UM ARQUIVO DA INDEX
$ git reset arquivo.php HEAD
▸Retorna o arquivo para o estago de unstaged
43.
44. CRIANDO UM COMMIT
$ git commit -m "modifiquei o sistema de
checkout"
▸Cria um commit das modificações executadas
$ git commit -am "modifiquei os boletos"
▸Cria um commit das modificações executadas já
adicionando todos os commits candidates (add * )
45. CRIANDO PUSH PARA O REMOTE
$ git push origin <branch>
▸Enviamos nossas modificações commitadas para o
remote.
46.
47. SOLICITANDO UM PULL DAS
MODIFICAÇÕES DO SERVIDOR
$ git pull origin <branch>
▸Git pull é um “syntax sugar” para “git fetch ; git
merge HEAD”, onde são baixadas as modificações da
branch e as mesmas são “merjadas” com a HEAD
atual.
48.
49. EFETUANDO O MERGE DE DUAS
BRANCHES
$ git merge <branch>
▸O Merge é uma das tarefas mais complexas que o git
faz, perde somente para o rebase, outra alteranativa
para o merge.
▸O Merge vai olhar para as duas branches (a atual e a
de origem), encontrar os commits em comum e
aplicar os commits que a branch atual não tem em
cima.
50.
51. REBASE - ALTERNATIVA MAIS COMPLEXA
AO MERGE
$ git rebase <branch>
▸É mais uma forma de mover commits entre branchs
do Git
▸No Rebase, os seus commits (acima da base) são
temporariamente apagados.
▸A branch atual fica exatamente igual ao outro
branch e seus commits são aplicados um a um no
branch atual.
▸Ideal para manter o histórico intacto.
52. VERIFICANDO UM DIFF DE UM ARQUIVO
$ git diff file
▸É o visualizador de diffs default do git.
▸Ele mostra as linhas modificadas de um arquivo
apontado.
▸Caso o arquivo seja muito grande ele vai abrir um
“less” em shell para melhor visualização.
▸“+” Representa as linhas adicionadas
▸“-” Representa as linhas removidas/substituidas
53.
54. ▸O Netbeans tem plugin nativo (FODA) de Git que
ajuda no historico e nos diffs
▸O Sublime tem alguns packages que ajudam
-> Sublime GIT
-> GitStatus
▸Atom tem muitos tbm...
VERIFICANDO UM DIFF DE UM ARQUIVO
60. REVERTENDO ALTERAÇÕES LOCAIS
$ git checkout -- <arquivo>
▸Modifiquei, deu ruim, é mais fácil refazer…
CHECKOUT NELE!
▸Substitui as alterações do arquivo pelo conteúdo
mais recente do mesmo presente do HEAD.
▸Alterações já adicionadas ao Index (Stage) e novos
arquivos serão mantidos.
61. VERIFICANDO OS LOGS DOS COMMITS
$ git log
▸Verifica as alterações efetuadas no repositório e
parseia de uma forma mais amigável.
▸Exibe as hashes dos commits e seus respectivos
autores.
62.
63. REVERTENDO ALTERAÇÕES LOCAIS
$ git fetch origin
$ git reset --hard origin/master
▸ZOEI TODO O MEU LOCAL!!! E agora??? Descarte todos
os commits locais e baixe uma nova cópia novinha
do servidor!
▸Todas as suas alterações locais (sem o push) vão
voltar para o estado original do servidor.
▸CUIDADO. Vai descartar tudo MESMO!
64. ROLLBACK EM COMMITS
$ git reset --hard hashdocommit
$ git reset --hard HEAD˜10
▸Podemos dar um reset na hash de um commit
específico, voltando todo o estado do head para o
estado commit especificado (git log)
▸Podemos voltar também um número específico de
commits para trás.