Treinamento git - Papos RBSDev

@evandroeisinger
@helmedeiros
@rssilva
--como-morre?
--o-que-é? --como-se-cria?
--do-que-se-alimenta?
--como-nasce?
--fácil-branch
--seguro
TREINAMENTO
#paposRBSDev

Git é sistema de controle de versão distribuído
livre e de código aberto, projetado para lidar com
tudo, de pequenos a grandes projetos, com
velocidade e eﬁciência.
http://git-scm.com/

Considerando a visão de LINUS TORVALDS
“controle de
versão do jeito que
ele realmente
deveria ser”
“cvs ou baseado
em suas
primitivas?”

o que é git ?
instalando o git
comandos no git
arquitetura git
repositórios no git
visão abrangente
ambiente conﬁgurado
trabalhando localmente
reconhecendo soluções
NOSSA AGENDA
SVN para git
trabalhando em time

PROPOSTAS?
Expectativas
SUGESTÕES?

O QUE É GIT?
#1 OffLine
#2 DISTRIBUÍDO
#3 BRANCHING
#4 ENXUTO
visão abrangente

#1
Git pode ser usado online ou offline, é possível fazer de tudo, branching, merging,
commiting, mesmo que você não esteja conectado a nenhuma rede.
OffLine

#2
Assim que você retorna a sua rede é possível enviar ou baixar informações de outros
repositórios remotos, seja ele um repositório centralizado ou de qualquer outra pessoa.
DISTRIBUÍDO

#3
O git fundamenta suas operações no sistema de branches, produzindo um conjunto
transparente de funções e facilidades para a sua criação, mescla, descarte, entre outros.
BRANCHING

INSTALANDO O GIT
#1 DOWNLOAD
#2 WINDOWS
#3 MACOSX
#4 GITCONFIG
ambiente conﬁgurado

#1
Dependendo do sistema operacional utilizado em seu ambiente de trabalho existirão uma ou
mais localidades ou implementações a serem feitas download para o funcionamento do git.
DOWNLOAD

DOWNLOAD
Para o windows
Faça o download do instalador a
partir da pagina Google Code a baixo:
http://msysgit.github.io/
1. Acessar http://msysgit.github.io;
2. Selecionar a opção
Downloads;
3. Selecionar a última versão
disponível;
4. Selecionar novamente
a versão previamente
escolhida para começar o
download.

DOWNLOAD
Para o linux
Você pode realizar o download e
instalação por gerenciadores de
pacotes como yum e apt-get, ou
instalar através do código fonte
baixado de:
http://git-scm.com/download
1. Acessar http://git-scm.com/download;
2. Escolha a opção para download Linux;
3. Escolha a opção indicada
para a sua distribuição.

DOWNLOAD
Para o macOSX
Você pode realizar o download e
instalação por gerenciadores de
pacotes como homebrew, fink e
macports; assim como pode baixar o
instalador dmg diretamente de:
http://code.google.com/p/git-osx-
installer
1. Acessar http://code.google.com/p/git-osx-
installer/;
2. Selecione a aba Dowloads no topo da
página;
3. Selecione a versão
mais atual compatível a
sua versão do macosx;
4. Selecionar
novamente a
versão previamente
escolhida para
começar o
download.

#2
Instalando o Git no Windows é muito fácil. O projeto msysGit tem um dos procedimentos
de instalação mais fácil.
WINDOWS

WINDOWS
Execute o instalador
Clique em avançar (Next) até chegar na
etapa seguinte
Select Components
Marque a opção Simple context menu.
Feito isso, avance para próxima tela
Select Start Menu Folder
deixe o caminho padrão e clique em
avançar (Next)
Habilitando está opção, o Git Bash e o Git
GUI serão incorporados ao menu de
contexto do Windows, possibilitando
executar o comando “Git Bash Here” dentro
um diretório qualquer

WINDOWS
Adjust your PATH
deixe marcado a opção Use Git Bash only
e prossiga com a instalação
Conﬁgure the line ending
marque a primeira opção para quebras de
linha independente do sistema operacional
Completing the git setup
instalação foi concluída com sucesso

#3
Existem algumas maneiras de instalar o git no macosx, as principais envolvem
gerenciadores de pacotes como HomeBrew, MacPorts ou Fink.
MACOSX

