1. @evandroeisinger @helmedeiros @rssilva --como-morre? --o-que-é? --como-se-cria? --do-que-se-alimenta? --como-nasce? --fácil-branch --seguro TREINAMENTO #paposRBSDev 2. 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/ 3. != 4. Considerando a visão de LINUS TORVALDS “controle de versão do jeito que ele realmente deveria ser” “cvs ou baseado em suas primitivas?” 5. 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 6. PROPOSTAS? Expectativas SUGESTÕES? 7. O QUE É GIT? #1 OffLine #2 DISTRIBUÍDO #3 BRANCHING #4 ENXUTO visão abrangente 8. #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 9. #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 10. #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 11. #4 Diferentemente 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 12. INSTALANDO O GIT #1 DOWNLOAD #2 WINDOWS #3 MACOSX #4 GITCONFIG ambiente configurado 13. #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 14. 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. 15. 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. 16. 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. 17. #2 Instalando o Git no Windows é muito fácil. O projeto msysGit tem um dos procedimentos de instalação mais fácil. WINDOWS 18. 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 19. WINDOWS Adjust your PATH deixe marcado a opção Use Git Bash only e prossiga com a instalação Configure 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 20. #3 Existem algumas maneiras de instalar o git no macosx, as principais envolvem gerenciadores de pacotes como HomeBrew, MacPorts ou Fink. MACOSX 21. 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. 22. 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) 23. #4 Para trabalhar de forma correta com o git o segundo grande passo é realizar as configurações. GITCONFIG 24. 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. 25. COMaNDOS NO GIT #1 NOVOREPOSITÓRIO #2 IGNORANDO #3 ADICIONANDO #4 COMITANDO trabalhando localmente #5 REMOVENDO 26. ├── 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 #1 Para criar um repositório de um diretório de arquivos existente, você pode simplesmente executar git init no diretório NOVOREPOSITÓRIO 27. 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 28. #2 No git é possível especificar arquivos que serão intencionalmente desconsiderados do versionamento. IGNORANDO .gitignore 29. 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 30. 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. 31. IGNORANDO http://gitignore.io/ 32. 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 33. #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 34. 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 ➜ rbsdev git status # On branch master # # Initial commit # # Untracked files: # (use "git add ..." to include in what will be committed) # # .gitignore nothing added to commit but untracked files present (use "git add" to track) .gitignore 35. 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 ➜ rbsdev git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: .gitignore Rastreando Arquivos Para iniciar o rastreamento de um novo arquivo, você deve usar o comando add. Veja: Untracked .gitignore 36. 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 . ➜ rbsdev git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." 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 ..." to unstage) # # new file: a.txt # # Untracked files: # (use "git add ..." 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 ..." to unstage) # # new file: a.txt # new file: a/a.srt 37. #4 Para confirmar e armazenar as alterações realizadas perante o histórico do git é necessário realizar o commit. COMITANDO Untracked tracked staged 38. 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: ➜ rbsdev git commit - 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: ➜ 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 39. #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 40. 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 41. REMOVENDO tracked .gitignore Untracked .gitignore modified .gitignore staged .gitignore adicionado arquivo alterado arquivo colocou arquivo no stage commit removido arquivo 42. ARQUITETURA GIT #1 BASEADOEMCONTEÚDO #2 OBJETOS #3 REFERÊNCIAS #4 LOGS reconhecendo soluções 43. #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 44. 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 ➜ rbsdev git commit -m "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 45. #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 46. 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 47. 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 1375914859 -0300 committer Helio Medeiros 1375914859 -0300 ➜ rbsdev git cat-file -p 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 48. 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 ➜ rbsdev git cat-file -p 35efc9 tree ea39e517ac8020761b53e86c02d7d1854f810 5b7 parent 66884380d0bc05e623b9ef91c3f8d640e3898 be2 author Helio Medeiros 1375923522 -0300 committer Helio Medeiros 1375923522 -0300 49. #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 50. VARIÁVEIS Apontando COMMIT específico 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' ➜ rbsdev git cat-file -p v1.0 object 35efc9e7dbf2febe5dfb23fd64da1c0acbe7 a06f type commit tag v1.0 tagger Helio Medeiros 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 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a 06f ➜ rbsdev git cat-file -t 35efc9 commit 51. #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 52. LOGS Vendo COMMITS com firulas 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 35efc9e7dbf2febe5dfb23fd64da1c0acbe7a 06f Author: Helio Medeiros Date: Wed Aug 7 21:58:42 2013 -0300 Novo arquivo na pasta 53. BRANCHING NO GIT #1 VISÃOGRÁFICA #2 #3 NOVO #4 DIFERENÇA reconhecendo soluções #5 CONFLITOS EXISTENTES #6 REMOVENDO 54. #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 55. 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. 56. #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 57. 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. 58. 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 59. #3 Em alguns momentos desejamos desenvolver novas funcionalidades, sejam para testar hipóteses ou apenas memorizar uma possível ideia. NOVO 60. 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. ➜ rbsdev git branch nova-funcionalidade ➜ rbsdev git branch * master nova-funcionalidade Um novo branch ➜ rbsdev git checkout nova-funcionalidade Switched to branch 'nova- funcionalidade' Selecionando o branch Situação idêntica 61. #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 62. 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 add . ➜ rbsdev git commit -v [nova-funcionalidade 27478a1] Adicionando novo script 0 files changed create mode 100644 mnb.sh 63. 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 ➜ rbsdev git checkout master Switched to branch 'master' ➜ rbsdev git ls-files .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 ➜ 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-funcionalidade Switched to branch 'nova- funcionalidade' ➜ rbsdev git ls-files .gitignore 1/1a.txt README mnb.sh oba.sh rbsdev.sh senha.sh 64. 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. 65. #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 66. 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 67. 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 UtilizandoConfigurando ➜ rbsdev git config -- global diff.tool p4mergetool ➜ rbsdev git config -- global difftool.p4mergetool.cmd "/Applications/p4merge.app/ Contents/Resources/ launchp4merge $LOCAL$REMOTE" Visualizando 68. 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. ➜ rbsdev git checkout master Switched to branch 'master' ➜ rbsdev git merge nova- funcionalidade Merge made by the 'recursive' strategy. 0 files changed create mode 100644 mnb.sh Merge sem conflitos ➜ rbsdev git checkout master Switched to branch '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 ➜ 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 69. 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. ➜ rbsdev git checkout 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 70. CONFLITOS Resolvendo 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 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. 71. #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 72. REMOVENDO Removendo um branch Caso 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 teste Deleted branch teste (was 27478a1). Renomeando um branch Para renomear um branch: ➜ rbsdev git branch -m teste test 73. repositórios trabalhando em time #1 MINHASCHAVES #2 CLONANDO #3 PUSH #4 PULL #5 REMOTE 74. #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 75. 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 "
[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 76. #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 77. 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
[email protected]: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 78. #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 79. 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. 80. #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 81. PULL Mantendo a casa em ordem É sempre aconselhável atualizar seu repositório local antes de qual quer envio: ➜ ~ git pull 82. #5 O git nos permite trabalhar com vários repositórios simultaneamente. Para isso temos o comando remote. REMOTE 83. 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
[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 84. SVN PARA GIT trabalhando em time #1 GITSVN #2 CLONANDO #3 REBASE #4 DCOMMIT 85. 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