Download - Git Overview: Grupo RBS
@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 eficiê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 configurado
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
#1Git 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
#2Assim 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
#3O 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
#4Diferentemente do SVN, o git possuí apenas um diretório na raiz do projeto, sem necessidade ou possibilidade de ser afetado negativamente com mudanças de nomes e pastas.
ENXUTO
.|-- .git|-- Rakefile|-- lib| |-- pascals_triangle.rb| |-- pretty_printed_array.rb|-- pascals_triangle.gemspec
.|-- .svn| |-- all-wcprops| |-- entries| |-- format| |-- prop-base| |-- props| |-- text-base| | |-- Rakefile.svn-base|.. Rakefile|.. lib| |-- .svn| | |-- all-wcprops| | |-- entries| | |-- format
INSTALANDO O GIT
#1 DOWNLOAD
#2 WINDOWS
#3 MACOSX
#4 GIT CONFIG
ambiente configurado
#1Dependendo 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
DOWNLOADPara 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.
DOWNLOADPara 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.
DOWNLOADPara 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.
#2Instalando o Git no Windows é muito fácil. O projeto msysGit tem um dos procedimentos de instalação mais fácil.
WINDOWS
WINDOWS
Execute o instaladorClique em avançar (Next) até chegar na
etapa seguinte
Select ComponentsMarque a opção Simple context menu. Feito isso, avance para próxima tela
Select Start Menu Folderdeixe 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 PATHdeixe marcado a opção Use Git Bash only
e prossiga com a instalação
Configure the line endingmarque a primeira opção para quebras de linha independente do sistema operacional
Completing the git setupinstalação foi concluída com sucesso
#3Existem algumas maneiras de instalar o git no macosx, as principais envolvem gerenciadores de pacotes como HomeBrew, MacPorts ou Fink.
MACOSX
MACOSX - Instalando
Instalando com BrewTendo o brew instalado você só precisa
fazer:
➜ ~ brew install git
Instalando com PortTendo o port instalado você só precisa
fazer:
Instalando com FinkTendo 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 instaladoDepois de instalado você deve conseguir ver onde o mesmo foi instalado, rodando
o comando:
➜ ~ which git /usr/bin/git
Qual versão instaladaApó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 --versiongit version 1.7.12.4 (Apple Git-37)
➜ ~ man gitGIT(1) Git Manual GIT(1)
#4Para trabalhar de forma correta com o git o segundo grande passo é realizar as configurações.
GIT CONFIG
GIT CONFIG
Verificar configuraçõesPara verificar todas as configurações de
sua máquina use o comando:
➜ ~ git config --list
➜ ~ git config --list --global
Adicionando configCaso 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 configCaso 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 NOVO REPOSITÓRIO
#2 IGNORANDO
#3 ADICIONANDO
#4 COMITANDO
trabalhando localmente
#5 REMOVENDO
├── HEAD├── branches├── config├── 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
#1Para criar um repositório de um diretório de arquivos existente, você pode simplesmente executar git init no diretório
NOVO REPOSITÓRIO
NOVO REPOSITÓRIO
Os arquivos a versionar Por exemplo, digamos que temos um
diretório com alguns arquivos nele, como:
➜ ~ cd rbsdev➜ rbsdev lsREADME rbsdev.sh
Criando o repositórioPara iniciar o controle de versão disso
com Git, podemos simplesmente executar git init, como:
➜ ~ git initInitialized empty Git repository in /Users/helmed/rbsdev/.git/
Novo diretórioApós a criação o git define um
diretório para armazenamento de versões
➜ ~ ls -la. .. .git README rbsdev.sh
#2No git é possível especificar arquivos que serão intencionalmente desconsiderados do versionamento.
IGNORANDO
.gitignore
IGNORANDO
Começando a IgnorarPara 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 IgnorarAtravé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.Trashesehthumbs.dbThumbs.db
IGNORANDO
Regras para qualquer diretóriovocê 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.
IGNORANDORodando 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
#3Quando 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 arquivosEm 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
➜ rbsdev git status# On branch master## Initial commit## Untracked files:# (use "git add <file>..." to include in what will be committed)## .gitignorenothing added to commit but untracked files present (use "git add" to track)
.gitignore
ADICIONANDO
Arquivos não rastreadosUntracked 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➜ rbsdev git status# On branch master## Initial commit## Changes to be committed:# (use "git rm --cached <file>..." to unstage)## new file: .gitignore
Rastreando ArquivosPara iniciar o rastreamento de um novo arquivo, você deve usar o
comando add. Veja:
Untracked
.gitignore
ADICIONANDO
Várias formas de adiçãoPara adicionar arquivos em um commit, é necessário executar um comando que insira ele no commit:
➜ rbsdev git add .➜ rbsdev git status# On branch master## Initial commit## Changes to be committed:# (use "git rm --cached <file>..." to unstage)## new file: .gitignore
➜ rbsdev touch a.txt➜ rbsdev git add *.txt➜ rbsdev git status# On branch master## Initial commit## Changes to be committed:# (use "git rm --cached <file>..." 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➜ rbsdev git status# On branch master## Initial commit## Changes to be committed:# (use "git rm --cached <file>..." to unstage)## new file: a.txt# new file: a/a.srt
#4Para 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 commitTambém é possível executar um commit
que já adicione todos os arquivos modificados:
➜ rbsdev git commit -a -m "Descrição do commit"[master 30bf45a] Descrição do commit 0 files changed create mode 100644 .gitignore
Diff no commitSe for desejado é possível adicionar a
mensagem de commit o diff da alteração, adicionando a opção -v:
➜ rbsdev git commit -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
#5O 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 untrackedCom o comando certo é possível fazer com que um arquivo não seja mais ratreado pelo git. Para
isso:
➜ rbsdev git rm --cached a.txtrm 'a.txt'
Retornando para a versão anteriorCaso você queira remover o commit anterior basta executar
➜ rbsdev git reset --hard HEADHEAD is now at 2921ce7 Feito
REMOVENDO
tracked
.gitignore
Untracked
.gitignore
modified
.gitignore
staged
.gitignore
adicionado arquivo
alterado arquivo
colocou arquivo no stage
commit
removido arquivo
ARQUITETURA GIT
#1 BASEADO EM CONTEÚDO
#2 OBJETOS
#3 REFERÊNCIAS
#4 LOGS
reconhecendo soluções
#1Vá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.
BASEADO EM CONTEÚDO
BASEADO EM CONTEÚDO
Versionando conteúdoUm 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 ➜ rbsdev git commit -m "a2"
Mantendo enxutoA 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 master100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903a1.txt100644 blob 8baef1b4abc478178b004d62031cf7fe6db6f903a2.txt
#2O 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 objetosExiste 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 -latotal 8drwxr-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 4d77388686f1edbc7223dc1f24d019716ba5f7
SHA-1 de 40 caracteresTodo 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 5a4d77388686f1edbc7223dc1f24d019716ba5f7
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 BLOBComo um arquivo comprimido padrão é
possível ainda realizar o processo inverso para verificação.
➜ rbsdev git show 5a4d77388686f1edbc7223dc1f24d019716ba5f7!senha.sh
TREES
Nome dos arquivosOs 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 mastertree 23006095b68e52e1cbef6c7072a22b5c35468d8dparent 72d3895c3730a69be3462ba30deb3a2bee66e4a6author Helio Medeiros <[email protected]> 1375914859 -0300committer Helio Medeiros <[email protected]> 1375914859 -0300
➜ rbsdev git cat-file -p 23006 100644 blob 5a4d77388686f1edbc7223dc1f24d019716ba5f7 .gitignore100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 README100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 oba.sh100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 rbsdev.sh100644 blob 46298323bfba1b7e70c2b69a325dbbaa60ec6f5c senha.sh
Estrutura de diretóriosCada árvore poderá não só referenciar blobs, mas também
outras trees. Cada nova árvore é um objeto com referencias.
➜ rbsdev git show 230060tree 230060
.gitignore1/READMEoba.shrbsdev.shsenha.sh
COMMITS
Informações complementaresPara 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/HEADref: refs/heads/master➜ rbsdev cat .git/refs/heads/master 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a06f➜ rbsdev git cat-file -t 35efc9commit
➜ rbsdev git cat-file -p 35efc9tree ea39e517ac8020761b53e86c02d7d1854f8105b7parent 66884380d0bc05e623b9ef91c3f8d640e3898be2author Helio Medeiros <[email protected]> 1375923522 -0300committer Helio Medeiros <[email protected]> 1375923522 -0300
#3Você 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
treetree
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íficoOutro 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'➜ rbsdev git cat-file -p v1.0 object 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a06ftype committag v1.0tagger Helio Medeiros <[email protected]> Wed Aug 7 22:43:58 2013 -0300
my version 1.0
Apontando o último COMMITO 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/HEADref: refs/heads/master➜ rbsdev cat .git/refs/heads/master 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a06f➜ rbsdev git cat-file -t 35efc9commit
#4O 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 firulasA 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 COMMITSEnquanto 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 logcommit 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a06fAuthor: Helio Medeiros <[email protected]>Date: Wed Aug 7 21:58:42 2013 -0300
Novo arquivo na pasta
BRANCHING NO GIT
#1 VISÃO GRÁFICA#2
#3 NOVO#4 DIFERENÇA
reconhecendo soluções
#5 CONFLITOS
EXISTENTES
#6 REMOVENDO
#1Para 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ÃO GRÁFICA
VISÃO GRÁFICA - gitk
Rodando em backgroundUma opção interessante é manter o gitk rodando em background
realizando reload das informações quando desejado.
➜ rbsdev gitk --all&
Informações sobre o COMMITQuem 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.
#2Um 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 - gitkInformaçõ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.
EXISTENTESConhecendo 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
#3Em alguns momentos desejamos desenvolver novas funcionalidades, sejam para testar hipóteses ou apenas memorizar uma possível ideia.
NOVO
NOVOTrabalhando 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.
➜ rbsdev git branch nova-funcionalidade➜ rbsdev git branch* masternova-funcionalidade
Um novo branch
➜ rbsdev git checkout nova-funcionalidadeSwitched to branch 'nova-funcionalidade'
Selecionando o branch Situação idêntica
#4Em 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ÇAFazendo 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 add .➜ rbsdev git commit -v[nova-funcionalidade 27478a1] Adicionando novo script 0 files changed create mode 100644 mnb.sh
DIFERENÇAMaster 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.gitignore1/1a.txtREADMEmnb.shoba.shrbsdev.shsenha.sh➜ rbsdev git checkout masterSwitched to branch 'master'➜ rbsdev git ls-files.gitignore1/1a.txtREADMEoba.shrbsdev.shsenha.sh
Branch intocadoPerceba que se realizarmos agora qualquer
alteração no master, as mesmas não refletirão no branch nova-funcionalidade
➜ rbsdev touch eef.txt➜ rbsdev git add .➜ rbsdev git commit -m “novo arquivo”[master a7fc460] novo arquivo 0 files changed create mode 100644 eef.txt➜ rbsdev git checkout nova-funcionalidadeSwitched to branch 'nova-funcionalidade'➜ rbsdev git ls-files.gitignore1/1a.txtREADMEmnb.shoba.shrbsdev.shsenha.sh
DIFERENÇARamos 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.
#5Gerenciar 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çõesSe 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 diffdiff --git a/oba.sh b/oba.shindex 0694820..56808d7 100644--- a/oba.sh+++ b/oba.sh@@ -1 +1,2 @@ 1213abc+1213abqwweqc
CONFIGURANDO DIFFTOOL
Ferramentas para para diferençasEm 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
UtilizandoConfigurando
➜ rbsdev git config --global diff.tool p4mergetool➜ rbsdev git config --global difftool.p4mergetool.cmd
"/Applications/p4merge.app/Contents/Resources/launchp4merge \$LOCAL \$REMOTE"
Visualizando
MERGE
Mesclando as alteraçõesApó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.
➜ rbsdev git checkout masterSwitched to branch 'master'➜ rbsdev git merge nova-funcionalidadeMerge made by the 'recursive' strategy. 0 files changed create mode 100644 mnb.sh
Merge sem conflitos
➜ rbsdev git checkout masterSwitched to branch 'master'➜ rbsdev git merge nova-funcionalidadeAuto-merging arquivo.txtCONFLICT (content): Merge conflict in arquivo.txtAutomatic merge failed; fix conflicts and then commit the result.
Merge com conflitos
➜ rbsdev git config --global merge.tool p4mergetool➜ rbsdev git config --global mergetool.p4mergetool.cmd"/Applications/p4merge.app/Contents/Resources/launchp4merge \$PWD/\$BASE \$PWD/\$REMOTE \$PWD/\$LOCAL
Configurando ferramenta de merge
REBASETrazendo 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.
➜ rbsdev git checkout nova-funcionalidade➜ rbsdev git rebase masterFirst, rewinding head to replay your work on top of it...Fast-forwarded nova-funcionalidade to master.
1 2
CONFLITOSResolvendo conflitos
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.
➜ rbsdev git checkout nova-funcionalidade➜ rbsdev git rebase masterFirst, rewinding head to replay your work on top of it...Applying: Adicionando novo scriptApplying: Alterado o o oba.shUsing index info to reconstruct a base tree...M oba.shFalling back to patching base and 3-way merge...Auto-merging oba.shCONFLICT (content): Merge conflict in oba.shFailed to merge in the changes.Patch failed at 0002 Alterado o o oba.shThe 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árioQuando 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.
#6Apó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 branchCaso houver a necessidade de excluir um branch:
➜ rbsdev git branch master nova-funcionalidade* teste➜ rbsdev git branch -D teste error: Cannot delete the branch 'teste' which you are currently on.➜ rbsdev git checkout master Switched to branch 'master'➜ rbsdev git branch -D testeDeleted branch teste (was 27478a1).
Renomeando um branchPara renomear um branch:
➜ rbsdev git branch -m teste test
repositórios
trabalhando em time
#1 MINHAS CHAVES
#2 CLONANDO
#3 PUSH
#4 PULL#5 REMOTE
#1Quando 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.
MINHAS CHAVES
Minhas chavesGithub 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 "[email protected]"# 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
#2Para 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
ClonandoAs 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 [email protected]:rbsdev/Regular-Expressions-Challenges.gitCloning 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
#3Apó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 pushesPara 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.
#4Após ter clonado um repositório, é possível atualizar seu repositório local com as atualizações enviadas para o repositório remoto.
PULL
PULLMantendo a casa em ordem
É sempre aconselhável atualizar seu repositório local antes de qual quer envio:
➜ ~ git pull
#5O git nos permite trabalhar com vários repositórios simultaneamente. Para isso temos o comando remote.
REMOTE
REMOTEListando 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 -vorigin [email protected]:helmedeiros/itunesScript.git (fetch)origin [email protected]: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:
➜ itunesScript git remote 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.
➜ itunesScript git remote rm dropbox
SVN PARA GIT
trabalhando em time
#1 GIT SVN
#2 CLONANDO
#3 REBASE
#4 DCOMMIT
Obrigado!
Fontes:Pro Git - Scott Chaconhttp://try.github.iohttp://nathanj.github.iohttp://gitready.com/
Imagens:http://git-scm.com/
@evandroeisinger@helmedeiros
@rssilva