MACOSX-Instalando
Instalando com Brew
Tendo o brew instalado você só precisa
fazer:
➜ ~ brew install git
Instalando com Port
Tendo o port instalado você só precisa
fazer:
Instalando com Fink
Tendo o fink instalado você só precisa
fazer:
➜ ~ sudo port install
git-core ➜ ~ fink install git
Se você ainda não usa homebrew para
gerenciar pacotes no Mac OS, então eu
recomendo instalá-lo.

MACOSX-Conferindo
Onde foi instalado
Depois de instalado você deve conseguir
ver onde o mesmo foi instalado, rodando
o comando:
➜ ~ which git
/usr/bin/git
Qual versão instalada
Após instalado é possível conferir a
qualquer momento a versão do git.
Consultando o manual
É possível consultar o manual do
conjunto de comandos, dos módulos
perl que compõem o git
➜ ~ git --version
git version 1.7.12.4 (Apple
Git-37)
➜ ~ man git
GIT(1) Git
Manual GIT(1)

#4
Para trabalhar de forma correta com o git o segundo grande passo é realizar as
configurações.
GITCONFIG

GITCONFIG
Verificar configurações
Para verificar todas as configurações de
sua máquina use o comando:
➜ ~ git config --list
➜ ~ git config --list
--global
Adicionando config
Caso seu usuário e email não estejam
configurados, faça-o com o comando:
➜ ~ git config --global
user.name "Nome completo"
➜ ~ git config --global
user.email "Endereço de
Email"
É possível definir configurações a nível global
ou local, sendo local dentro do repositório a
qual se está executando comandos. As
configurações locais prevalecem sobe as
globais quando definidas.
Removendo config
Caso uma configuração seja
sobreposta, ou ainda deseje ser
removida, use o comando:
➜ ~ git config --global --
unset user.name
➜ ~ git config --unset
user.name
Na primeira vez quando não configurado o --
list --global não possuí o .gitconfig na pasta
do usuário.

COMaNDOS NO GIT
#1 NOVOREPOSITÓRIO
#2 IGNORANDO
#3 ADICIONANDO
#4 COMITANDO
trabalhando localmente
#5 REMOVENDO

├── HEAD
├── branches
├── conﬁg
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-rebase.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── info
│   └── exclude
├── objects
│   ├── info
│   └── pack
└── refs
├── heads
└── tags
#1
Para criar um repositório de um diretório de arquivos existente, você pode simplesmente
executar git init no diretório
NOVOREPOSITÓRIO

NOVOREPOSITÓRIO
Os arquivos a versionar
Por exemplo, digamos que temos um
diretório com alguns arquivos nele, como:
➜ ~ cd rbsdev
➜ rbsdev ls
README rbsdev.sh
Criando o repositório
Para iniciar o controle de versão disso
com Git, podemos simplesmente
executar git init, como:
➜ ~ git init
Initialized empty Git
repository in /Users/
helmed/rbsdev/.git/
Novo diretório
Após a criação o git define um
diretório para armazenamento de
versões
➜ ~ ls -la
. .. .git
README rbsdev.sh

#2
No git é possível especificar arquivos que serão intencionalmente desconsiderados do
versionamento.
IGNORANDO
.gitignore

IGNORANDO
Começando a Ignorar
Para ignorar os arquivos basta criar um
arquivo chamado .gitignore, seguindo o
comando a baixo, na raiz do seu projeto:
➜ rbsdev
touch .gitignore
Padrões a Ignorar
Através de expressões você poderá
definir quais arquivos, e tipos destes
poderão ser aceitos:
➜ rbsdev
nano .gitignore
#Código compilado#
##################
*.com
*.class
*.dll
*.exe
*.o
*.so
#Empacotados#
#############
*.7z
*.dmg
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip
#Logs and bancos de dados#
######################
*.log
*.sql
*.sqlite
#Arquivos gerados pelo SO#
##########################
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db

