Introdução ao Controle de Versão com Git. Software Carpentry

Transcrição

1 Introdução ao Controle de Versão com Git Software Carpentry

2 2

3 Sumário 1 Introdução ao Controle de Versão com Git 7 Pré-requisitos Tópicos Outros recursos Configurando o Git 9 Objetivos Proxy Criando um repositório 13 Objetivos Onde posso criar meu repositório? Monitorando alterações 15 Objetivos Onde estão minhas mudanças? Comitando alterações no Git Repositório bio Explorando o histórico 25 Objetivos Simplificando o Caso Comum Recuperando versões antigas de um arquivo

4 4 SUMÁRIO 6 Ignorando Arquivos 31 Objetivos Colaborando 35 Objetivos HTTPS vs SSH Proxy Gerenciadores de Senhas A opção -u Praticando sozinho Marcação de tempo no GitHub Conflitos 45 Objetivos Resolvendo conflitos que você criou Conflitos em arquivos que não são texto plano Ciência Aberta 51 Objetivo Controle de versão de cadernos de anotações científicos eletrônicos.. 52 Licenciamento Licenciamento de produtos que não são programas de computador 54 Hospedagem Posso utilizar uma licença aberta? Posso utilizar uma licença aberta? Meu trabalho pode ser público? Motivação 59 Por que utilizar Controle de Versão? Por que Git? Próximos Passos

5 SUMÁRIO 5 11 Referência 61 Configurando o Git Criando um repositório Monitorando alterações Explorando o histórico Ignorando Arquivos Colaborando Conflitos Ciência Aberta Glossário Discussão 65 Frequently Asked Questions More Advanced Git Configuration Styling Git s Log Version Controlling the Gitconfig Non-text Files Non-text Version Control Guia para Instrutores 71 Legend Overall Teaching Notes Setting Up Git Creating a Repository Tracking Changes Exploring History Ignoring Things Collaborating Conflicts Open Science

6 6 SUMÁRIO 14 Licença 75 Material Software Trademark

7 Capítulo 1 Introdução ao Controle de Versão com Git Lobisomem e Drácula foram contratados pelo Universal Missions (uma agência de serviços espaciais da Euphoric State University) para descobrir onde a companhia deveria enviar sue próximo robô explorador. Eles desejam trabalhar nos planos ao mesmo tempo mas tiveram problemas ao fazer isso no passado. Se eles trabalharem em turnos, cada um deles irá gastar muito tempo esperando o outro terminar mas se eles trabalharem em sua cópia e trocarem s com as mudanças alguma coisa acabará se perdendo, sendo reescrita ou duplicada. A solução é eles utilizarem controle de versão para gerenciar o trabalho. Controle de versão é melhor que trocar arquivos por pois: Nada que é salva no controle de versão pode ser perdido. Isso significa que ele pode ser utilizado como a ferramenta desfazer de um editor de texto e como todas as versões anteriores dos arquivos estão salvas sempre é possível voltar no tempo para saber quem escreveu o que em um dia particular ou que versão de um programa foi utilizado para gerar um resultado. Ele mantem um registro de quem fez cada mudança e quando ela foi feita e assim, se alguém tiver perguntas depois saberá a quem perguntar. É difícil (mas não impossível) de acidentalmente sobrescrever as mudanças de alguém: o sistema de controle de versão automaticamente avisa o usuário quando existe um conflito entre o trabalho de duas ou mais pessoas. Controle de versão é o caderno de laboratório do mundo digital: é o que profissionais utilizam para manter registro do que fizeram e para colaborar com outras pessoas. Todo grande projeto de desenvolvimento de software depende dele, e vários programadores também o utilizam para seus pequenos projetos. E ele não é utilizado apenas para software: livros (como esse), artigos, pequenos 7