IGNORANDO
Regras para qualquer diretório
você pode adicionar estes arquivos em qualquer diretório que
se queira alterar um padrão, mas o mais indicado é manter
um único arquivo com navegação entre arquivos nos padrões
adicionados a trilha principal.
➜ rbsdev cd .idea
➜ .idea touch .gitignore
Ignorando o que já foi versionado
É importante lembrar que o .gitignore não funciona com
arquivos já versionados, isto é, arquivos comitados
anteriormente ao .gitignore. Para isso é necessário remover o
cache, para que consigam ser ignorados:
➜ .idea git rm -r --
cached .idea
É possível ter regras gerais por usuário
utilizando a configuração core.excludesfile
que aponta para o caminho de um
arquivo .gitignore. ex.: git config --global
core.excludesfile ~/.gitignore
Quando você ignorar algo globalmente,
localmente pode usar o ! para adicioná-lo
localmente.

IGNORANDO
http://gitignore.io/

IGNORANDO
Rodando o .gitignore.io no console
Para rodar o gitignore.io da linha de comando você irá precisar de uma função com acesso a urls web. Adicione o
script a baixo para usar a API do gitignore.io.
➜ rbsdev $ echo
"function gi() { curl
http://gitignore.io/api/
$@ ;}" >> ~/.bashrc &&
source ~/.bashrc
➜ rbsdev gi list
➜ rbsdev gi vim,maven,java
# Generated by http://gitignore.io
### vim ###
.*.s[a-w][a-z]
*.un~
Session.vim
.netrwhist
*~
### Maven ###
target/
### Java ###
*.class
# Package Files #
*.jar
*.war
*.ear

#3
Quando estamos trabalhando com arquivos sobe o versionamento do git, temos que ter
sempre em mente o ciclo de vida dos mesmos passando de não rastreados para
rastreados.
ADICIONANDO
Untracked
tracked

Untracked
ADICIONANDO
Conferindo o Estado dos arquivos
Em muitos momentos os arquivos sobe o versionamento
estarão no seu computador mas em um determinado
estado. Para descobrir em que estado podemos usar o
comando status, veja:
➜ rbsdev git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files
and use "git add" to track)
➜ rbsdev touch .gitignore
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to
include in what will be committed)
#
# .gitignore
nothing added to commit but
untracked files present (use "git
add" to track)
.gitignore

ADICIONANDO
Arquivos não rastreados
Untracked significa basicamente que o git vê um novo arquivo que
ele não tem no seu histórico; o git nunca vai fazê-lo
automaticamente a não ser que você o diga.
tracked
.gitignore
➜ rbsdev git
add .gitignore
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..."
to unstage)
#
# new file: .gitignore
Rastreando Arquivos
Para iniciar o rastreamento de um novo arquivo, você deve usar o
comando add. Veja:
Untracked
.gitignore

ADICIONANDO
Várias formas de adição
Para adicionar arquivos em um commit, é necessário executar um comando que insira ele no commit:
➜ rbsdev git add .
# On branch master
#
# Initial commit
#
to unstage)
#
# new file: .gitignore
➜ rbsdev touch a.txt
➜ rbsdev git add *.txt
# On branch master
#
# Initial commit
#
to unstage)
#
# new file: a.txt
#
# Untracked files:
# (use "git add <file>..." to
include in what will be committed)
#
# .gitignore
➜ rbsdev mkidr a
➜ rbsdev git add a
# On branch master
#
# Initial commit
#
to unstage)
#
# new file: a.txt
# new file: a/a.srt

#4
Para confirmar e armazenar as alterações realizadas perante o histórico do git é
necessário realizar o commit.
COMITANDO
Untracked
tracked
staged

COMITANDO
Descrevendo o commit
Após a adição dos arquivos no commit
é possível executar o commit
➜ rbsdev git commit -
m "Descrição do
commit"
[master (root-commit)
edc6bb2] Descrição do
commit
0 files changed
create mode 100644 a.txt
Adicionando no commit
Também é possível executar um commit
que já adicione todos os arquivos
modificados:
a -m "Descrição do
commit"
[master 30bf45a] Descrição
do commit
0 files changed
create mode
100644 .gitignore
Diff no commit
Se for desejado é possível adicionar a
mensagem de commit o diff da
alteração, adicionando a opção -v:
a -v
[master 2921ce7] Feito
0 files changed
create mode 100644 b/
b.srt
a opção a cima só funciona quando o arquivo
já foi adicionado previamente a árvore de
acompanhamento, o primeiro commit sempre
deve se precedido de uma adição (git add)
Esta opção abre normalmente o seu editor
predileto para editar a mensagem.
core.editor=mate

#5
O comando reset do git desfaz mudanças em arquivos no diretório de trabalho. É bom
lembrar que só é permitido limpar ou remover completamente as mudanças que não foram
enviadas para um repositório público
REMOVENDO

REMOVENDO
Retornando para untracked
Com o comando certo é possível fazer com que
um arquivo não seja mais ratreado pelo git. Para
isso:
➜ rbsdev git rm --
cached a.txt
rm 'a.txt'
Retornando para a versão anterior
Caso você queira remover o commit anterior basta executar
➜ rbsdev git reset --
hard HEAD
HEAD is now at 2921ce7
Feito

REMOVENDO
tracked
.gitignore
Untracked
.gitignore
modiﬁed
.gitignore
staged
.gitignore
adicionado arquivo
alterado arquivo
colocou arquivo no stage
commit
removido arquivo

ARQUITETURA GIT
#1 BASEADOEMCONTEÚDO
#2 OBJETOS
#3 REFERÊNCIAS
#4 LOGS

#1
Vários sistemas de controle versões possuem seu comportamento regido por arquivos, ou
seja em um dado momento você pode ter 3 arquivos versionados e armazenados com o
mesmo conteúdo.
BASEADOEMCONTEÚDO

BASEADOEMCONTEÚDO
Versionando conteúdo
Um arquivo comitado dentro do git nada mais é que seu tipo de
conteúdo comprimido com o algoritmo DEFLATE.
➜ rbsdev nano a1.txt
➜ rbsdev cp a1.txt a2.txt
➜ rbsdev git add a1.txt
➜ rbsdev git commit -m
"a1"
➜ rbsdev git add a2.txt
"a2"
Mantendo enxuto
A organização interna do git apenas organiza as labels
(nome dos arquivos), mas todos realizam o apontamento
para o mesmo objeto.
➜ rbsdev git ls-tree
master
100644 blob
8baef1b4abc478178b004d62031cf7fe6db6
f903 a1.txt
100644 blob
8baef1b4abc478178b004d62031cf7fe6db6
f903 a2.txt

#2
O git possui três tipos básicos de objetos: blobs, trees e Commits. Todos estes tipos de
objetos são armazenados seguindo o padrão chave valor.
OBJETOS
tree
tree
blob
blobblob
README senha.sh 1
a.txt

BLOBS
Encontrando os objetos
Existe uma pasta específica para o git
armazenar todos os objetos criados, que
nada mais são do que os SHAs ordenados.
➜ rbsdev cd .git
➜ .git cd objects
➜ objects cd 5a
➜ 8b ls -la
total 8
drwxr-xr-x 3 helmed staff 102
Aug 7 19:21 .
drwxr-xr-x 19 helmed staff 646
Aug 7 19:34 ..
-r--r--r-- 1 helmed staff 26
Aug 7 19:21
4d77388686f1edbc7223dc1f24d019716ba5
f7
SHA-1 de 40 caracteres
Todo SHA-1 representa unicamente um
conjunto de informações, é possível criar
e recuperar informações dele, veja:
➜ rbsdev echo '!
senha.sh' | git hash-
object --stdin
5a4d77388686f1edbc7223dc1f24d019716b
a5f7
a opção a cima só funciona quando o arquivo
já foi adicionado previamente a árvore de
acompanhamento, o primeiro commit sempre
deve se precedido de uma adição (git add)
TRADUZIR BLOB
Como um arquivo comprimido padrão é
possível ainda realizar o processo
inverso para verificação.
➜ rbsdev git show
5a4d77388686f1edbc7223dc
1f24d019716ba5f7
!senha.sh