8 8 CAPÍTULO 1. INTRODUÇÃO AO CONTROLE DE VERSÃO COM GIT conjuntos de dados, e qualquer coisa que é modificado ao longo do tempo ou precisa ser compartilhada pode e deveria ser armazenado em um sistema para controle de versão. Pré-requisitos Nessa lição utilizamos Git pela linha de comando e por isso espera-se uma experiência prévia com ela embora isso não seja obrigatório. Tópicos 1. Configurando o Git 2. Criando um repositório 3. Monitorando alterações 4. Explorando o histórico 5. Ignorando Arquivos 6. Colaborando 7. Conflitos 8. Ciência Aberta Outros recursos Motivação Referência Discussão Guia do Instrutor

9 Capítulo 2 Configurando o Git Objetivos Explicar os passos de inicialização e configuração necessários por máquina e por repositório. Nós vamos começar explorando como o controle de versão pode ser utilizado para manter o registro do que e de quando uma pessoa fez algo. Mesmo se você não estiver colaborando com outros, controle de versão é muito melhor que: 9

10 10 CAPÍTULO 2. CONFIGURANDO O GIT Piled Higher and Deeper by Jorge Cham, Na primeira vez que utilizamos Git em uma máquina, precisamos configurar algumas coisas. A seguir encontra-se o que Drácula fez para configurar seu novo notebook: $ git config --global user.name "Vlad Dracula"

11 PROXY 11 $ git config --global user. "vlad@tran.sylvan.ia" $ git config --global color.ui "auto" (Por favor, utilize seu nome e endereço de ao invés do de Drácula) Ele também configurou seu editor favorito utilizando a tabela a seguir. Editor nano Text Wrangler Sublime Text (Mac) Sublime Text (Win) Notepad++ (Win) Kate (Linux) Gedit (Linux) Configuration command $ git config --global core.editor "nano -w" $ git config --global core.editor "edit -w" $ git config --global core.editor "subl -n -w" $ git config --global core.editor "'c:/program files/sublime text 2/sublime_te $ git config --global core.editor "'c:/program files (x86)/notepad++/notepad++ $ git config --global core.editor "kate" $ git config --global core.editor "gedit -s" Os commandos do Git são escritos como git verbo, onde verbo é o que desejamos fazer. No caso anterior, estamos dizendo para o Git: nosso nome e endereço de , para colorir a saída, qual o nosso editor de texto favorito, e que queremos utilizar essas informações globalmente (i.e., para todo projeto). Os quatro comandos anteriores só precisam ser executados uma vez: a opção (em inglês denominada de flag) --global diz para o Git utilizar as configurações para todo projeto na máquina atual. You can check your settings at any time: $ git config --list Proxy Em alguns casos você precisa utilizar um proxy para se conectar a internet. Se esse for o seu caso você precisa informar o Git sobre o proxy: $ git config --global http.proxy proxy-url $ git config --global https.proxy proxy-url Para desabilitar o proxy, utilize

12 12 CAPÍTULO 2. CONFIGURANDO O GIT $ git config --global --unset http.proxy $ git config --global --unset https.proxy

13 Capítulo 3 Criando um repositório Objetivos Explicar como criar um repositório Git local. Uma vez que Git está configurado, podemos começar a utilizá-lo. Vamos criar um diretório para nosso trabalho: $ mkdir planetas $ cd planetas e dizemos para fazer do diretório um repositório um lugar onde Git irá armazenar as versões anteriores de nossos arquivos: $ git init Se utilizarmos ls para mostrar o conteúdo do diretório irá parecer que nada foi feito: $ ls Mas se adicionarmos a opção -a para mostrar todos os arquivos, iremos ver que Git criou um diretório oculto denominado.git: $ ls -a....git 13