TREES
Nome dos arquivos
Os nomes dos arquivos são tratados no git como labels, cada
blob - conjunto de informações - pode ser referenciado por um
ou mais nomes. Estas informações estão guardadas nas trees.
➜ rbsdev git cat-file -p
master
tree 23006095b68e52e1cbef6c7072a22b5c35468d8d
parent 72d3895c3730a69be3462ba30deb3a2bee66e4a6
author Helio Medeiros
<helio.cabralmedeiros@gmail.com> 1375914859 -0300
committer Helio Medeiros
<helio.cabralmedeiros@gmail.com> 1375914859 -0300
23006
100644 blob
5a4d77388686f1edbc7223dc1f24d019716ba5f7 .gitignore
100644 blob
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 README
100644 blob
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 oba.sh
100644 blob
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 rbsdev.sh
100644 blob
46298323bfba1b7e70c2b69a325dbbaa60ec6f5c senha.sh
Estrutura de diretórios
Cada árvore poderá não só referenciar blobs, mas também
outras trees. Cada nova árvore é um objeto com referencias.
➜ rbsdev git show 230060
tree 230060
.gitignore
1/
README
oba.sh
rbsdev.sh
senha.sh

COMMITS
Informações complementares
Para guardar uma versão, além do conteúdo dos arquivos(blob), da sua organização(tree), ainda é necessário definir
quem, quando isto foi realizado e manter a ordem que foi realizado. Para tal é usado o commit.
➜ rbsdev cat .git/HEAD
ref: refs/heads/master
➜ rbsdev cat .git/refs/
heads/master
35efc9e7dbf2febe5dfb23fd64da1c0acbe7a
06f
➜ rbsdev git cat-file -t
35efc9
commit
35efc9
tree
ea39e517ac8020761b53e86c02d7d1854f810
5b7
parent
66884380d0bc05e623b9ef91c3f8d640e3898
be2
author Helio Medeiros
<helio.cabralmedeiros@gmail.com>
1375923522 -0300
committer Helio Medeiros
1375923522 -0300

#3
Você precisa de um arquivo no qual você pode armazenar o SHA-1 com um nome simples
para que você possa usar esse ponteiro e não o valor bruto SHA-1 sempre que precisar de
informações específicas.
REFERÊNCIAS
tree
tree
blob
blob
blob
README
senha.sh
1
a.txt
terceiro commit
segundo commit
primeiro commit
refs/heads/master
refs/heads/branch tree
tree

VARIÁVEIS
Apontando COMMIT especíﬁco
Outro ponto interessante no processo de
versionamento é a definição de TAGS, para as quais
se pode retornar. TAGS para os gits são
marcadores de commit.
➜ rbsdev git tag -a v1.0
-m 'my version 1.0'
v1.0
object
35efc9e7dbf2febe5dfb23fd64da1c0acbe7
a06f
type commit
tag v1.0
tagger Helio Medeiros
<helio.cabralmedeiros@gmail.com> Wed
Aug 7 22:43:58 2013 -0300
my version 1.0
Apontando o último COMMIT
O HEAD é uma referência que aponta para o
nosso último commit por isso o reset HEAD
permite desfazer este commit. Para verificar qual
o SHA do head, faça:
➜ rbsdev cat .git/HEAD
ref: refs/heads/master
➜ rbsdev cat .git/refs/
heads/master
06f
➜ rbsdev git cat-file -t
35efc9
commit

#4
O comando git log mostra os snapshots armazenados. Ele permite listar o histórico do
projeto, filtrá-lo e, além de buscar por mudanças específicas.
LOGS

LOGS
Vendo COMMITS com ﬁrulas
A opção -graph desenha um gráfico dos branchs e
merges. A -decorate acrescenta nomes dos
branches ou tags mostrados. - oneline mostra as
informações do commit em uma única linha.
Vendo todos os COMMITS
Enquanto git status permite que você inspecione a
staging area, o git log permitirá a visualização de
toda a história armazenada, faça:
➜ rbsdev git log
commit
06f
Author: Helio Medeiros
Date: Wed Aug 7 21:58:42 2013 -0300
Novo arquivo na pasta

BRANCHING NO GIT
#1 VISÃOGRÁFICA
#2
#3 NOVO
#4 DIFERENÇA
#5 CONFLITOS
EXISTENTES
#6 REMOVENDO

#1
Para entender toda a mecânica por trás dos branches nada melhor do que ferramentas
para visualizarmos suas criações, distanciação ou aproximação dos demais branches.
VISÃOGRÁFICA