14 14 CAPÍTULO 3. CRIANDO UM REPOSITÓRIO Git armazena informações sobre o projeto nesse subdiretório especial. Se deletarmos ele iremos perder o histórico do projeto. Podemos verificar que a configuração foi feita com sucesso requisitando o estado do nosso projeto para o Git: $ git status # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track) Onde posso criar meu repositório? A seguinte sequencia de comandos cira um repositório Git dentro de outro: cd mkdir alpha cd alpha git init mkdir beta cd beta git init # retorna para sua pasta de usuário # cria um novo repositório # muda o diretório atual para o diretório recém criado # transforma o diretório recém criado em um repositório Git # cria um subdiretório # muda o diretório atual para o subdiretório recém criado # transforma o subdiretório em um repositório Git Por que utilizar um repositório Git dentro de outro é uma péssima ideia?

15 Capítulo 4 Monitorando alterações Objetivos Passar o ciclo modicar-adicionar-salvar para um único arquivo e para múltiplos arquivos. Explicar onde a informação é armazenada em cada estágio. Vamos criar um arquivo chamado marte.txt que contém algumas notas sobre a sustentabilidade de uma base no planeta vermelho. (Iremos utilizar um editor chamado nano para editar o arquivo mas você pode utilizar o editor de sua preferência. Em particular, ele não precisa ser o mesmo editor informado para o Git). $ nano marte.txt Escreva o texto abaixo no arquivo marte.txt: Frio e seco, mas tudo é da minha cor favorita. marte.txt agora contem a seguinte linha: $ ls marte.txt $ cat marte.txt Frio e seco, mas tudo é da minha cor favorita. 15

16 16 CAPÍTULO 4. MONITORANDO ALTERAÇÕES Se verificarmos o estado do nosso projeto novamente, Git irá informar que ele encontrou um novo arquivo: $ git status # On branch master # # Initial commit # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # marte.txt nothing added to commit but untracked files present (use "git add" to track) A mensagem untracked files significa que existe um arquivo no diretório que Git não está monitorando. Iremos dizer para o Git que ele deve fazê-lo utilizando git add: $ git add marte.txt e então verificamos alteração na mensagem de estado: $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: marte.txt # Git agora sabe que ele deve monitorar o arquivo marte.txt mas ele ainda não salvou nenhuma mudança para a posterioridade como um commit. Para fazer isso precisamos executar mais um comando: $ git commit -m "Começando a tomar notas sobre Marte como um base" [master (root-commit) f22b25e] Começando a tomar notas sobre Marte como um base 1 file changed, 1 insertion(+) create mode marte.txt

17 ONDE ESTÃO MINHAS MUDANÇAS? 17 Quando executamos git commit, Git pega todas as mudanças que informamos precisar serem salvas quando utilizamos git add e armazena uma cópia permanente dentro do diretório especial.git. Essa cópia permanente é denominada revisão é brevemente identificada por f22b25e. (Sua revisão pode ter um identificador diferente.) Utilizamos a opção -m (de mensagem ) para salvar um pequeno comentário que seja descritivo e específico que irá nos ajudar a lembrar depois o que fizemos e porque. Se apenas executarmos git commit sem a opção -m, Git irá iniciar nano (ou o editor que tivermos configurado no início) para que possamos escrever um comentário longo. Boas mensagens de commit iniciam com um curto sumário (menos de 50 caracteres) das alterações feitas no commit. Se você desejar adicionar mais detalhes, adicione uma linha em branco entre o sumário e suas notas adicionais. Se executarmos git status agora: $ git status # On branch master nothing to commit, working directory clean Git está dizendo que tudo está atualizado. Se desejarmos saber o que foi feito recentemente podemos pedir ao Git que mostre o histórico do projeto utilizando git log: $ git log commit f22b25e3233b4645dabd0d81e651fe074bd8e73b Author: Vlad Dracula <vlad@tran.sylvan.ia> Date: Thu Aug 22 09:51: Começando a tomar notas sobre Marte como um base git log lista todas as revisões salvas em um repositório na ordem cronológica reversa. Essa lista inclui, para cada revisão, o identificador completo da revisão (que inicia com os mesmos caracteres que o identificador curto impresso pelo comando git commit anteriormente), o autor da revisão, quando ela foi criada e o comentário dado à revisão quando ela foi criada. Onde estão minhas mudanças? Se executarmos ls agora continuamos a encontrar apenas um arquivo chamado marte.txt. Isso deve-se ao fato do Git salvar as informações

18 18 CAPÍTULO 4. MONITORANDO ALTERAÇÕES com histórico dos arquivos no diretório especial denominado.git mencionado anteriormente tal que nosso sitema de arquivos não fique cheio (e nós acidentalmente editemos ou removemos uma versão anterior. Agora suponha adicionou algumas informações ao arquivo. (Novamente, editaremos o arquivo utilizando o nano e utilizaremos o commando cat para mostrar o conteúdo do arquivo; você pode utilizar outro editor e não precisa do comando cat.) $ nano marte.txt $ cat marte.txt Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. Quando executamos o comando git status, ele irá informar que um arquivo sendo monitorado foi alterado: $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: marte.txt # no changes added to commit (use "git add" and/or "git commit -a") A última linha, no changes added to commit, é importante e nos avisa que nenhuma das mudanças feitas será salvo na próxima revisão. Embora tenhamos alterado o arquivo não informamos ao Git que queremos salvar essas mudanças (que iremos fazer utilizando git add). Para verificar as alterações nos arquivos utilizamos git diff, que irá mostrar a diferença entre o estado atual dos arquivo e a última revisão salva: $ git diff diff --git a/marte.txt b/mars.txt index df0654a..315bf3a a/marte.txt Frio e seco, mas tudo é da minha cor favorita. +Duas luas pode ser um problema para o Lobisomem.

19 ONDE ESTÃO MINHAS MUDANÇAS? 19 A saída parecer criptografada porque na verdade é uma série de comandos dizendo para programas como editores de texto e patch como reconstruir um arquivo partindo do outro. Podemos quebrar essa saída em algumas partes: 1. A primeira linha informa que Git utilizou o comando diff para comparar a versão antiga com a nova. 2. A segunda linha informa exatamente quais revisões Git está comparando: df0654a e 315bf3a são identificadores únicos gerados pelo computador para essas duas revisões. 3. As linhas restantes mostram o que realmente mudou e as linhas correspondentes. Em particular, o sinal + na primeira coluna indica onde adicionamos novas linhas. Vamos salvar nossas mudanças: $ git commit -m "Adicionado preocupação sobre o feito das luas de Marte no Lobisomem" # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: marte.txt # no changes added to commit (use "git add" and/or "git commit -a") Hoops: Git não salvou uma nova revisão porque esquecemos de utilizar o comando git add primeiro. Vamos corrigir isso: $ git add marte.txt $ git commit -m "Adicionado preocupação sobre o feito das luas de Marte no Lobisomem" [master 34961b1] Adicionado preocupação sobre o feito das luas de Marte no Lobisomem 1 file changed, 1 insertion(+) Git insiste que adicionemos os arquivos ao grupo a ser salvo antes de realmente criarmos uma nova revisão porque podemos não querer incluir todas as mudanças de uma vez. Por exemplo, suponha que estejamos adicionando algumas citações ao trabalho de nosso orientador na nossa tese. Pode ser que desejamos ter uma versão em que adicionamos as citações e as referências bibliográficas mas não desejamos incluir as mudanças na conclusão uma vez que ainda não terminamos esta. Para que isso seja possível, Git possui uma área temporária especial (em inglês denominada staging area) onde ele mantem o registro das alterações que foram

20 20 CAPÍTULO 4. MONITORANDO ALTERAÇÕES adicionadas ao conjunto a ser utilizado para o próximo commit (que ainda não foi feito). git add coloca as modificações nessa área e git commit move a informação dessa área para o armazenamento de longo termo na forma de um commit. Figura 4.1: The Git Staging Area Vamos verificar como nossas mudanças são transmitidas do nosso editor para a área temporária e posteriormente para o armazenamento de longo termo. Primeiro, precisamos adicionar uma nova linha ao arquivo: $ nano marte.txt $ cat marte.txt Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. Mas a Múmia irá apreciar a falta de humidade. $ git diff diff --git a/marte.txt b/mars.txt index 315bf3a..b36abfd a/marte.txt ,2 Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. Até agora, tudo bem: adicionamos uma nova linha no final do arquivo (identificada com o sinal + na primeira coluna). Agora vamos colocar essa mudança na área temporária e verificar o que git diff informa:

21 ONDE ESTÃO MINHAS MUDANÇAS? 21 $ git add marte.txt $ git diff Não existe saída pois até onde o Git consegue informar não existe diferença entre o que foi pedido para salvar permanentemente e o arquivos no repositório. Entretanto, se pedirmos: $ git diff --staged diff --git a/marte.txt b/mars.txt index 315bf3a..b36abfd a/marte.txt ,2 Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. será mostrado a diferença entre o último commit e as mudanças na área temporária. Vamos salvar nossa mudança: $ git commit -m "Discussão sobre o clima de Marte para a Múmia" [master f] Discussão sobre o clima de Marte para a Múmia 1 file changed, 1 insertion(+) e verificar o estado do repositório: $ git status # On branch master nothing to commit, working directory clean e também no histórico do que foi feito até agora: $ git log commit fbe2a98fb83f0ade869025dc2636b4dad5 Author: Vlad Dracula <vlad@tran.sylvan.ia> Date: Thu Aug 22 10:14: Discussão sobre o clima de Marte para a Múmia

22 22 CAPÍTULO 4. MONITORANDO ALTERAÇÕES commit 34961b159c27df3b475cfe4415d94a6d1fcd064d Author: Vlad Dracula Date: Thu Aug 22 10:07: Adicionado preocupação sobre o feito das luas de Marte no Lobisomem commit f22b25e3233b4645dabd0d81e651fe074bd8e73b Author: Vlad Dracula <vlad@tran.sylvan.ia> Date: Thu Aug 22 09:51: Começando a tomar notas sobre Marte como um base Para recapitular, quando queremos adicionar mudanças no nosso repositório, primeiro precisamos adicionar os arquivos alterados para a área de transferência (git add) e então commitar as mudanças na área de transferência no repositório (git commit): Comitando alterações no Git Qual comando abaixo irá salvar as alterações de meu-arquivo.txt no meu repositório Git local? 1. $ git commit -m minhas mudanças recentes 2. $ git init meu-arquivo.txt $ git commit -m minhas mudanças recentes 3. $ git add meu-arquivo.txt $ git commit -m minhas mudanças recentes 4. $ git commit -m meu-arquivo.txt minhas mudanças recentes Repositório bio Crie um novo repositório Git no seu computador chamado bio. Escreva uma versão curta da sua bibliografia com três linhas no arquivo me.txt, salva suas mudanças. Depois, modifique uma das linhas e adicione uma quarta linha, mostre a alteração feita e desfaçaa.

23 REPOSITÓRIO BIO 23 Figura 4.2: The Git Commit Workflow

24 24 CAPÍTULO 4. MONITORANDO ALTERAÇÕES

25 Capítulo 5 Explorando o histórico Objetivos Identificar e usar números de revisões do Git. Comparar versões antigas de um arquivo com a atual. Restaurar versões antigas de arquivos. Se desejarmos ver o que alteramos, podemos utilizar git diff novamente, mas referindo-se a versões antigas utilizando a notação HEAD~1, HEAD~2 e assim por diante: $ git diff HEAD~1 marte.txt diff --git a/marte.txt b/mars.txt index 315bf3a..b36abfd a/marte.txt ,2 Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. $ git diff HEAD~2 marte.txt diff --git a/marte.txt b/mars.txt index df0654a..b36abfd a/marte.txt +++ b/marte.txt 25

26 26 CAPÍTULO 5. EXPLORANDO O -1 Frio e seco, mas tudo é da minha cor favorita. +Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. Dessa forma, criamos uma sequência de revisões. A revisão mais recente nessa sequência é referenciada por HEAD e podemos referenciar revisões anteriores utilizando a notação com ~, tal que HEAD~1 (pronuncia-se head minus one ) significa a revisão anterior, enquanto HEAD~123 retorna 123 revisões do ponto em que estamos agora. Podemos também referenciar revisões anteriores utilizando a longa string de dígitos e letras impressas por git log. Essa longa string é única para as revisões e única realmente significa única: todo conjunto de mudanças em um conjunto de arquivos em cada máquina possui um identificador único de 40 caracteres. O nosso primeiro commit possui como identificado f22b25e3233b4645dabd0d81e651fe074bd8e73b. Então vamos tentar: $ git diff f22b25e3233b4645dabd0d81e651fe074bd8e73b marte.txt diff --git a/marte.txt b/mars.txt index df0654a..b36abfd a/marte.txt Frio e seco, mas tudo é da minha cor favorita. +Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. A resposta do Git está correta mas digitar 40 caracteres aleatórios é inconveniente e por isso Git permite você digitar apenas os primeiros caracteres: $ git diff f22b25e marte.txt diff --git a/marte.txt b/mars.txt index df0654a..b36abfd a/marte.txt Frio e seco, mas tudo é da minha cor favorita. +Duas luas pode ser um problema para o Lobisomem. +Mas a Múmia irá apreciar a falta de humidade. Até agora aprendemos como salvar alterações nos arquivos e verificar as alterações realizadas. Como podemos recuperar um arquivo de uma versão antiga? Vamos supor que acidentalmente sobre escrevemos um de nossos arquivos.

27 OBJETIVOS 27 $ nano marte.txt $ cat marte.txt Teremos que produzir oxigênio para nosso consumo. git status irá informar que os arquivo foi alterado e que as alterações não foram salvas na área temporária: $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: marte.txt # no changes added to commit (use "git add" and/or "git commit -a") Podemos desfazer as mudanças utilizando o comando git checkout: We can put things back the way they were by using git checkout: $ git checkout HEAD marte.txt $ cat marte.txt Frio e seco, mas tudo é da minha cor favorita. Duas luas pode ser um problema para o Lobisomem. Mas a Múmia irá apreciar a falta de humidade. Como você pode adivinhar pelo verbo utilizado, git checkout checks out (i.e., restaura) uma versão anterior do arquivo. Nesse caso, estamos dizendo para o Git que queremos recuperar a versão do arquivo presente em HEAD, que corresponde a última versão salva. Se você você resolver resolver voltar para uma versão mais antiga você deve utilizar o identificado da respectiva versão: $ git checkout f22b25e marte.txt É importante lembrar que devemos utilizar o identificador da revisão anterior ao estado que desejamos desfazer. Um erro comum é utilizar o identificador da revisão na qual as alterações indesejadas foram feitas. No exemplo abaixo, queremos recuperar o estado anterior ao commit mais recente (HEAD~1), cuja identificação é f22b25e: O diagrama a seguir ilustra como o histórico de um arquivo deve ser (indo para antes de HEAD, a versão mais recente salva):

28 28 CAPÍTULO 5. EXPLORANDO O HISTÓRICO Figura 5.1: Git Checkout Figura 5.2: When Git Updates Revision Numbers

29 SIMPLIFICANDO O CASO COMUM 29 Simplificando o Caso Comum Se você tiver lido cuidadosamente a saída do comando git status você terá notado que ele encontra a seguinte dica: (use "git checkout -- <file>..." to discard changes in working directory) Como ela diz, git checkout irá restaurar os arquivos para o estado salvo em HEAD. O traço duplo, --, é necessário para separar o nome do arquivo a ser recuperado do comando propriamente dito: sem o traço duplo, Git tentará utilizar o nome do arquivo como o identificador da revisão. O fato de que os arquivos pode ser recuperados um por um tende a mudar a forma como as pessoas organizam seu trabalho. Se todo o trabalho consiste de um grande documento, será difícil (mas não impossível) de desfazer alguma mudança sem também desfazer outras, por exemplo desfazer as alterações na introdução sem também desfazer as alterações feitas na conclusão. Se a introdução e conclusão estiverem salvas em arquivos separados será muito mais fácil desfazer apenas as alterações em um dos arquivos. Recuperando versões antigas de um arquivo Jennifer fez alterações no seu script Python no qual ela estava trabalhando a duas semanas, e as alterações que ela fez essa manhã quebraram o script que não mais funciona. Ela já gastou em ~1h tentando corrigi-lo sem sucesso... Felizmente, ela esteve mantendo registro do seu trabalho utilizando Git! Qual comando a seguir permite ela recuperar a última versão salva do seu script Python chamado reducao-de-dados.py? 1. $ git checkout HEAD 2. $ git checkout HEAD reducao-de-dados.py 3. $ git checkout HEAD~1 reducao-de-dados.py 4. $ git checkout reducao-de-dados.py 5. 2 e 4

30 30 CAPÍTULO 5. EXPLORANDO O HISTÓRICO

31 Capítulo 6 Ignorando Arquivos Objetivos Configurar Git para ignorar arquivos específicos, e explicar porque isso é útil em alguns casos. Se tivermos arquivos que não desejamos serem monitorados pelo Git, por exemplo arquivos de backup criados pelo nosso editor ou arquivos intermediários criados durante a análise de dados. Vamos criar um exemplo bobo: $ mkdir resultados $ touch a.dat b.dat c.dat resultados/a.out resultados/b.out e verificar o que o Git diz: $ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # a.dat # b.dat # c.dat # resultados/ nothing added to commit but untracked files present (use "git add" to track) Colocando esses arquivos sob controle de versão é um desperdício de memória em disco. Algo pior é que ter eles listados toda vez pode reduzir nossa atenção para 31

32 32 CAPÍTULO 6. IGNORANDO ARQUIVOS as mudanças que realmente importam. Vamos então dizer para o Git ignorar alguns arquivos. Fazemos isso criando um arquivo denominado.gitignore no diretório raiz do nosso projeto. $ nano.gitignore $ cat.gitignore *.dat resultados/ A primeira expressão no arquivo.gitignore diz para o Git ignorar todos os arquivos que terminam com.dat e a segunda expressão para ele ignorar todos os arquivos dentro do diretório resultados. (Se algum desses arquivos já está sendo monitorado pelo Git ele continuará sendo-o). Uma vez que criamos esse arquivo, a saída do comando git status é muito mais limpa. $ git status # On branch master # 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) A única alteração que Git nota é a criação do arquivo.gitignore. Inicialmente você pode pensar que você não quer monitorar esse arquivo mas todas as pessoas que fizerem uso do repositório provavelmente irão querer ignorar os mesmos arquivos que ignoramos. Por esse motivo, vamos adicionar o arquivo.gitignore ao nosso controle de versão: $ git add.gitignore $ git commit -m "Adicionado gitignore" $ git status # On branch master nothing to commit, working directory clean Como um bônus, utilizar.gitignore irá ajudar nos a evitar de acidentadamente adicionar arquivos indesejados.

33 OBJETIVOS 33 $ git add a.dat The following paths are ignored by one of your.gitignore files: a.dat Use -f if you really want to add them. fatal: no files added Se realmente desejarmos desobedecer nossas configurações presentes no.gitignore precisamos informar isso ao Git utilizando git add -f. Também podemos verificar o status dos arquivos ignorados utilizando: $ git status --ignored # On branch master # Ignored files: # (use "git add -f <file>..." to include in what will be committed) # # a.dat # b.dat # c.dat # resultados/ nothing to commit, working directory clean

34 34 CAPÍTULO 6. IGNORANDO ARQUIVOS

35 Capítulo 7 Colaborando Objetivos Explicar o que são repositórios remotos e por que eles são úteis. Explicar o que acontece quando um repositório remoto é clonado. Explicar o que acontece quando mudanças são obtidas e enviadas para um repositório remoto. Controle de versão começa a fazer falta quando começamos a colaborar com outras pessoas. Já temos quase todas as ferramentas necessárias para fazer isso, só falta aprendermos como copiar alterações de um repositório para outro. Sistemas como Git permite trocar alterações entre dois repositórios quaisquer. Na prática, entretanto, é mais fácil utilizar uma cópia como hub central e mantêlo em um servidor conectado à internet do que no notebook de alguém. Grande parte dos programadores utilizam serviços de hospedagem como GitHub ou BitBucket para armazenar esses cópias. Vamos explorar os pros e os contras dessa abordagem no final dessa lição. Vamos começar por compartilhar as mudanças que fizemos no nosso projeto com o mundo. Autentique-se no GitHub e clique no ícone no canto superior direito para criar um novo repositório denominado planetas: Nomeie o seu repositório de planetas e selecione Create Repository : Assim que o repositório for criado, GitHub irá mostrar uma página com uma URL e algumas informações de como configurar seu repositório local: Esse procedimento realiza os seguintes comandos nos servidores do GitHub: $ mkdir planetas $ cd planetas $ git init 35

36 36 CAPÍTULO 7. COLABORANDO Figura 7.1: Criando um novo repositório no GitHub (Passo 1) Figura 7.2: Criando um novo repositório no GitHub (Passo 2)

37 HTTPS VS SSH 37 Figura 7.3: Criando um novo repositório no GitHub (Passo 3) Nosso repositório local ainda contem nosso trabalho anterior no arquivo marte.txt mas o repositório remoto no GitHub não contem nenhum arquivo: O próximo passo é conectar esses dois repositórios. Fazemos isso transformando o repositório no GitHub um repositório remote para o repositório local. Na página inicial do repositório no GitHub encontra-se a string necessária para identificá-lo: Selecione HTTPS para alterar o protocolo SSH para HTTPS. HTTPS vs SSH Utilizamos HTTPS porque ele não requer configurações adicionais. Depois do workshop você pode querer configurar acesso via SSH, que é um pouco seguro, seguindo um dos tutoriais disponibilizados por GitHub, Atlassian/BitBucket e GitLab (esse é um vídeo). Copie essa URL do navegador, vá para seu repositório local e execute o comando: $ git remote add origin Certifique-se de utilizar a URL do seu repositório ao invés da URL do Vlad: a única diferença deve ser seu nome de usuário no lugar de vlad. Você pode verificar que o comando anterior foi executado corretamente utilizando git remote -v:

38 38 CAPÍTULO 7. COLABORANDO Figura 7.4: Freshly-Made GitHub Repository Figura 7.5: Where to Find Repository URL on GitHub

39 PROXY 39 Figura 7.6: Changing the Repository URL on GitHub $ git remote -v origin origin (push) (fetch) O nome origin é o apelido local para seu repositório remoto: você pode utilizar outro apelido no lugar se você desejar, mas origin é a opção mais utilizada. Uma vez que o apelido origin está configurado, o comando a seguir irá copiar as alterações no repositório local para o repositório no GitHub: $ git push origin master Counting objects: 9, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (9/9), 821 bytes, done. Total 9 (delta 2), reused 0 (delta 0) To * [new branch] master -> master Branch master set up to track remote branch master from origin. Proxy Se a rede que você está conectado utiliza um proxy existe uma change do último comando ter falhado com Could not resolve hostname