VISÃOGRÁFICA-gitk
Rodando em background
Uma opção interessante é manter o gitk rodando em background
realizando reload das informações quando desejado.
➜ rbsdev gitk --all&
Informações sobre o COMMIT
Quem o fez, perceba que neste ponto a configuração feita
das informações de nome e email são importantes;
Quando o fez;
O que alterou.

#2
Um branch representa uma linha independente de desenvolvimento. Você pode considerá-
los como uma forma de solicitar um novo diretório de trabalho, área e histórico do projeto.
EXISTENTES

EXISTENTES-gitk
Informações sobre o COMMIT
O gitk nos permite acompanhar durante todo o processo de desenvolvimento por meio de árvores de integração
entre branches, mostrando em que estado de versionamento estamos, e quão próximos estamos de integrar versões.

EXISTENTES
Conhecendo os branches atuais
Durante todas as etapas anteriores já estávamos utilizando um branch chamado master que funcionalmente no SVN
corresponde ao trunk, mas na verdade possuí várias diferenças.
➜ rbsdev git branch
* master

#3
Em alguns momentos desejamos desenvolver novas funcionalidades, sejam para testar
hipóteses ou apenas memorizar uma possível ideia.
NOVO

NOVO
Trabalhando em novas funcionalidades
Em alguns momentos desejamos desenvolver novas funcionalidades, sejam para testar hipóteses ou apenas
memorizar uma possível ideia, sem que nenhuma alteração seja memorizada em minha linha central de versionamento,
mantendo builds e deploys funcionais enquanto trabalhamos nestes experimentos.
nova-funcionalidade
* master
nova-funcionalidade
Um novo branch
➜ rbsdev git checkout
nova-funcionalidade
Switched to branch 'nova-
funcionalidade'
Selecionando o branch Situação idêntica

#4
Em toda criação de branch o estado interno dos objetos é igual, mas com o passar do
tempo de desenvolvimento eles tendem a divergir em todos os sentidos.
DIFERENÇA

DIFERENÇA
Fazendo nossas alterações
Agora é hora de fazermos as alterações que desejamos, e esperar que as mesmas se reflitam de alguma forma em
nossa árvore de versões no gitk.
➜ rbsdev touch mnb.sh
➜ rbsdev git commit -v
[nova-funcionalidade 27478a1]
Adicionando novo script
0 files changed
create mode 100644 mnb.sh

DIFERENÇA
Master intocado
Perceba que se você fizer checkout neste
momento voltando para o branch master, não
deverá estar presente nenhum resquício das
alterações que acabamos de executar dentro do
branch nova-funcionalidade:
➜ rbsdev git ls-files
.gitignore
1/1a.txt
README
mnb.sh
oba.sh
rbsdev.sh
senha.sh
master
Switched to branch 'master'
.gitignore
1/1a.txt
README
oba.sh
rbsdev.sh
senha.sh
Branch intocado
Perceba que se realizarmos agora qualquer
alteração no master, as mesmas não refletirão no
branch nova-funcionalidade
➜ rbsdev touch eef.txt
“novo arquivo”
[master a7fc460] novo arquivo
0 files changed
create mode 100644 eef.txt
nova-funcionalidade
Switched to branch 'nova-
funcionalidade'
.gitignore
1/1a.txt
README
mnb.sh
oba.sh
rbsdev.sh
senha.sh

DIFERENÇA
Ramos separados
Veja que agora temos dois ramos bem separados, que mostram a completa independência em termos de alterações e
controles sobre as mesmas.

#5
Gerenciar a existência e os conflitos entre branches é realmente uma arte a ser
aprofundada em anos de experiência. O git simplifica alguns anos.
CONFLITOS

DIFF
Comparando alterações
Se o comando git status for muito vago — você quer saber exatamente o que você alterou, não apenas quais arquivos foram
alterados — você pode utilizar o comando git diff
➜ rbsdev git diff
diff --git a/oba.sh b/oba.sh
index 0694820..56808d7 100644
--- a/oba.sh
+++ b/oba.sh
@@ -1 +1,2 @@
1213abc
+1213abqwweqc

CONFIGURANDODIFFTOOL
Ferramentas para para diferenças
Em vários casos detectar ou conferir alterações entre scripts com várias linhas em um console pode ser complexo. Para isso
existem ferramentas que podem auxiliar nesta analise como o p4merge, que pode ser associado para ser automaticamente
acionado sempre que for necessária uma mescla ou diferenciação entre arquivos.
➜ rbsdev git difftool
UtilizandoConﬁgurando
➜ rbsdev git config --
global diff.tool p4mergetool
global
difftool.p4mergetool.cmd
"/Applications/p4merge.app/
Contents/Resources/
launchp4merge $LOCAL
$REMOTE"
Visualizando

MERGE
Mesclando as alterações
Após a conclusão de uma tarefa é possível integrá-la a linha de desenvolvimento central. Para fazer isso, você fará o merge do
seu branch. Tudo que você tem a fazer é executar o checkout do branch para onde deseja fazer o merge e então rodar o
comando git merge.
master
➜ rbsdev git merge nova-
funcionalidade
Merge made by the 'recursive'
strategy.
0 files changed
create mode 100644 mnb.sh
Merge sem conflitos
master
➜ rbsdev git merge nova-
funcionalidade
Auto-merging arquivo.txt
CONFLICT (content): Merge conflict
in arquivo.txt
Automatic merge failed; fix
conflicts and then commit the
result.
Merge com conflitos
global merge.tool p4mergetool
global
mergetool.p4mergetool.cmd
"/Applications/p4merge.app/
Contents/Resources/
launchp4merge $PWD/$BASE
$PWD/$REMOTE $PWD/$LOCAL
Configurando ferramenta de
merge

REBASE
Trazendo as alterações da equipe diariamente
Com o comando rebase, você pode pegar todas as mudanças que foram commitadas em um branch e as replica
em outro. Você pega o trecho da mudança que foi introduzido no branch e reaplicá-o em cima do trazido do
master.
nova-funcionalidade
➜ rbsdev git rebase
master
First, rewinding head to replay your
work on top of it...
Fast-forwarded nova-funcionalidade to
master.
1 2

CONFLITOS
Resolvendo conﬂitos
Em vários momentos o git não conseguirá apresentar uma solução para os
conflitos gerados entre as várias versões. Os conflitos podem acontecer
durante os merges, commits e rebases. Sempre que um conflito acontece a
ação executada fica incompleta até que os mesmos estejam resolvidos.
nova-funcionalidade
➜ rbsdev git rebase
master
First, rewinding head to replay your
work on top of it...
Applying: Adicionando novo script
Applying: Alterado o o oba.sh
Using index info to reconstruct a base
tree...
M oba.sh
Falling back to patching base and 3-way
merge...
Auto-merging oba.sh
CONFLICT (content): Merge conflict in
oba.sh
Failed to merge in the changes.
Patch failed at 0002 Alterado o o
oba.sh
The copy of the patch that failed is
found in:
/Users/helmed/rbsdev/.git/rebase-
apply/patch
When you have resolved this problem,
run "git rebase --continue".
If you prefer to skip this patch, run
"git rebase --skip" instead.
To check out the original branch and
stop rebasing, run "git rebase --
abort".
Branch temporário
Quando acontecem conflitos durante o rebase e o merge o git prepara um
branch intermediário onde você irá permanecer até concluir a correção
dos conflitos.

#6
Após a conclusão do desenvolvimento de uma nova funcionalidade e sua integração ao
master é interessante a remoção dos branches, mantendo o ambiente limpo.
REMOVENDO

REMOVENDO
Removendo um branch
Caso houver a necessidade de excluir um branch:
master
nova-funcionalidade
* teste
➜ rbsdev git branch -D
teste
error: Cannot delete the branch 'teste'
which you are currently on.
master
➜ rbsdev git branch -D
teste
Deleted branch teste (was 27478a1).
Renomeando um branch
Para renomear um branch:
➜ rbsdev git branch -m
teste test

repositórios
trabalhando em time
#1 MINHASCHAVES
#2 CLONANDO
#3 PUSH
#4 PULL
#5 REMOTE

#1
Quando você passar a trabalhar com repositórios remotos, será necessário autenticar-se
nos servidores com permissões específicas. Para isso será necessários criar chaves
próprias de acesso, assim como configurá-las.
MINHASCHAVES

Minhaschaves
Github via ssh
Uma das opções para acesso a repositórios remotos no
github é utilizando SSH. Para este método será necessária a
criação da configuração local, e junto ao serviço.
➜ ~ cd ~/.ssh
➜ .ssh ls
# Lista dos arquivos do diretório. Caso
não tenha nenhum id_rsa.pub ou
id_dsa.pub continue.
➜ .ssh ssh-keygen -t rsa
-C "qualquer@email.com"
# Creates a new ssh key, using the
provided email as a label
#
Generating public/private rsa key pair.
#
Enter file in which to save the key (/
c/Users/you/.ssh/id_rsa): [Press enter]
Enter passphrase (empty for no
passphrase): [Type a passphrase]
#
Enter same passphrase again: [Type
passphrase again]
➜ .ssh clip < ~/.ssh/
id_rsa.pub
# Copies the contents of the
id_rsa.pub file to your clipboard

#2
Para contribuir com qualquer projeto versionado pelo git, utilizaremos o comando git clone.
Cada versão de cada arquivo no histórico do projeto é obtida quando você roda git clone
CLONANDO

Clonando
As duas formas de clonar
É possível clonar um repositório de duas formas, clonar um repositório local ou um repositório remoto.
Para clonarmos um repositório remoto, normalmente é necessário ter chaves de autenticação ssh/https:
➜ ~ git clone ~/Dropbox/
shared_folder/Regular-
Expressions-Challenges.git
➜ ~ git clone
git@github.com:rbsdev/
Regular-Expressions-
Challenges.git
Cloning into 'Regular-Expressions-
Challenges'...
remote: Counting objects: 149, done.
remote: Compressing objects: 100%
(86/86), done.
remote: Total 149 (delta 53), reused
140 (delta 46)
Receiving objects: 100% (149/149),
20.40 KiB | 0 bytes/s, done.
Resolving deltas: 100% (53/53), done.
Checking connectivity... done

#3
Após realizar todas as alterações locais, chega a hora de enviá-las para o servidor remoto.
Para isso utilizamos o comando push.
PUSH

PUSH
Os demais pushes
Para enviar as alterações feitas no seu
repositório local para o remoto, é
necessário executar o comando:
➜ ~ git push➜ ~ git push origin
master
Primeiro push
É importante lembrar que na primeira vez
que se envia alterações para o repositório
remoto, é necessário definir o branch de
origem do envio.

#4
Após ter clonado um repositório, é possível atualizar seu repositório local com as
atualizações enviadas para o repositório remoto.
PULL

PULL
Mantendo a casa em ordem
É sempre aconselhável atualizar seu repositório local antes de qual quer envio:
➜ ~ git pull

#5
O git nos permite trabalhar com vários repositórios simultaneamente. Para isso temos o
comando remote.
REMOTE

REMOTE
Listando os repositórios
o git nos permite a criação e
compartilhamento de versão totalmente
descentralizado. Para saber todos os
repositórios disponíveis para versionar
execute:
➜ itunesScript git remote
-v
origin git@github.com:helmedeiros/
itunesScript.git (fetch)
origin git@github.com:helmedeiros/
itunesScript.git (push)
Adicionando os
repositórios
Se você desejar compartilhar um
repositório ou alteração local, ou receber
contribuições externas. Basta configurar
um novo repositórios remoto, execute:
add dropbox ~/Dropbox/git/
project.git
Removendo os
repositórios
Em vários momentos será necessária e
indicada a remoção dos alias para
repositórios externos, não mais usados.
rm dropbox

SVN PARA GIT
trabalhando em time
#1 GITSVN
#2 CLONANDO
#3 REBASE
#4 DCOMMIT

Obrigado!
Fontes:
Pro Git - Scott Chacon
http://try.github.io
http://nathanj.github.io
http://gitready.com/
Imagens:
http://git-scm.com/
@evandroeisinger
@helmedeiros
@rssilva

Treinamento git - Papos RBSDev

Mais conteúdo relacionado

Mais procurados (20)

Semelhante a Treinamento git - Papos RBSDev (20)

Mais de Hélio Medeiros (20)

Último (19)

Treinamento git - Papos RBSDev