diff --git a/cap01.md b/cap01.md
deleted file mode 100644
index c9cf86e7716365643d277fb6260129819d8f71e8..0000000000000000000000000000000000000000
--- a/cap01.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Tutorial de Git
-PET Estatística UFPR
-
-
-
-Sistemas de controle de versão
-
-Inicialmente, podemos dizer que Git é um Sistema de Controle de Versão,
-que permite ao programador armazenar diversas cópias de versão do seu
-trabalho, restaurar versões anteriores, sincronizar entre diversos
-computadores de trabalho e trabalhar colaborativamente com outros
-programadores. Só com essas possibilidades já faz do Git uma ferramenta
-muito útil a quem programa. Mas o Git é muito mais! É possível utilizar
-o Git através do Shell (linha de comando) ou através de diversas
-interfaces gráficas e até mesmo dentro do Rstudio. Você pode integrar
-seu projeto com o Github ou Gitlab e disponibilizar os arquivos na web.
-Assim, você pode acessá-los e até editar seus arquivos via navegador.
-Pode deixar os arquivos públicos e disponibilizar seu código à
-comunidade de programadores. Outras pessoas podem até vir a colaborar
-nos seus projetos. Neste conceito, você pode fazer uso ou colaborar com
-projetos de outros programadores! Acompanhar o desenvolvimento de
-projetos que sequer foram lançados, fazer sugestões, tirar dúvidas e
-entrar em contato direto com equipes e desenvolvedores. Isso transforma
-o Github e Gitlab numa rede social de programadores!
-
-O Git não é o único sistema de controle de versão. Nem foi o primeiro.
-Os primeiros sistemas de controle de versão foram lançados na década
-de 70. Há sistemas abertos e proprietários. E também, sistemas que
-trabalham somente de forma local, cliente-servidor ou sistema
-distribuído. Dentre os sistemas abertos, os mais conhecidos são o
-Apache Subversion (SVN), Mercurial, Git, Veracity e Bazzar. Mas, porque
-tantos sistemas foram desenvolvidos? Cada sistema foi desenvolvido
-buscando resolver os mesmos problemas de diferentes formas. A comunidade
-desenvolvedora do kernel (núcleo) do Linux utilizava o BitKeeper, um
-software proprietário que decidiu revogar a licença gratuita. Linus
-Torvalds, desenvolvedor do primeiro kernel, estudou os diversos
-softwares de controle de versão para ser o substituto do BitKeeper.
-Mas nenhum software atendia as necessidades, principalmente na
-performance de um projeto tão grande. Então, ele iniciou o
-desenvolvimento do software que ele chamou de Git e em menos de dois
-meses todo o gerenciamento do kernel já estava transferido para o
-novo sistema.
-
-Então, utilizar o Git é a garantia de um sistema robusto de controle de
-versionamento. Um sistema aberto e muito utilizado por programadores,
-estatísticos e cientistas de dados.
-
-Seja você mais um desenvolvedor a resolver os seus problemas e
-participar desta comunidade.
diff --git a/cap02.md b/cap02.md
deleted file mode 100644
index dd9c69341c6caf05b149480a6c889ad4c511ff70..0000000000000000000000000000000000000000
--- a/cap02.md
+++ /dev/null
@@ -1,336 +0,0 @@
-# Capítulo 2: Instalação e Configuração
-Jhenifer
-29/10/2015
-
-
-
-## Instalação
-
-#### Windows
-Usuários Windows devem visitar [Git for Windows](https://git-for-windows.github.io/ "Git"), clicar em "Download" e baixar o arquivo ".exe".
-
-Após o download, execute o arquivo e você terá essa tela:
-
-
-
-
-
-Como de costume, clique em "Next". Para dar continuidade a instalação
-aceite a licença do Git.
-
-O diretório apresentado na figura abaixo vem como default, porém é
-possível alterar a instalação para um diretório de sua preferência.
-Depois de selecionado o caminho da instalação, clique em "Next" para
-prosseguir.
-
-
-
-
-
-Na tela de componentes podemos definir atalhos, integração ao menu de
-contexto do Windows Explorer, associação de arquivos e uso de font
-TrueType.
-
-O Git Bash é o prompt de comandos próprio, que além dos comandos Git
-também fornece alguns comandos Unix que podem ser bem úteis. Já o Git
-GUI é uma interface gráfica para trabalhar com Git. É recomendável a
-seleção de ambos os itens.
-
-Depois de selecionado os componentes de sua
-preferência, clique em “Next” para dar continuidade.
-
-
-
-
-
-Aqui, o instalador nos oferece a oportunidade de mudar o nome da pasta
-no menu iniciar, recomenda-se deixar o padrão para fácil localização
-posteriormente.
-
-
-
-
-
-Na tela de configuração "PATH environment", podemos escolher as formas
-de integração do Git com o sistema.
-A primeira opção nos permite usar o Git apenas pelo "Git Bash" (é o
-prompt de comando do Git), a segunda opção nos possibilita executar os
-comandos no "Git Bash" e no prompt de comando do Windows (cmd.exe), e a
-terceira opção é a junção das duas de cima, porém alguns comandos do
-Windows serão substituídos por comandos Unix com mesmo nome.
-Essa última opção não é recomendada, e a primeira opção é a
-desejável.
-
-
-
-
-
-Abaixo, a configuração de quebra de linha. Windows e sistemas Unix
-(Linux, Mac) possuem formatos diferentes de quebra de linha em arquivos
-de texto. Se você escreve um código com quebras de linha no formato
-Windows, outra pessoa pode ter problemas ao abrir o mesmo arquivo em
-um Linux, e vice-versa. Esta opção, portanto, permite normalizar isso.
-A primeira opção converte automaticamente os arquivos para padrão Windows
-quando receber algum arquivo e converterá para padrão Unix quando
-“comitar” (enviar alterações) ao repositório. A segunda opção,
-não faz nenhuma conversão ao receber arquivos, mas convertem
-para padrão Unix ao “comitar”.
-Já a terceira opção, o Git não fará nenhuma conversão.
-Recomenda-se a seleção da opção "Checkout Windows-style,
-commit Unix-Style line endings".
-
-
-
-
-
-Aqui, a configuração do emulador de terminal para usar com o Git Bash.
-A primeira opção utiliza o terminal MSys2 (Shell), que permite utilizar
-comandos Unix no Windows. Já a segunda opção, utiliza o terminal
-padrão do Windows. Recomendamos a primeira opção.
-Feito isso, dê continuidade a instalação.
-
-
-
-
-E por último, configurando ajustes de performance. Essa opção é para
-habilitar o sistema de cache de arquivo.
-
-
-
-
-Feito isso, “Next”, “Finish” e o Git está instalado.
-
-
-#### Linux
-
-Em qualquer sistema Linux, pode-se utilizar o gerenciador de pacotes da respectiva distribuição para instalar o Git.
-Basta executar o código de instalação de sua respectiva distribuição.
-
-
-**Debian**
-
-Em uma sessão de terminal Linux de distribuições Debian (Ubuntu, Mint),
-execute o código abaixo.
-Adicione o ppa para obter a versão mais recente do Git.
-
-```sh
-sudo add-apt-repository ppa:git-core/ppa
-sudo apt-get update
-```
-
-Agora, execute o comando abaixo para instalação do Git.
-Siga as instruções do prompt de comando, primeiro confirmando a instalação
-dos pacotes e suas dependências, depois confirmando a instalação
-do pacote git-core.
-
-```sh
-sudo apt-get install git git-core git-man git-gui git-doc \
- ssh openssh-server openssh-client
-git --version
-```
-
-Para adicionar ferramentas complementares, execute:
-
-```sh
-sudo apt-get install gitk meld
-```
-
-
-**Arch**
-
-
-```sh
-pacman -S git openssh meld
-git --version
-```
-
-
-**Fedora**
-
-
-```sh
-Yum install git
-git --version
-```
-
-Usuários de outra versão do Linux podem visitar [Download for Linux](https://git-scm.com/download/linux).
-
-
-#### MacOS
-Exitem duas maneiras de instalar o Git no Mac, uma pelo instalador e
-outra através do MacPorts.
-
-**Utiizando o Instalador**
-
-O usuário deverá acessar [Download for Mac](http://git-scm.com/downloads),
-clicar em "Download" e baixar o arquivo ".dmg".
-
-Após o download, é necessário clicar duas vezes para ter acesso ao pacote
-de instalação. Dentro do arquivo ".dmg", execute o arquivo ".pkg" para
-iniciar a instalação.
-Siga os passos até concluir a instalação. É recomendável utilizar a
-instalação padrão.
-
-Para testar a instalação, abra o terminal e digite o comando “git”.
-A saída deverá ser similar à imagem:
-
-
-
-**Utiizando o MacPorts**
-
-A maneira mais fácil de instalar Git no Mac é via
-[MacPorts](http://www.macports.org), para isso basta executar o seguinte
-comando:
-
-
-```sh
-sudo port install git-core
-```
-
-
-## Configurando Perfil
-As configurações vão determinar algumas opções globais do Git, sendo
-necessário fazê-las apenas uma vez.
-
-**Usuário**
-
-Os comandos abaixo vão configurar o nome de usuário e endereço de e-mail.
-Esta informação é importante pois é anexada aos commits que você realiza,
-ou seja, as configurações ficarão associadas ao trabalho em desenvolvimento,
-permitindo que os colaboradores/gestores do projeto identifiquem suas
-contribuições.
-
-Caso o projeto seja individual, a importância de configurar usuário e
-e-mail se mantém. Uma vez que se trabalha com duas ou mais máquinas,
-a maneira de identificar a pessoa que está desenvolvendo o trabalho é
-pelo nome de usuário.
-
-Em um terminal Bash, execute o código abaixo:
-
-```sh
-git config --global user.name "Knight Rider"
-git config --global user.email "batman@justiceleague.org"
-```
-
-A opção `--global` usará essa informação para todo projeto Git da máquina.
-É possível fazer definições para cada projeto, ou seja, não globais.
-Para isso é necessário executar o comando a seguir sem a opção `--global`.
-
-
-```sh
-git config user.name "Knight Rider"
-git config user.email "batman@justiceleague.org"
-```
-
-Uma vez configurado o perfil, o Git está pronto para uso.
-
-
-**Atalhos**
-
-Os atalhos no Git são chamados de *Alias*. Com ele podemos mapear comandos
-que repetidamente usamos para algumas poucas teclas. Estes atalhos podem
-ser criados de dois modos: através do comando no terminal ou editando
-diretamente no arquivo `/.gitconfig`.
-
-* Pelo terminal:
-
-Execute o comando abaixo com o atalho de sua preferência e o nome completo
-do camando o qual deseja criar o alias.
-
-
-```sh
-git config --global alias.nome_do_alias "comando inteiro"
-```
-
-Um exemplo bem simples é o seguinte:
-
-
-```sh
-git config --global alias.st "status"
-```
-
-Assim, ao executar git st é o mesmo que executar git status.
-
-Pelo método citado acima, o alias é adicionado automaticamente no seu arquivo `/.gitconfig`.
-
-* Pelo arquivo `/.gitconfig`:
-
-Pode-se criar atalhos através de um bloco no seu arquivo de configuração.
-Para isso, é necessário localizar o diretório do Git e adicionar a lista
-de comandos desejada, como no exemplo:
-
-
-```sh
-[alias]
- st = status
- ci = commit
- br = branch
- co = checkout
- df = diff
-```
-
-Assim que adicionar este bloco com os comandos de sua escolha, ele irá
-funcionar imediatamente.
-
-Segue abaixo os caminhos para encontrar o arquivo `/.gitconfig` nos sistemas operacionais:
-
-+ Windows:
-1 - C:\\Pasta_do_seu_projeto\\.git\\config
-2 – C:\\Documents and Settings\\Seu_usuario\\.gitconfig
-3 – C:\\Arquivos de programas\\Git\\etc\\gitconfig
-
-+ Mac:
-1 - /Pasta_do_seu_projeto/.git/config
-2 – /Users/Seu_usuario/.gitconfig
-3 – /usr/local/git/etc/gitconfig
-Obs: Os arquivos de configuração do Git não tem extensão.
-
-+ Linux:
-Crie um arquivo como _sudo_ dentro da pasta etc/ com nome de gitconfig e
-coloque os atalhos de sua escolha.
-
-Não importa o método você utilize, suas configurações sempre ficarão
-salvas no arquivo `/.gitconfig`.
-
-**Ignorar Arquivos**
-
-Usando o arquivo `.gitignore` podemos ignorar arquivos que não desejamos
-versionar no repositório, pode ser feito por projeto e por usuário.
-Configurar um arquivo `.gitignore` antes de começar a trabalhar,
-é importante, pois evita commits acidentais de arquivos que não deveriam
-ir para o seu repositório Git.
-
-* Ignorar Arquivos por Projeto:
-
-Em todos os projetos que necessitam de um controle de versão há sempre
-casos em que arquivos não precisam ser versionados. Para isso é preciso
-criar um arquivo `.gitignore` no diretório raiz do projeto, o qual contém
-padrões (pattern) que serão ignorados, cada padrão fica em uma linha
-como no exemplo:
-
-
-```sh
-$ cat .gitignore
-*.[oa]
-*~
-```
-
-A primeira linha fala para o Git ignorar qualquer arquivo finalizado
-em **.o** ou **.a** e a segunda linha ignora todos os arquivos que
-terminam com um til **(~)**. Esses padrões podem serem feitos de acordo
-com a necessidade de cada projeto.
-
-* Ignorar Arquivos por Usuário (Globalmente):
-
-Para não precisar criar uma lista de comandos para serem ignorados em cada
-projeto, é possível ignorar arquivos em todos os repositórios. Para isso,
-basta criar um arquivo `.gitignore` em seu diretório _home_ contendo os
-padrões os quais deseja ignorar e executar o comando abaixo no terminal
-a partir da pasta onde está localizado o arquivo `.gitignore`:
-
-
-```sh
-git config --global core.excludesfile ~/.gitignore
-```
-
-A partir disso, todos os arquivos que estão na lista serão ignorados pelo usuário.
diff --git a/cap03.md b/cap03.md
deleted file mode 100644
index 68c2dbcbaff505ae4d055140f031d7db1ad4992c..0000000000000000000000000000000000000000
--- a/cap03.md
+++ /dev/null
@@ -1,1724 +0,0 @@
-# Repositório Local
-Gabriel Sartori
-29/10/2015
-
-
-### Instruções do Git
-
-Neste capítulo, as instruções serão todas feitas no terminal mesmo que
-existam alternativas gráficas para as mesmas. Isso enfatiza no que está
-sendo feito além do fato de que no terminal todos devem ter os mesmos
-recursos e os comandos irão produzir os mesmos resultados, o que faz
-esse tutorial algo reproduzível. Para usufruir das ferramentas gráfica va até o capitulo 6 **link*.
-
-
-Já temos o Git devidamente e com credenciais (nome e email) e
-configurações aplicadas. Vamos então ver como o sistema de controle de
-versão acontece.
-
-Todas as instruções do Git são sinalizadas por começar com `git` seguido
-da instrução/comando e seus argumentos complementares, se
-existirem/necessários.
-
-
-
-
-```sh
-cd meu1repo ## Diretório de teste de comandos
-```
-
-Antes de iniciarmos o repositório, vamos só verificar o cadastro. Se
-você já usa o Git ou fez os procedimento apresentados na primeira
-sessão, o comando abaixo vai retornar o nome e email usados e alguns
-definições adicionais, caso existam. Em caso de ainda não ter
-configurado o seu Git, informe o nome e email conforme apresentado na
-sessão anterior.
-
-
-
-```sh
-## Mostra as informações/definições do usuário.
-git config --list
-```
-
-```sh
-user.name=Knight Rider
-user.email=batman@justiceleague.org
-```
-
-Temos um diretório destinado ao projeto que será mantido sobre
-versionamento, então vamos iniciar um repositório Git nele.
-
-
-```bash
-## Inicia um repositório sob versionamento Git.
-git init
-```
-
-```
-
-O Git retorna a mensagem de inicilização do repositório. Nesse momento
-ele cria um diretório oculto `.git/` com subdiretórios que são o coração
-do sistema de versionamento. Você não deve modificar nada nesse
-diretório. É por essa razão que ele é oculto. Alterar o conteúdo pode
-prejudicar ou interromper o funcionamento do Git. Se você quiser
-encerrar o processo de versionamento fazendo com que esse diretório seja
-como qualquer outro diretório, é só excluir a diretório `.git/`. Cada
-subdiretório do `.git/` tem um propósito mas deixaremos os
-esclarecimentos para o futuro. Por agora vamos apenas conferir a sua
-estrutura.
-
-
-```bash
-## Mostra todo conteúdo do diretório.
-tree -a
-```
-
-```
-## .
-## └── .git
-## ├── branches
-## ├── config
-## ├── description
-## ├── HEAD
-## ├── hooks
-## │ ├── applypatch-msg.sample
-## │ ├── commit-msg.sample
-## │ ├── post-update.sample
-## │ ├── pre-applypatch.sample
-## │ ├── pre-commit.sample
-## │ ├── prepare-commit-msg.sample
-## │ ├── pre-push.sample
-## │ ├── pre-rebase.sample
-## │ └── update.sample
-## ├── info
-## │ └── exclude
-## ├── objects
-## │ ├── info
-## │ └── pack
-## └── refs
-## ├── heads
-## └── tags
-##
-## 10 directories, 13 files
-```
-
-**NOTA**: o `tree` é um programa instalado a parte (*third party
-software*) que retorna arte ASCII representado a estrutura de
-diretórios. Se você usa distribuição Debian, instale com `sudo apt-get
-install tree`. Windows: [tree][].
-
-## Minha Primeira Sessão
-
-Vamos começar da maneira mais simples, criando um arquivo com uma linha
-de texto apenas. Bem, vale avisar que ao longo desse tutorial, os
-arquivos serão sempre bem pequenos e dificilmente realistas, mas como o
-enfoque está no funcionamento, não haverá prejuízo.
-
-Vamos criar o arquivo com conteúdo também pelo terminal. Se você
-preferir, abra um editor de texto favorito (Emacs, Gedit, Geany,
-RStudio, Bloco de Notas, etc) e faça algo mais elaborado.
-
-
-## Comandos De Verificação
-git diff
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-```
-
-Vamos aplicar o primeiro *add* ao `porqueLinux.txt` para que ele começe
-a ser versionado. Perceba que ao adicioná-lo, as mudanças, no caso a
-criação do arquivo com contúdo, já são separadas para receber registro
-(*changes to be commited*).
-
-
-```bash
-## Adiciona o arquivo ao processo de reastreamento.
-git add porqueLinux.txt
-git status
-ref log
-
-```
-## On branch master
-## Changes to be committed:
-## (use "git reset HEAD <file>..." to unstage)
-##
-## new file: porqueLinux.txt
-##
-## 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: README.txt
-```
-
-
-```bash
-## Mensagem que registra as modificações adicionadas.
-git commit -m "Lista de inicial de o porquê usar o Linux."
-```
-
-```
-## [master 448b201] Lista de inicial de o porquê usar o Linux.
-## 1 file changed, 5 insertions(+)
-## create mode 100644 porqueLinux.txt
-```
-
-
-```bash
-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: README.txt
-##
-## no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-Ainda resta o `REAMDE.txt` para receber registro. Você não precisa fazer
-agora. Pode continuar editanto caso não tenha atingido uma quantidade de
-modificação merecedora de *commit*. Lembre-se que registros geram
-conteúdo no diretório `.git`. Quanto mais *commits*, mais conteúdo
-gerado. Mas também, toda vez que você faz um *commit*, você define um
-ponto de retorno, um estado salvo, caso precise no futuro
-recuperar/visitar. O que é uma unidade de modificação comitável você irá
-definir aos poucos com a prática.
-
-
-```bash
-## Encaminha o arquivo para receber registro.
-git add README.txt
-git status
-```
-
-```
-## On branch master
-## Changes to be committed:
-## (use "git reset HEAD <file>..." to unstage)
-##
-## modified: README.txt
-```
-
-
-```bash
-## Atribui mensagem de notificação.
-git commit -m "Adiciona frase do Linux Torvalds."
-```
-
-```
-## [master 41a3225] Adiciona frase do Linux Torvalds.
-## 1 file changed, 4 insertions(+)
-```
-
-Agora temos 3 *commits* e o *log* apresenta os *sha1* e as mensagens
-correspondentes aos mesmos. Com `--oneline` resumimos o *output* mostrando
-apenas o *sha1* e a mensagem de *commit*.
-
-
-```bash
-git log --oneline
-```
-
-```
-## 41a3225 Adiciona frase do Linux Torvalds.
-## 448b201 Lista de inicial de o porquê usar o Linux.
-## ffc1d12 Cria arquivo com título.
-```
-
-Por meio dos *sha1*, podemos aplicar o *diff* para visitarmos as
-modificações entre dois *commits*, não necessariamente consecutivos, por
-exemplo. Também podemos retroceder (*checkout*, *reset*, *revert*) o
-projeto para alguns desses pontos.
-
-Abaixo instruímos o Git mostrar as diferenças para um *commit* atrás. A
-cabeça (*HEAD*) é o que se entende como estado mais recente. Usa-se o
-termo *HEAD* (cabeça) pois considera-se um crescimento do histórico
-debaixo para cima no qual um novo *commit* é colocado em cima dos demais
-(empilhado). O `HEAD@{0}` ou apenas `HEAD` representa o último registro
-feito. Não é necessário escrever o último `HEAD` na intrução abaixo.
-
-
-```bash
-git diff HEAD@{1}
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-```
-
-Agora inspecionado uma distância de 2 *commits* a partir do último. Aqui
-tem-se os dois arquivos envolvidos nesse intervalo de 2 *commits*. Com
-`--name-only` retorna-se só o nome dos arquivos.
-
-
-```bash
-git diff HEAD@{2} HEAD@{0}
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-## diff --git a/porqueLinux.txt b/porqueLinux.txt
-## new file mode 100644
-## index 0000000..8ecdfda
-## --- /dev/null
-## +++ b/porqueLinux.txt
-## @@ -0,0 +1,5 @@
-## +Por que usar o Linux?
-## +
-## +* É livre
-## +* É seguro
-## +* É customizavel
-```
-
-
-```bash
-git diff --name-only HEAD@{2} HEAD@{0}
-```
-
-```
-## README.txt
-## porqueLinux.txt
-```
-
-Vamos resolver logo o caso da palavra sem acento em
-`porqueLinux.txt`. Você abre o arquivo no seu editor de texto e modifica
-conforme necessário. A modificação compreende um linha apenas mas aí
-lembrei de mais coisas e acrescentei. O `git diff` mostra as
-diferenças. Epa! As diferenças não eram entre *commits*? O conteúdo
-adicionado ainda não recebeu notificação!
-
-
-
-
-```bash
-## Depois de corrigir palavras e adicionar conteúdo.
-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: porqueLinux.txt
-##
-## no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-O Git sugere você aplicar *add* para preparar para *commit*. Caso as
-modificações sejam um engano e não mais desejadas, você pode
-desfazazê-las, abadonar a correção/inclusão das palavras usando
-`checkout`. Vamos aplicá-lo para ver como funciona.
-
-
-```bash
-## Palavras corrigidas e mais itens adicionados.
-less porqueLinux.txt
-```
-
-```
-## Por que usar o Linux?
-##
-## * É livre
-## * É seguro
-## * É customizável
-## * Tem repositórios de software
-## * Atualização constante
-## * Desempenho
-```
-
-
-```bash
-## Abandona modificações feitas presentes no arquivo.
-git checkout -- porqueLinux.txt
-```
-
-
-```bash
-less porqueLinux.txt
-```
-
-```
-## Por que usar o Linux?
-##
-## * É livre
-## * É seguro
-## * É customizavel
-```
-
-Bateu o arrependimento? Tem formas de poder retroceder com mudanças
-ainda não registradas mas mantendo a possibilidade de
-recuperá-las. Mostraremos em breve.
-
-**NOTA**: sempre que quiser testar um comando novo e não está seguro do
-que ele faz ou da extensão dos seus efeitos, faça uma cópia do projeto
-em outro diretório e experimente ele lá. Isso previne sabores amargos,
-pois algumas ações podem ser irreversíveis.
-
-
-```bash
-## Depois de desfazer as modificações no porqueLinux.txt
-git status
-```
-
-```
-## On branch master
-## nothing to commit, working directory clean
-```
-
-Vamos seguir com as modificações em `porqueLinux.txt` que corrigem o
-texto e acrescentam itens novos.
-
-
-
-
-```bash
-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: porqueLinux.txt
-##
-## no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-O `diff` vazio compara o diretório de trabalho com o último registro
-(último *commit*). Quando você usa explicitamente na instrução `HEAD@{ }`
-seguido de número, então estão sendo comparadas versões
-"commitadas". Existem variantes de sufixo para usar no `HEAD` que são:
-
- * `HEAD@{n}`
- * `HEAD^n`
- * `HEAD~n`
-
-em que `n` é um número inteiro não negativo. Cada sulfixo tem uma
-finalidade que não detalharemos agora. Visite: [git-caret-and-tilde][].
-
-
-```bash
-## Modificações no diretório vs último commit.
-git diff
-```
-
-```
-## diff --git a/porqueLinux.txt b/porqueLinux.txt
-## index 8ecdfda..8747d1e 100644
-## --- a/porqueLinux.txt
-## +++ b/porqueLinux.txt
-## @@ -2,4 +2,7 @@ Por que usar o Linux?
-##
-## * É livre
-## * É seguro
-## -* É customizavel
-## +* É customizável
-## +* Tem repositórios de software
-## +* Atualização constante
-## +* Desempenho
-```
-
-
-```bash
-## Último commit vs dois ancestrais, usando ~.
-git diff HEAD~1 HEAD~0
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-```
-
-
-```bash
-## Último commit vs seu ancestral, usando @{}.
-git diff HEAD@{1} HEAD@{0}
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-```
-
-
-```bash
-## Último commit vs dois ancestrais.
-## git diff HEAD~2 HEAD~0
-git diff HEAD@{2} HEAD@{0}
-```
-
-```
-## diff --git a/README.txt b/README.txt
-## index 07d3585..d0af1d3 100644
-## --- a/README.txt
-## +++ b/README.txt
-## @@ -1 +1,5 @@
-## Meu primeiro repositório Git
-## +
-## +A filosofia do Linux é 'Ria na face do perigo'.
-## +Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## + -- Lunus Torvalds
-## diff --git a/porqueLinux.txt b/porqueLinux.txt
-## new file mode 100644
-## index 0000000..8ecdfda
-## --- /dev/null
-## +++ b/porqueLinux.txt
-## @@ -0,0 +1,5 @@
-## +Por que usar o Linux?
-## +
-## +* É livre
-## +* É seguro
-## +* É customizavel
-```
-
-Para ficar claro daqui em diante, você pode ao invés de pedir `log`,
-pedir o `reflog` que incluí as referências em termos da sequência do
-mais rencente para os seus ancestrais.
-
-
-```bash
-## Mostra referências para commits os ancentrais.
-git reflog
-```
-
-```
-## 41a3225 HEAD@{0}: commit: Adiciona frase do Linux Torvalds.
-## 448b201 HEAD@{1}: commit: Lista de inicial de o porquê usar o Linux.
-## ffc1d12 HEAD@{2}: commit (initial): Cria arquivo com título.
-```
-
-
-```bash
-## Adiciona e commita.
-git add porqueLinux.txt
-git commit -m "Novos argumentos."
-```
-
-```
-## [master a2c3f0d] Novos argumentos.
-## 1 file changed, 4 insertions(+), 1 deletion(-)
-```
-
-O Git permite um nível de rastreabilidade bem fino. Veja por exemplo que
-é possível saber quem modificou e quando cada linha do arquivo e qual o
-correspondente *sha1* do *commit*.
-
-
-```bash
-## Mostra quem, onde e o que fez em cada arquivo.
-git blame README.txt
-```
-
-```
-## ^ffc1d12 (gabriel sartori 2015-11-24 14:31:29 -0200 1) Meu primeiro repositório Git
-## 41a32255 (gabriel sartori 2015-11-24 14:31:30 -0200 2)
-## 41a32255 (gabriel sartori 2015-11-24 14:31:30 -0200 3) A filosofia do Linux é 'Ria na face do perigo'.
-## 41a32255 (gabriel sartori 2015-11-24 14:31:30 -0200 4) Ôpa. Errado. 'Faça você mesmo'. É, é essa.
-## 41a32255 (gabriel sartori 2015-11-24 14:31:30 -0200 5) -- Lunus Torvalds
-```
-
-
-## Fazendo cópias e trabalhando com ramos
-
-Existem várias formas de se trabalham com ramos. Geralmente os ramos são
-feitos sob demandas para adicionar uma característica ao projeto
-(*feature*) ou corrigir um *bug*. Alguns ramos, por outro lado, são
-ramos fixos destinados a receber o desenvolvimento dos ramos de
-demanda. Esses ramos são geralmente chamados de *devel* (*development*)
-e *release*. O ramo *master* é o default e em geral, para projetos
-grandes, o *master* só recebe versões funcionais do projeito, livre de
-bugs.
-
-Para criar um ramo, usandos `git branch` seguido do nome que se
-deseja. Vamos criar um ramo para adicionar mais arquivos ou modificações
-ao projeto.
-
-
-```bash
-## Lista ramos (all), locais e remotos.
-## git branch ## Só ramos locais
-## git branch -r ## Só ramos remotos
-git branch -a ## Todos os ramos.
-```
-
-```
-## * master
-```
-
-
-```bash
-## Cria um ramo para adição de conteúdo, novo segmento.
-git branch feature01
-```
-
-
-```bash
-## Novo ramo criado aparece.
-git branch
-```
-
-```
-## feature01
-## * master
-```
-
-
-```bash
-## Muda o HEAD de ramo.
-git checkout feature01
-```
-
-```
-## Switched to branch 'feature01'
-```
-
-
-```bash
-## Situação no novo ramo.
-git status
-```
-
-```
-## On branch feature01
-## nothing to commit, working directory clean
-```
-
-
-```bash
-## Histórico de commits.
-git log --oneline
-```
-
-```
-## a2c3f0d Novos argumentos.
-## 41a3225 Adiciona frase do Linux Torvalds.
-## 448b201 Lista de inicial de o porquê usar o Linux.
-## ffc1d12 Cria arquivo com título.
-```
-
-Veja que o novo ramo não começa no zero ou vazio (sem arquivos) e sim a
-partir do ramo que é seu ancestral, ou seja, ele começa a partir do
-último *commit* existente, por padrão. Vamos adicionar um arquivo e
-commitar. O comando `wget` permite baixar arquivos pelo terminal. Será
-baixado um arquivo com um função para calcular o fator de inflação de
-variância (*vif*, variance inflation factor) usado em modelos de
-regressão, disponível na página da [Professora Suely Giolo][].
-
-
-
-
-```bash
-## Baixando arquivo da internet. Uma função do R.
-wget 'http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R'
-```
-
-
-```
-## --2015-11-24 14:31:30-- http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R
-## Resolving people.ufpr.br (people.ufpr.br)... ???.??.???.??, 2801:82:8020:0:8377:0:100:20
-## Connecting to people.ufpr.br (people.ufpr.br)|???.??.???.??|:80... connected.
-## HTTP request sent, awaiting response... 200 OK
-## Length: 560
-## Saving to: ‘vif.R’
-##
-## 0K 100% 44,0M=0s
-##
-## 2015-11-24 14:31:30 (44,0 MB/s) - ‘vif.R’ saved [560/560]
-```
-
-
-```bash
-## Situação do repositório após o download.
-git status
-```
-
-```
-## On branch feature01
-## Untracked files:
-## (use "git add <file>..." to include in what will be committed)
-##
-## vif.R
-##
-## nothing added to commit but untracked files present (use "git add" to track)
-```
-
-
-```bash
-git add vif.R
-git commit -m "Adiciona função R para VIF."
-```
-
-```
-## [feature01 ed304f7] Adiciona função R para VIF.
-## 1 file changed, 20 insertions(+)
-## create mode 100644 vif.R
-```
-
-
-```bash
-## Estrutura do diretório.
-tree
-```
-
-```
-## .
-## ├── porqueLinux.txt
-## ├── README.txt
-## └── vif.R
-##
-## 0 directories, 3 files
-```
-
-
-```bash
-## Histórico de commits.
-git reflog
-```
-
-```
-## ed304f7 HEAD@{0}: commit: Adiciona função R para VIF.
-## a2c3f0d HEAD@{1}: checkout: moving from master to feature01
-## a2c3f0d HEAD@{2}: commit: Novos argumentos.
-## 41a3225 HEAD@{3}: commit: Adiciona frase do Linux Torvalds.
-## 448b201 HEAD@{4}: commit: Lista de inicial de o porquê usar o Linux.
-## ffc1d12 HEAD@{5}: commit (initial): Cria arquivo com título.
-```
-
-
-```bash
-git status
-```
-
-```
-## On branch feature01
-## nothing to commit, working directory clean
-```
-
-Então acabamos de acrescentar um novo aquivo ao projeto. Agora que as
-modificações foram salvas (*commit* feito) podemos trocar de ramo. Você
-vai ver que ao voltarmos para o ramo *master* o arquivo baixado da
-internet vai "desaparecer".
-
-
-```bash
-## Volta para o ramo master.
-git checkout master
-```
-
-```
-## Switched to branch 'master'
-```
-
-
-```bash
-## Estrutura do diretório.
-tree
-```
-
-```
-## .
-## ├── porqueLinux.txt
-## └── README.txt
-##
-## 0 directories, 2 files
-```
-
-O arquivo `vif.R` não sumiu. Ele está no ramo `feature01` e só passará
-para o ramo master quando mesclarmos o que existe no `feature01` ao
-`master`. Então é assim: mudou de ramo, muda o conteúdo do
-diretório. Fazer isso é bem simples, basta dar um `git merge`. Antes
-vamos aprender como saber as diferenças que existem entre ramos.
-
-
-```bash
-## Mostra todas as modificações, cada linha modificada de cada arquivo.
-git diff master feature01
-```
-
-```
-## diff --git a/vif.R b/vif.R
-## new file mode 100644
-## index 0000000..a114969
-## --- /dev/null
-## +++ b/vif.R
-## @@ -0,0 +1,20 @@
-## +vif<-function (obj, digits = 5) {
-## + Qr <- obj$qr
-## + if (is.null(obj$terms) || is.null(Qr))
-## + stop("invalid 'lm' object: no terms or qr component")
-## + tt <- terms(obj)
-## + hasintercept <- attr(tt, "intercept") > 0
-## + p <- Qr$rank
-## + if (hasintercept)
-## + p1 <- 2:p
-## + else p1 <- 1:p
-## + R <- Qr$qr[p1, p1, drop = FALSE]
-## + if (length(p1) > 1)
-## + R[row(R) > col(R)] <- 0
-## + Rinv <- qr.solve(R)
-## + vv <- apply(Rinv, 1, function(x) sum(x^2))
-## + ss <- apply(R, 2, function(x) sum(x^2))
-## + vif <- ss * vv
-## + signif(vif, digits)
-## + }
-## +
-```
-
-
-```bash
-## Mostra só os arquivos modificados.
-git diff --name-only master feature01
-```
-
-```
-## vif.R
-```
-
-Como você já havia antecipado, a única diferença entre os ramos `master`
-e `feature01` é o arquivo `vif.R`. Agora é só pedir o `git merge`.
-
-
-```bash
-## Mesclando as modificações em feature01 no master.
-git merge feature01 master
-```
-
-```
-## Updating a2c3f0d..ed304f7
-## Fast-forward
-## vif.R | 20 ++++++++++++++++++++
-## 1 file changed, 20 insertions(+)
-## create mode 100644 vif.R
-```
-
-
-```bash
-git log --oneline
-```
-
-```
-## ed304f7 Adiciona função R para VIF.
-## a2c3f0d Novos argumentos.
-## 41a3225 Adiciona frase do Linux Torvalds.
-## 448b201 Lista de inicial de o porquê usar o Linux.
-## ffc1d12 Cria arquivo com título.
-```
-
-É possível criar um ramo a partir de um *commit* ancestral ao atual. Isso
-é extremamente útil para resolver os bugs. Vamos fazer um segundo ramo a
-partir do *commit* anterior a inclusão do arquivo R.
-
-
-```bash
-## Referencias aos commits.
-git reflog
-```
-
-```
-## ed304f7 HEAD@{0}: merge feature01: Fast-forward
-## a2c3f0d HEAD@{1}: checkout: moving from feature01 to master
-## ed304f7 HEAD@{2}: commit: Adiciona função R para VIF.
-## a2c3f0d HEAD@{3}: checkout: moving from master to feature01
-## a2c3f0d HEAD@{4}: commit: Novos argumentos.
-## 41a3225 HEAD@{5}: commit: Adiciona frase do Linux Torvalds.
-## 448b201 HEAD@{6}: commit: Lista de inicial de o porquê usar o Linux.
-## ffc1d12 HEAD@{7}: commit (initial): Cria arquivo com título.
-```
-
-
-```bash
-## Volta para antes do arquivo de baixar o vif.R.
-git checkout HEAD@{4}
-```
-
-```
-## Note: checking out 'HEAD@{4}'.
-##
-## You are in 'detached HEAD' state. You can look around, make experimental
-## changes and commit them, and you can discard any commits you make in this
-## state without impacting any branches by performing another checkout.
-##
-## If you want to create a new branch to retain commits you create, you may
-## do so (now or later) by using -b with the checkout command again. Example:
-##
-## git checkout -b new_branch_name
-##
-## HEAD is now at a2c3f0d... Novos argumentos.
-```
-
-
-```bash
-## Qual a situação.
-git status
-```
-
-```
-## HEAD detached at a2c3f0d
-## nothing to commit, working directory clean
-```
-
-
-```bash
-## O histório existente nesse ponto.
-git log --name-only --oneline
-```
-
-```
-## a2c3f0d Novos argumentos.
-## porqueLinux.txt
-## 41a3225 Adiciona frase do Linux Torvalds.
-## README.txt
-## 448b201 Lista de inicial de o porquê usar o Linux.
-## porqueLinux.txt
-## ffc1d12 Cria arquivo com título.
-## README.txt
-```
-
-Já que o *commit* mais recente dessa história aponta para o arquivo
-compras, vamos checar o seu conteúdo apenas por medida de segurança.
-
-
-```bash
-## Mostra o conteúdo do arquivo.
-less porqueLinux.txt
-```
-
-```
-## Por que usar o Linux?
-##
-## * É livre
-## * É seguro
-## * É customizável
-## * Tem repositórios de software
-## * Atualização constante
-## * Desempenho
-```
-
-Dito e feito! Voltamos no tempo para o instante logo após o *commit* que
-incluí novos itens na lista. Podemos voltar para o presente se
-estivermos satisfeitos com o passeio mas também podemos criar um ramo
-aqui, caso isso seja necessário. Primeiro vamos voltar para o presente
-depois mostramos como criar o ramo.
-
-
-```bash
-## Mostra onde estamos.
-git branch
-```
-
-```
-## * (detached from a2c3f0d)
-## feature01
-## master
-```
-
-Se não fizemos nenhuma modificação, voltar é bem simples. Se
-modificações foram feitas é necessário saber se precisam ser mantidas e
-onde ou se devem ser descartadas.
-
-
-```bash
-## Volta para o presente.
-git checkout master
-```
-
-```
-## Previous HEAD position was a2c3f0d... Novos argumentos.
-## Switched to branch 'master'
-```
-
-
-```bash
-git status
-```
-
-```
-## On branch master
-## nothing to commit, working directory clean
-```
-
-
-```bash
-git log --oneline
-```
-
-```
-## ed304f7 Adiciona função R para VIF.
-## a2c3f0d Novos argumentos.
-## 41a3225 Adiciona frase do Linux Torvalds.
-## 448b201 Lista de inicial de o porquê usar o Linux.
-## ffc1d12 Cria arquivo com título.
-```
-
-
-```bash
-## Fenda no tempo fechada. Sem sinal do detached HEAD.
-git branch
-```
-
-```
-## feature01
-## * master
-```
-
-
-```bash
-## Sinal do passeio no tempo.
-git reflog
-```
-
-```
-## ed304f7 HEAD@{0}: checkout: moving from a2c3f0d2a344bf7c680ec67982efca4f5cdf164c to master
-## a2c3f0d HEAD@{1}: checkout: moving from master to HEAD@{4}
-## ed304f7 HEAD@{2}: merge feature01: Fast-forward
-## a2c3f0d HEAD@{3}: checkout: moving from feature01 to master
-## ed304f7 HEAD@{4}: commit: Adiciona função R para VIF.
-## a2c3f0d HEAD@{5}: checkout: moving from master to feature01
-## a2c3f0d HEAD@{6}: commit: Novos argumentos.
-## 41a3225 HEAD@{7}: commit: Adiciona frase do Linux Torvalds.
-## 448b201 HEAD@{8}: commit: Lista de inicial de o porquê usar o Linux.
-## ffc1d12 HEAD@{9}: commit (initial): Cria arquivo com título.
-```
-
-Vamos começar a ser ousados. Vamos voltar no passado, adicionar um
-arquivo, commitar e ver o que acontece, como o histórico é representado.
-
-
-```bash
-## Volta no tempo, após commit que aumenta porqueLinux.txt.
-git checkout HEAD@{6}
-```
-
-```
-## Note: checking out 'HEAD@{6}'.
-##
-## You are in 'detached HEAD' state. You can look around, make experimental
-## changes and commit them, and you can discard any commits you make in this
-## state without impacting any branches by performing another checkout.
-##
-## If you want to create a new branch to retain commits you create, you may
-## do so (now or later) by using -b with the checkout command again. Example:
-##
-## git checkout -b new_branch_name
-##
-## HEAD is now at a2c3f0d... Novos argumentos.
-```
-
-
-
-
-```bash
-## Baixa arquivo de dados da internet.
-wget 'http://www.leg.ufpr.br/~walmes/data/pimentel_racoes.txt'
-```
-
-
-```
-## --(date +"%Y-%m-%d %H:%M:%S")-- http://www.leg.ufpr.br/~walmes/data/pimentel_racoes.txt
-## Resolving www.leg.ufpr.br (www.leg.ufpr.br)... ???.??.???.??
-## Connecting to www.leg.ufpr.br (www.leg.ufpr.br)|???.??.???.??|:80... connected.
-## HTTP request sent, awaiting response... 200 OK
-## Length: 217 [text/plain]
-## Saving to: ‘pimentel_racoes.txt’
-##
-## 0K 100% 68,9M=0s
-##
-## (date +"%Y-%m-%d %H:%M:%S") (68,9 MB/s) - ‘pimentel_racoes.txt’ saved [217/217]
-##
-## ‘pimentel_racoes.txt’ -> ‘../meu1repo/pimentel_racoes.txt’
-```
-
-
-```bash
-git status
-```
-
-```
-## HEAD detached at a2c3f0d
-## Untracked files:
-## (use "git add <file>..." to include in what will be committed)
-##
-## pimentel_racoes.txt
-##
-## nothing added to commit but untracked files present (use "git add" to track)
-```
-
-
-```bash
-## Adiciona para registrar a inclusão do arquivo.
-git add pimentel_racoes.txt
-git commit -m "Adiciona aquivo de dados de experimento com rações."
-```
-
-```
-## [detached HEAD 344674a] Adiciona aquivo de dados de experimento com rações.
-## 1 file changed, 24 insertions(+)
-## create mode 100644 pimentel_racoes.txt
-```
-
-
-```bash
-git status
-```
-
-```
-## HEAD detached from a2c3f0d
-## nothing to commit, working directory clean
-```
-
-
-```bash
-## Log num formato gráfico ASCII para mostrar o novo ramo.
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 344674a (HEAD) Adiciona aquivo de dados de experimento com rações.
-## | * ed304f7 (master, feature01) Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-No nosso projeto temos o *master* e o *feature01* em igual condição, sem
-nenhuma diferença. O *commit* recém feito indica um novo seguimento a
-partir daquele onde adicionamos novos itens na lista. Vamos criar um
-novo ramo porque atualmente estamos em um ramos suspenso (*detached
-HEAD*) que não é persistênte.
-
-
-```bash
-git branch
-```
-
-```
-## * (detached from a2c3f0d)
-## feature01
-## master
-```
-
-
-```bash
-## Um novo ramo a partir do atual HEAD.
-git checkout -b feature02
-```
-
-```
-## Switched to a new branch 'feature02'
-```
-
-
-```bash
-git branch
-```
-
-```
-## feature01
-## * feature02
-## master
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 344674a (HEAD, feature02) Adiciona aquivo de dados de experimento com rações.
-## | * ed304f7 (master, feature01) Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-Vamos explorar bem a funcionalidade. Vamos voltar para o `feature01` e
-criar mais coisas lá. Você já deve estar pensando que tudo isso é
-absurdo e jamais alguém firaria indo e voltando assim. Você está certo,
-porém, quando o projeto envolve mais pessoas, cerrtamente as coisas irão
-bifurcar em algum ponto.
-
-
-```bash
-git checkout feature01
-```
-
-```
-## Switched to branch 'feature01'
-```
-
-
-```
-## Diretório existe.
-## Arquivo brasilCopa2014.txt já existe.
-## ‘brasilCopa2014.txt’ -> ‘../meu1repo/brasilCopa2014.txt’
-```
-
-
-```bash
-wget 'http://www.leg.ufpr.br/~walmes/cursoR/geneticaEsalq/brasilCopa2014.txt'
-```
-
-
-```
-## --2015-11-24 14:31:31-- http://www.leg.ufpr.br/~walmes/cursoR/geneticaEsalq/brasilCopa2014.txt
-## Resolving www.leg.ufpr.br (www.leg.ufpr.br)... ???.??.???.??
-## Connecting to www.leg.ufpr.br (www.leg.ufpr.br)|???.??.???.??|:80... connected.
-## HTTP request sent, awaiting response... 200 OK
-## Length: 1254 (1,2K) [text/plain]
-## Saving to: ‘brasilCopa2014.txt’
-##
-## 0K . 100% 69,6M=0s
-##
-## 2015-11-24 14:31:31 (69,6 MB/s) - ‘brasilCopa2014.txt’ saved [1254/1254]
-```
-
-
-```bash
-git add brasilCopa2014.txt
-git commit -m "Arquivo sobre copa 2014 celeção brasileira."
-```
-
-```
-## [feature01 78a7842] Arquivo sobre copa 2014 celeção brasileira.
-## 1 file changed, 22 insertions(+)
-## create mode 100644 brasilCopa2014.txt
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 78a7842 (HEAD, feature01) Arquivo sobre copa 2014 celeção brasileira.
-## * ed304f7 (master) Adiciona função R para VIF.
-## | * 344674a (feature02) Adiciona aquivo de dados de experimento com rações.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-Agora nos temos o *feature01* na frente do master e o *feature02* ao
-lado. O conteúdo dos dois ramos terá que ser incorporado ao *master* em
-algum momento porque é assim que funciona. Mas não há razões para
-preocupação pois o propósito do Git é justamente facilitar esse
-processo. Nesse caso, por exemplo, como as diferenças nos ramos consiste
-na adição de arquivos diferentes, incorporar as modificações no *master*
-será uma tarefa simples para o Git. O agravante é quando em dois ramos
-(ou duas pessoas) o mesmo arquivo é modificado no mesmo intervalo de
-linhas. Nessa situação o *merge* nos arquivos deve ser supervisionado e
-não automático. Vamos incorporar as modificações dos ramos ao master
-então.
-
-
-```bash
-## Volta para o master.
-git checkout master
-```
-
-```
-## Switched to branch 'master'
-```
-
-
-```bash
-## Mescla o feature01.
-git merge feature01 master
-```
-
-```
-## Updating ed304f7..78a7842
-## Fast-forward
-## brasilCopa2014.txt | 22 ++++++++++++++++++++++
-## 1 file changed, 22 insertions(+)
-## create mode 100644 brasilCopa2014.txt
-```
-
-
-```bash
-## Mescla o feature02.
-git merge feature02 master
-```
-
-```
-## Merge made by the 'recursive' strategy.
-## pimentel_racoes.txt | 24 ++++++++++++++++++++++++
-## 1 file changed, 24 insertions(+)
-## create mode 100644 pimentel_racoes.txt
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 0bac2be (HEAD, master) Merge branch 'feature02'
-## |\
-## | * 344674a (feature02) Adiciona aquivo de dados de experimento com rações.
-## * | 78a7842 (feature01) Arquivo sobre copa 2014 celeção brasileira.
-## * | ed304f7 Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-
-```bash
-tree
-```
-
-```
-## .
-## ├── brasilCopa2014.txt
-## ├── pimentel_racoes.txt
-## ├── porqueLinux.txt
-## ├── README.txt
-## └── vif.R
-##
-## 0 directories, 5 files
-```
-
-****
-## Resolvendo conflitos
-
-Agora vamos de propósito mostrar uma situação em que não é possível
-fazer o merge automaticamente. Vamos criar um conflito. Para isso vou
-criar um ramo novo, modificar o arquivo na última linha e commitar. Vou
-voltar par ao *master* e fazer o mesmo mas vou usar um texto diferente
-para incluir no arquivo. Já que os ramos *feature01* e *feature02* não
-são mais necessários, podemos removê-los. No entanto, eles permanecem na
-história do projeto e poder resurgir se você voltar no tempo.
-
-
-```bash
-## Remove ramos.
-git branch -d feature01
-git branch -d feature02
-git branch
-```
-
-```
-## Deleted branch feature01 (was 78a7842).
-## Deleted branch feature02 (was 344674a).
-## * master
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 0bac2be (HEAD, master) Merge branch 'feature02'
-## |\
-## | * 344674a Adiciona aquivo de dados de experimento com rações.
-## * | 78a7842 Arquivo sobre copa 2014 celeção brasileira.
-## * | ed304f7 Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-Agora vou criar um novo ramo, adicionar um arquivo e encurtar o nome das
-colunas no cabeçalho.
-
-
-```bash
-## Muda para um ramo criado na hora.
-git checkout -b feature03
-```
-
-```
-## Switched to a new branch 'feature03'
-```
-
-
-
-
-```bash
-## Baixa o arquivo.
-wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt'
-```
-
-
-```
-## --2015-11-24 14:31:31-- http://www.leg.ufpr.br/~walmes/data/bib1.txt
-## Resolving www.leg.ufpr.br (www.leg.ufpr.br)... ???.??.???.??
-## Connecting to www.leg.ufpr.br (www.leg.ufpr.br)|???.??.???.??|:80... connected.
-## HTTP request sent, awaiting response... 200 OK
-## Length: 535 [text/plain]
-## Saving to: ‘bib1.txt’
-##
-## 0K 100% 35,0M=0s
-##
-## 2015-11-24 14:31:31 (35,0 MB/s) - ‘bib1.txt’ saved [535/535]
-```
-
-
-```bash
-## Mostra as 4 primeiras linhas.
-head -4 bib1.txt
-```
-
-```
-## repetição variedade bloco y
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-```
-
-Ao encurtar o nome para quatro dígitos, fica assim.
-
-
-```bash
-## Substitui o conteúdo da primeira linha pelos nomes truncados em 4
-## dígidos e separados por tabulação. Etapa que você pode fazer no seu
-## editor de texto.
-sed -i "1s/.*/rept\tvari\tbloc\ty/" bib1.txt
-head -4 bib1.txt
-```
-
-```
-## rept vari bloc y
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-```
-
-
-```bash
-git add bib1.txt
-git commit -m "Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos."
-```
-
-```
-## [feature03 ef648bb] Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos.
-## 1 file changed, 58 insertions(+)
-## create mode 100644 bib1.txt
-```
-
-Baixamos e modificamos o arquivo. Adicionamos e fizemos o registro das
-modificações. Agora vamos voltar ao *master* e baixar o arquivo também,
-fazendo de conta que é outra pessoa trabalhando no mesmo projeto, mas
-essa pessoa vai passar a cabeçalho para caixa alta.
-
-
-```bash
-git checkout master
-```
-
-```
-## Switched to branch 'master'
-```
-
-
-
-
-```bash
-## Baixa o arquivo.
-wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt'
-```
-
-Ao encurtar o nome para quatro dígitos, fica assim.
-
-
-```bash
-## Substitui o conteúdo da primeira linha pelo mesmo em caixa alta. Faça
-## isso no seu editor de texto de preferido.
-sed -i '1s/.*/\U&/' bib1.txt
-head -4 bib1.txt
-```
-
-```
-## REPETIÇÃO VARIEDADE BLOCO Y
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-```
-
-
-```bash
-git add bib1.txt
-git commit -m "Arquivo de experimento em BIB. Cabeçalho em caixa alta."
-```
-
-```
-## [master 87e8601] Arquivo de experimento em BIB. Cabeçalho em caixa alta.
-## 1 file changed, 58 insertions(+)
-## create mode 100644 bib1.txt
-```
-
-
-```bash
-git diff master feature03
-```
-
-```
-## diff --git a/bib1.txt b/bib1.txt
-## index a8dfaa6..b5f5963 100644
-## --- a/bib1.txt
-## +++ b/bib1.txt
-## @@ -1,4 +1,4 @@
-## -REPETIÇÃO VARIEDADE BLOCO Y
-## +rept vari bloc y
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * ef648bb (feature03) Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos.
-## | * 87e8601 (HEAD, master) Arquivo de experimento em BIB. Cabeçalho em caixa alta.
-## |/
-## * 0bac2be Merge branch 'feature02'
-## |\
-## | * 344674a Adiciona aquivo de dados de experimento com rações.
-## * | 78a7842 Arquivo sobre copa 2014 celeção brasileira.
-## * | ed304f7 Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-
-```bash
-## Dá mensagem de erro que informa o conflito.
-git merge feature03 master
-```
-
-
-```
-## Auto-merging bib1.txt
-## CONFLICT (add/add): Merge conflict in bib1.txt
-## Automatic merge failed; fix conflicts and then commit the result.
-```
-
-
-```bash
-git status
-```
-
-```
-## On branch master
-## You have unmerged paths.
-## (fix conflicts and run "git commit")
-##
-## Unmerged paths:
-## (use "git add <file>..." to mark resolution)
-##
-## both added: bib1.txt
-##
-## no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-
-```bash
-## `less` printa o conteúdo do arquivo mas `head` limita para 10 linhas.
-less bib1.txt | head -10
-```
-
-```
-## <<<<<<< HEAD
-## REPETIÇÃO VARIEDADE BLOCO Y
-## =======
-## rept vari bloc y
-## >>>>>>> feature03
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-## 1 4 2 16
-## 1 5 3 14
-```
-
-Então deu conflito e o Git informa que ele deve ser resolvido. Resolver
-o conflito aqui significa abrir os arquivos com problema listados no git
-status e editar de tal forma a desconflitar. Nas regiões de conflito o
-Git sinaliza de forma especial, indicando por divisórias (`<<<<<<<`,
-`=======` e `>>>>>>>`) as versões no HEAD (ramo *master*) e no ramos a
-ser incorporado (*feature03*). Então vamos resolver o conflito sem
-favorecer ninguém, ou seja, vamos encurtar para 4 digitos e manter caixa
-alta. Dessa forma o aquivo fica assim.
-
-
-
-
-```bash
-## Arquivo depois da edição que resolve o conflito.
-head -6 bib1.txt
-```
-
-```
-## REPT VARI BLOC Y
-## 1 1 1 20
-## 1 2 1 18
-## 1 3 2 15
-## 1 4 2 16
-## 1 5 3 14
-```
-
-
-```bash
-git status
-```
-
-```
-## On branch master
-## You have unmerged paths.
-## (fix conflicts and run "git commit")
-##
-## Unmerged paths:
-## (use "git add <file>..." to mark resolution)
-##
-## both added: bib1.txt
-##
-## no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-
-```bash
-git add bib1.txt
-git commit -m "Resolve conflito, trunca com caixa alta."
-```
-
-```
-## [master 52b1f76] Resolve conflito, trunca com caixa alta.
-```
-
-
-```bash
-git status
-```
-
-```
-## On branch master
-## nothing to commit, working directory clean
-```
-
-
-```bash
-git log --graph --oneline --decorate --date=relative --all
-```
-
-```
-## * 52b1f76 (HEAD, master) Resolve conflito, trunca com caixa alta.
-## |\
-## | * ef648bb (feature03) Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos.
-## * | 87e8601 Arquivo de experimento em BIB. Cabeçalho em caixa alta.
-## |/
-## * 0bac2be Merge branch 'feature02'
-## |\
-## | * 344674a Adiciona aquivo de dados de experimento com rações.
-## * | 78a7842 Arquivo sobre copa 2014 celeção brasileira.
-## * | ed304f7 Adiciona função R para VIF.
-## |/
-## * a2c3f0d Novos argumentos.
-## * 41a3225 Adiciona frase do Linux Torvalds.
-## * 448b201 Lista de inicial de o porquê usar o Linux.
-## * ffc1d12 Cria arquivo com título.
-```
-
-
-```bash
-git reflog
-```
-
-```
-## 52b1f76 HEAD@{0}: commit (merge): Resolve conflito, trunca com caixa alta.
-## 87e8601 HEAD@{1}: commit: Arquivo de experimento em BIB. Cabeçalho em caixa alta.
-## 0bac2be HEAD@{2}: checkout: moving from feature03 to master
-## ef648bb HEAD@{3}: commit: Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos.
-## 0bac2be HEAD@{4}: checkout: moving from master to feature03
-## 0bac2be HEAD@{5}: merge feature02: Merge made by the 'recursive' strategy.
-## 78a7842 HEAD@{6}: merge feature01: Fast-forward
-## ed304f7 HEAD@{7}: checkout: moving from feature01 to master
-## 78a7842 HEAD@{8}: commit: Arquivo sobre copa 2014 celeção brasileira.
-## ed304f7 HEAD@{9}: checkout: moving from feature02 to feature01
-## 344674a HEAD@{10}: checkout: moving from 344674a37125d278b22320956316e7df2e939fdc to feature02
-## 344674a HEAD@{11}: commit: Adiciona aquivo de dados de experimento com rações.
-## a2c3f0d HEAD@{12}: checkout: moving from master to HEAD@{6}
-## ed304f7 HEAD@{13}: checkout: moving from a2c3f0d2a344bf7c680ec67982efca4f5cdf164c to master
-## a2c3f0d HEAD@{14}: checkout: moving from master to HEAD@{4}
-## ed304f7 HEAD@{15}: merge feature01: Fast-forward
-## a2c3f0d HEAD@{16}: checkout: moving from feature01 to master
-## ed304f7 HEAD@{17}: commit: Adiciona função R para VIF.
-## a2c3f0d HEAD@{18}: checkout: moving from master to feature01
-## a2c3f0d HEAD@{19}: commit: Novos argumentos.
-## 41a3225 HEAD@{20}: commit: Adiciona frase do Linux Torvalds.
-## 448b201 HEAD@{21}: commit: Lista de inicial de o porquê usar o Linux.
-## ffc1d12 HEAD@{22}: commit (initial): Cria arquivo com título.
-```
-
-
-
diff --git a/cap04.md b/cap04.md
deleted file mode 100644
index ffec6bbf3b1fff90a93a431044d25623b375eaba..0000000000000000000000000000000000000000
--- a/cap04.md
+++ /dev/null
@@ -1,335 +0,0 @@
-# 4. Projetos remotos
-PET Estatística
-29/11/2015
-
-
-
-## Introdução
-
-Para colaborar em projetos coletivos no Git é preciso ter um repositório remoto. Este repositório conterá todo o histórico das versões dos arquivos editados. A seguir serão abordados como adicionar, remover e gerenciar repositórios remotos.
-
-Primeiramente será apresentado o comando `git remote`, este é usado para verificar quais repositórios estão configurados.
-
-**Exemplo:** para retornar a lista de repositórios:
-
-
-```bash
-git remote
-```
-
-```
-## MeuRepo
-## RenameRepo
-## origin
-```
-
-No comando acima é possível visualizar o remoto padrão **origin** (URL SSH para onde será possível enviar os seus arquivos).
-
-**Exemplo:** para retornar o nome dos repositórios com a URL onde foram armazanados:
-
-
-```bash
-git remote -v
-```
-
-```
-## MeuRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## MeuRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-## RenameRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## RenameRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-## origin git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## origin git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-```
-
-
-### Adicionando repositórios remotos
-
-O comando `git remote add` adiciona um repositório remoto. No exemplo a seguir será adicionado um repositório chamado **MeuRepo** ao qual será vinculado a URL `git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git`. Usaremos como exemplo o projeto Git **Apostila-git**.
-
-**Exemplo:**
-
-```bash
-git remote add MeuRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
-# Quando executamos novamente o comando para obter a lista de repositórios:
-git remote -v
-```
-
-```
-## fatal: remote MeuRepo already exists.
-## MeuRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## MeuRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-## RenameRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## RenameRepo git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-## origin git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (fetch)
-## origin git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git (push)
-```
-
-Pare acessar localmente o branch master do projeto **Apostila-git** será usado `MeuRepo/master`.
-
-### Obtendo informações de um Remoto
-
-Você pode acessar as informações de qualquer repositório remoto com o comando `git remote show`, que retornará a URL e os `branches`.
-
-**Exemplo:**
-
-```bash
-git remote show origin
-```
-
-```
-## * remote origin
-## Fetch URL: git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
-## Push URL: git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
-## HEAD branch: devel
-## Remote branches:
-## Issue#49 tracked
-## devel tracked
-## issue#15 new (next fetch will store in remotes/origin)
-## issue#23 tracked
-## issue#36 tracked
-## issue#48 tracked
-## issue#50 tracked
-## issue#51 tracked
-## issue#53 new (next fetch will store in remotes/origin)
-## issue#54 new (next fetch will store in remotes/origin)
-## issue#56 new (next fetch will store in remotes/origin)
-## issue#57 new (next fetch will store in remotes/origin)
-## master tracked
-## refs/remotes/origin/Issue#39 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#10 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#11 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#12 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#13 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#17 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#21 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#27 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#37 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#38 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#40 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#43 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#44 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#45 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#47 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#7 stale (use 'git remote prune' to remove)
-## refs/remotes/origin/issue#9 stale (use 'git remote prune' to remove)
-## Local branch configured for 'git pull':
-## devel merges with remote devel
-## Local ref configured for 'git push':
-## devel pushes to devel (up to date)
-```
-
-### Renomeado Remotos
-
-O comando `git remote rename` pode modificar o nome de um repositório remoto. A seguir o repositório `MeuRepo`será renomeado para `RenameRepo`.
-
-**Exemplo:**
-
-```sh
-git remote rename MeuRepo RenameRepo
-```
-
-### Removendo Remotos
-
-Para remover remotos é utilizado o comando `git remote rm`, agora será removido o repositório renomeado anteriormente `RenameRepo`.
-
-**Exemplo:**
-
-```sh
- git remote rm RenameRepo
-```
-
-**Protocolos Git**
-
-Há quatro tipos diferentes de protocolos Git (Local, Git, HTTP e SSH).
-
-Nesta apostila será abordado apenas o Secure Shell (SSH). Por ser fácil de fazer a configuração do acesso deste protocolo aos servidores, este é o mais usual.
-
-## Criando um Repositório Git
-
-Primeiramente é necessário ter acesso a um servidor Linux com chave SSH, no qual você poderá ter seus repositórios. É definido um diretório no qual será armazenado o repositório remoto.
-No próximo exemplo é preciso criar um repositório remoto chamado `MeuRepo` e o armazenar em um diretório `~/git`:
-
-**Exemplo:**
-
- ```sh
- # Para criar um diretório git na sua home:
- mkdir ~/git
- # Para criar um repositório git:
- mkdir MeuRepo.git
- # Para definir MeuRepo como um repositório remoto:
- git --bare init
- ```
-
-As configurações do servidor estão completas. A partir você pode realizar os primeiros comandos para iniciar o repositório criado.
-
-
-## Git no servidor
-
-Primeiramente, para configurar o Git no Servidor e configurar os protocolos, clonaremos o repositório existente em um repositório limpo.
-**Observação:** você poderá colocar um repositório no Servidor se este não contém um diretório de trabalho.
-
-**Exemplo:**
-
-```sh
- git clone --bare MeuRepo MeuRepo.git
-```
-
-Acima foi criado um repositório limpo `MeuRepo.git`, no qual está armazenada a cópia de todos os arquivos do diretorio Git.
-
-Após este primeiro passo o repositório limpo será colocado no Servidor e configurado os protolocos.
-No exemplo abaixo, supondo que você tem configurado um servidor `git.servidor.com`, e um diretório `/dir/git`no qual você quer armazenar seus repositórios. Ao copiar o seu repositório limpo, você pode configurar seu novo repositório.
-
-**Exemplo:**
-
- ```sh
- scp -r MeuRepo.git usuario@git.example.com:/dir/git
- ```
-
-Agora o repositório pode ser clonado por outros usuários, que podem ter acesso de escrita e de envio de arquivos `push` no diretório.
-
-
- ```sh
- git clone usuario@git.example.com:/dir/git/MeuRepo.git
- ```
-
-
-## Configuração de Conexão SSH com Servidor
-
-O Git possibilita ao usuário realizar uma chave SSH que fará uma conexão segura da sua máquina com o servidor. Para isso começamos com o seguinte comando no terminal:
-
-**Exemplo:**
-
- ```sh
- ## Gerando uma chave ssh
- ssh-keygen -t rsa -C "usuario@email.com"
- ```
-
-A partir deste comando, será possível alterar o diretório onde será salva a chave SSH. O usuário tem a opção de permanecer com o diretório padrão, para isso basta apertar Enter.
-A partir disso, são criados dois arquivos no diretório, o `id_rsa` e o `id_rsa.pub`.
-Após escolher o diretório onde serão salvos os arquivos, você terá a opção de digitar uma senha ou deixar o espaço em branco.
-
-Para visualizar a chave basta digitar o seguinte comando:
-
-**Exemplo:**
-
- ```sh
- cat ~/.ssh/id_rsa.pub
- ```
-
-A chave está no arquivo `id_rsa.pub`. O usuário deve copiar o texto deste arquivo na íntegra.
-Para gerar a conexão ssh com o servidor, deve visitar o site [https://gitlab.c3sl.ufpr.br/profile/keys](https://gitlab.c3sl.ufpr.br/profile/keys) e clicar em [Add SSH Key](https://gitlab.c3sl.ufpr.br/profile/keys/new). É necessário escrever um título para a sua nova chave, no campo `key` colar o texto copiado do arquivo `id_rsa.pub` e adicionar sua nova chave.
-
-Para checar a configuração da sua máquina com o sevidor basta realizar o seguinte comando:
-
-**Exemplo:**
-
- ```sh
- ssh -T git@gitlab.c3sl.ufpr.br
- ```
-
-
-**Configurando o servidor**
-
-Agora será abordado como configurar o acesso SSH do ponto de vista do servidor.
-Você precisa criar um usuário Git e um diretório `.ssh` para este usuário.
-
-**Exemplo:** criar usuário e diretório.
-
- ```sh
- sudo adduser git
- su git
- cd
- mkdir .ssh
- ```
-
-Agora, você terá um arquivo chamado `authorized_keys` onde será adicionado uma chave pública de algum desenvolvedor. Após obter chaves de alguns usuários, você pode salvá-las no arquivo `authorized_keys`, como no exemplo a seguir.
-
-**Exemplo:**
-
-```sh
-cat /tmp/id_rsa1.pub >> ~/.ssh/authorized_keys # chave do primeiro usuário
-cat /tmp/id_rsa2.pub >> ~/.ssh/authorized_keys # chave do segundo usuário
-...
-```
-
-Depois de armazenar as chaves dos usuários, basta criar um repositório limpo (sem um diretório de trabalho) para eles. Como visto anteriormente:
-
-**Exemplo:**
-
-```sh
-cd/dir/git
-mkdir NovoProjeto.git
-cd NovoProjeto.git
-git –bare init
-```
-
-Agora os usuários, cujas chaves foram salvas no arquivo `authorized_keys` podem compartilhar arquivos no repositório com os comando `git init`, `git add`, `git commit`, `git remote add` e `git push origin master`.
-
-
-## Comandos clone, push, pull e fetch
-
-### Git clone
-
-Este comando é usado para clonar um repositório do servidor remoto para um servidor local, caso você queira copiar um repositório que já existe para realizar colaborações em um projeto que queira participar.
-Você terá acesso a todos os arquivos e poderá verificar as diferentes versões destes.
-No exemplo abaixo temos uma bibliotaca Git, chamada **TesteClone**, que será clonado da seguinte forma:
-
-**Exemplo:**
-
- ```sh
- git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git
- ```
-
-Desta forma você terá um diretório `TesteClone` em seu computador, onde estarão todos os arquivos do projeto nele.
-
-O usuário também terá a opção de clonar o repositório `TesteClone` em um diretório diferente do padrão Git, que no próximo exemplo denominaremos de `DirTeste`:
-
-**Exemplo:**
-
- ```sh
- git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git DirTeste
- ```
-
-
-### Git Push
-
-Usado para transferência de arquivos entre repositório local e o servidor remoto. Como o nome já diz, o comando empurra os arquivos para o servidor remoto.
-No exemplo abaixo enviaremos a ramificação `Branch Master` para o servidor chamado `origin`:
-
-**Exemplo:**
-
- ```sh
- git push origin master
- ```
-
-É importante ressaltar que se dois usuários clonarem ao mesmo tempo, realizarem modificações e enviarem os arquivos atualizados ao repositório utilizando o `Git push`, as modificações do usuário que realizou o push por último serão desconsideradas.
-
-### Git Pull
-
-Também utilizado para transferência de arquivos. O comando puxa os arquivos do servidor remoto para o repositório local e faz o merge do mesmo, fundindo a última versão com a versão atualizada.
-
-**Exemplo:**
-
- ```sh
- git pull origin master
- ```
-
-### Git fetch
-
-Assim como o comando `Git pull`, o `Git fetch` transfere arquivos do repositório remoto para o local, porém ele não realiza automaticamente o merge dos arquivos transferidos, o usuário deve fazer o merge manualmente.
-
-**Exemplo:**
-
- ```sh
- git fetch origin master
- ```
-
-Para verificar as modificações realizadas entre versões de um arquivo basta utilizar o comando `git diff`:
-
-**Exemplo:**
-
-```sh
-git diff master origin/master
-```
-
-
diff --git a/cap06.md b/cap06.md
deleted file mode 100644
index 7a491c791e0d139c5d3d23aa985735dc3ac62200..0000000000000000000000000000000000000000
--- a/cap06.md
+++ /dev/null
@@ -1,322 +0,0 @@
-# Ferramentas Gráficas
-PET Estatística UFPR
-
-
-
-# Ferramentas gráficas #
-
-No GIT, como vimos até agora, todo o gerenciamento do projeto é
-realizado via *CLI (Command line interface)*, linhas de comando
-interpretadas, geralmente pelo *bash*. Isso confere um maior controle e
-segurança nas ações realizadas, mas em muitas situações os comandos e
-*outpus* GIT não se apresentam de forma tão amigável seja pela difícil
-memorização ou pela interatividade limitada.
-
-Os comandos mais usuais como `git add`, `git commit` se tornam simples,
-pois, mesmo para um usuário iniciante eles fazem parte do cotidiano em
-um projeto sob versionamento GIT. Mas algumas situações que não ocorrem
-com frequência, como por exemplo voltar a versão de um arquivo ou do
-repositório, requerem comandos que são pouco utilizados e para realizá-las
-é necessário a consulta de algum material sobre GIT. Outra situação onde
-a utilização dos comandos é dificultada, ocorre para projetos maiores, onde
-muitos arquivos são alterados simultaneamente e o procedimento de *commit*
-se torna trabalhoso, pois é necessário listar todos os arquivos que fazem
-parte de um *commit* no commando `git add`. Uma última situação exemplo
-em que o uso de *CLI* não parece satisfatório é na comparação de arquivos,
-já usamos o comando `git diff` no capítulo 3 e o *output* deste comando
-foi de simples visualização, mas em arquivos maiores (com muitas linhas)
-a navegação para verificar as alterações do arquivo não é tão amigável. Para
-facilitar essas e outras situações surgem as *GUI's (Graphical User
-Interfaces)*, interfaces gráficas para o usuário que incorpora comandos
-GIT em *widgets*(botões, caixas de texto etc.) dispostos em uma janela
-gráfica de seu sistema operacional.
-
-
-# Interfaces GIT #
-
-Neste material chamaremos de **Interfaces GIT** as *GUI's* para gestão
-de um repositório. Estas facilitam a utilização das principais
-instruções **GIT** (`git add`, `git commit`, `git push`, `git pull`),
-visualização dos arquivos e alterações no repositório.
-
-Desde o surgimento do GIT diversas *GUI's* foram propostas. Neste
-capítulo apresentamos as principais *GUI's* em diferentes plataformas nos
-sistemas UNIX, Mac OS X e Windows. Detalhes de download, instalação e
-exemplos da utilização destas interfaces no fluxo de trabalho de um
-projeto com versionamento **GIT** são descritos.
-
-## git-gui ##
-
-Baseada em *Tcl/Tk* a *GUI* chamada `git gui` é mantida como projeto
-independente do GIT, mas as versões estáveis são distribuídas junto com
-o programa principal, portanto não é necessário o download e
-instalação. A interface é voltada para realizar alterações no
-repositório, desde as mais simples como *commitar* arquivos até as mais
-específicas como voltar estágios ou reescrever o último *commit* (muito
-útil quando notamos erros de gramática logo após a submissão). Nesta
-seção abordaremos apenas as alterações mais comuns no repositório.
-
-`git gui`, no Windows, pode ser aberto pelo menu iniciar. Nesta
-plataforma, ao instalar o GIT (conforme visto no capítulo 2) duas
-aplicações ficam disponíveis **git BASH** e **git GUI**. Em sistemas
-LINUX podemos criar um *alias* (criar e editar adequadamente um
-arquivo em */usr/share/applications*) para que a `git gui` fique listada
-junto as aplicações do sistema. --Descobrir no MAC se `git gui` fica no
-lançador automaticamente. Porém, de forma geral, independente da
-plataforma de trabalho, a `git gui` pode ser iniciada a partir de um
-terminal `bash`, com o comando:
-
-```sh
-git gui
-```
-
-Para exemplificar a utilização desta interface vamos alterar alguns
-arquivos do repositório `meu1repo`, criado no capítulo 3.
-
-
-
-
-```bash
-cd meu1repo/
-
-echo $(tr '[[:lower:][:upper:]]' '[[:upper:][:lower:]]' < README) > README
-
-echo "Lista de afazeres:
--------------------------------------------
-* tarefa 1
-* tarefa 2
-* tarefa 3
-* tarefa 4
-* tarefa 5
-* tarefa 6" > TODO.txt
-
-echo "
-Mais um arquivo criado" > OTHER.txt
-```
-
-Após as alterações a interface gráfica é chamada.
-
-
-FIGURA: Inteface `git gui`
-
-A interface `git gui` se apresenta de forma simples, o que facilita
-sua utilização. Na figura ?? detacamos as quatro áreas que compreendem a
-interface. Na primeira porção temos listados os arquivos presentes no
-*working directory*, os arquivos criados aparecem com ícone em branco e
-os modificados com linhas em azul, aqui a interface implementa
-interativamente o comando `git add`, pois ao clicar no ícone de um
-arquivo ele é automaticamente adicionado à *staging area*. Na segunda
-parte são listados os arquivos na *staging area* com ícone de *check
-mark*. Na terceira parte temos a implementação do comando
-`git diff` para qualquer arquivo selecionado. Com destaque de cores, a
-interface apresenta em vermelho as deleções e em verde as adições. Por fim
-temos no canto inferior direito a área para escrever *commits* com
-botões para submissão de ação. Um detalhe importante do `git gui` é que
-o idioma do sistema operacional é verificado para sua construção, ou
-seja, os botões da interface na figura ?? são *push*, *commit*, *sign
-off*, etc pois o idioma do sistema operacional em que essa interface foi
-executada é o inglês. Para português (Brasil) as mensagens ficam .....
-
-Além das quatro áreas principais da interface, que facilitam
-interativamente atividades como `git status`, `git diff`, `git add`,
-`git commit` e `git push`, temos mais implementações no menu da
-interface para procedimentos não cotidianos. Essas implementações podem
-ser acessadas com um simples clique e são auto-explicativas.
-
-## gitk ##
-
-Pioneira dentre as interfaces gráficas, `gitk` foi a primeira
-*GUI* implementada. Também implementada em *Tcl/Tk*, esta *GUI*
-tem como objetivo a apresentação do histórico de um projeto. A `gitk`
-é incorporada ao principal repositório do GIT, portanto nas instalações
-completas do GIT esta interface fica disponível sem ser necessário
-download e instalação. Nesta seção apresentamos a `gitk` detalhando a
-disposição dos elementos nesta interface que se mostra muito útil na
-visualização de projetos GIT.
-
-A `gitk` trabalha em conjunto com a `git gui`. Em `git gui` podemos fazer
-alterações de forma rápida e visual nos arquivos que estão na *staging
-area* e *working directory*, porém para visualizar o histórico completo
-de *commits* com ramificações, marcações e demais detalhes, recorremos
-à `gitk`. Essa interface se mostra muito útil também como ferramenta de
-aprendizagem GIT, uma vez que visualizar de forma gráfica as alterações
-que os comandos realizados causam no projeto, torna mais fácil a
-compreensão dos mesmos.
-
-`gitk`, assim como a `git gui` pode ser chamada atráves de linha de
-comando:
-
-```sh
-gitk
-```
-
-Para exemplificar a disposição dos elementos nesta interface, seguimos
-com as alterações feitas na seção anterior, lembrando que temos todas as
-alterações já realizadas no capítulo 3 e ainda duas modificações e uma
-inclusão de arquivos não *commitadas*. Visualizando a interface `gitk`
-chamada neste estado do repositório temos:
-
-
-FIGURA: Inteface `gitk`
-
-Perceba na figura ?? que esta interface é bem mais completa do que a `git
-gui` no que diz respeito à informação. Dividida em apenas duas partes, a
-`gitk` apresenta na primeira todo o histórico do projeto, é uma
-implementação visual e agradável do comando `git log --graph`. No
-gráfico apresentado na parte superior, as bolinhas azuis representam
-*commits* passados, a de amarelo indica o estado atual do repositório e
-em vermelho são asmodificações no *working directory*. Ao lado estão os
-autores dos respectivos *commits* e o momento em que foram feitos. Na parte
-inferior da interface temos o detalhamento do *commit* selecionado
-na parte superior. As informações contidas aqui vão desde o
-identificador do *commit* (*SHA1 ID*), diferença das modificações
-referenciadas por este *commit* com relação ao estado anterior do
-repositório até a listagem dos arquivos atingidos pelo *commit*
-selecionado.
-
-Além da excelente apresentação visual do repositório GIT, a interface
-`gitk` também permite algumas alterações. Clicando com o botão direito de
-seu *mouse* em qualquer *commit* listado podemos criar *tags*, reverter o
-repositório neste estado, criar um ramo a partir do *commit* dentre outras
-opções possíveis atráves da interface.
-
-`gitk` é uma implementação em *Tcl/Tk* para visualização de repositórios
-GIT. Com o mesmo objetivo outras interfaces gráficas foram
-implementadas.
-
-
-Podemos destacar duas delas pela grande similaridade à
-`gitk`, são elas `gitg` e `gitx`. Ambas podem ser instalar em:
-
-* https://git-scm.com/docs/gitk
-* https://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to-understand-git/
-
-## Outras Interfaces ##
-
-### gitg e gitx ###
-
-Estas duas interfaces tentam juntar em uma única as opções proporcionadas
-pela `git gui` e pela `gitk`. Os layouts e as propostas são similares, a
-diferença está na portabilidade.
-A `gitg` é implementada em *GTk+* e está disponível para sistemas LINUX e a
-`gitx` foi implementada para Mac OS seguindo o estilo de aplicativos
-deste sistema operacional. De forma geral não há detalhes a serem
-repassados sobre estas interfaces uma vez que as possibilidades já foram
-listadas nas seções sobre `git gui` e `gitk`
-
-
-FIGURA: Interface `gitg`
-
-
-FIGURA: Interface `gitx`
-
-### RabbitVCS ###
-
-*RabbitVCS* é uma coleção de ferramentas gráficas para navegadores de
- arquivos do sistema LINUX que permitem o acesso simples e direto aos
- sistemas de controle de versão GIT e/ou Subversion. Não se caracteriza
- como interface, porém altera a visualização no navegador de arquivos de
- diretórios sob versionamento GIT além de dispor de ações implementadas
- nas opções do menu quando pressionado o botão direito do mouse.
-
-
-FIGURA: Navegador *Nautilus* com uso do `RabbitVCS`
-
-Na figura ?? temos o *screenshot* do repositório `meu1repo` no navegor
-de arquivos `nautilus` (padrão do sistema Ubuntu 14.04). Perceba que com
-essa interface os ícones de arquivos e pastas no navegador ganham
-destaque com um outro pequeno ícone na paste inferior. Estes pequenos
-ícones indicam o estado do arquivo sem precisar recorrer ao terminal, ou
-seja, temos um `git status` no próprio navegador de arquivos. Além disso
-`RabbitVCS` complementa o menu de opções acessados com o botão direito
-do mouse. As opções implementadas neste menu são completas, vão
-desde *commits*, criação de *branchs* e *tags* até a ações de
-reverter o estado do repositório.
-
-### git-cola ###
-
-Esta também é uma interface alternativa que se destaca por ser completa
-e pela portabilidade (disponível para sistema LINUX, Windows e
-Mac). Implementada em *python*, `git-cola` é uma alternativa à `git gui`
-e contém praticamente os mesmos elementos para alterações no
-repositório. Como a `git gui` se auxilia da `gitk` para visualização,
-a `git-cola` também tem uma interface de apoio, chamada de `git-dag` que
-vem instalado junto ao `git-cola`.
-
-
-FIGURA: Interface `git-cola` e `git-dag`
-
-Perceba pela figura ?? que as opções das interfaces são similares
-as apresentadas em `git gui` e `gitk`. As interfaces `git-cola` e
-`git-dag` se destacam pela fácil manipulação do layout exibido, além de
-buscar deixar a interface mais intuitiva possível. Como destaque em
-implementação de funcionalidade GIT, a `git-cola` se sobressai com relação
-à `git gui` na possibilidade de execução do comando `git rebase` via
-interface.
-
-### Plugins e extensões para editores ###
-
-Muitas vezes é inconveniente trabalhar com códigos fonte em um editor e
-ter que abrir um terminal *bash* em outra janela do sistema operacional
-para verificar o sistema de versionamento, realizar commits,
-etc. Felizmente alguns editores possuem um sistema **GIT** integrado,
-seja por meio de *plugins* adicionais instalados ou pela opção nativa do
-editor.
-
-Destacamos aqui dois editores, comumente utilizados pela comunidade
-estatística, que possuem os comandos **GIT** intergrado à sua
-interface. São eles, o `emacs`, o qual temos as opções de *buffers* nos
-editores onde podemos abrir uma instância *shell* e executar os comandos
-**GIT** junto com o desenvolvimento do código fonte. Além disso uma
-extensão poderosa chamada `magit`[^magit] está disponível e em
-desenvolvimento para o **GIT** no `emacs`, esta extensão proporciona
-opções de comandos e visualização em um *buffer* do editor que facilita
-o trabalho de versionamento. Outro editor também muito utilizado em
-Estatística, talvez o mais utilizado pela comunidade, é o RStudio que
-também implementa em sua interface vários comandos, assim como as
-interfaces anteriormente descritas e para tarefas não triviais uma
-chamada do terminal *Shell* é possível dentro do aplicativo. As diversas
-ferramentas do editor RStudio serão exploradas no capítulo ??, com
-exemplos e ilustrações voltadas para a comunidade estatística.
-
-# Interfaces de comparação #
-
-Uma das principais vantagens do **GIT** é a possibilidade de trabalho
-paralelo por dois ou mais usuários ou por ramos de desenvolvimento. E
-como qualquer desenvolvimento paralelo, desejamos ao final do trabalho,
-mesclar as contribuições realizadas lado a lado. Como vimos no capítulo
-3 isso é feito através do comando `git merge ramo_desenvolvimento` para ramos
-locais e com o comando `git push origin` quando estamos trabalhando em
-equipe e as contribuições são enviadas para um servidor remoto, capítulo
-4. Porém, quando a mesma porção de um mesmo arquivo é alterada em duas
-instâncias distintas (ramos diferentes, usuários diferentes etc.) ocorrem
-conflitos e vimos como o **GIT** os sinaliza para que possamos resolvê-los.
-Nesta seção mostraremos as interfaces gráficas dedicadas à resolução de
-conflitos no mesclagem e a visualização da diferença de arquivos em
-estados diferentes do repositório.
-
-## Ferramentas de Comparação Padrão ##
-
-* meld
- + Download e Instalação
- + Utilização básica
- + Utilização no **GIT** como `difftool` e/ou `mergetool`
- + screenshots
-
-* kdiff3
- + Download e Instalação
- + Utilização básica
- + Utilização no **GIT** como `difftool` e/ou `mergetool`
- + screenshots
-
-## Outras interfaces ##
-
-* P4Merge
-
-Citar materiais de referência para instalação e
-utilização.
-
-<!-- Exclui o repositório criado para exemplicação -->
-
-
-[^magit]: http://magit.vc/
diff --git a/cap07.md b/cap07.md
deleted file mode 100644
index 9ccfff39c0e324001451c8dd4b70dafcd1d15954..0000000000000000000000000000000000000000
--- a/cap07.md
+++ /dev/null
@@ -1,338 +0,0 @@
-# Capítulo 7: Trabalhando em equipe
-PET-Estatística UFPR
-
-O Git é uma ferramenta que aliada a outros serviços web, como GitLab ou
-GitHub, oferece funcionalidade e autonomia para se trabalhar.
-Contudo, com tantos recursos disponíveis, só serão bem aplicados quando
-todos os membros do grupo, além de conhecê-los, trabalham em harmonia.
-
-## 1.Boas práticas de colaboração
-
-Repositório é onde são armazenados os arquivos de um projeto. Existem
-três níveis de acesso permitidos:
-
-- **Private**: é o repositório fechado, onde apenas o criador (Owner) tem
-permissão de leitura e escrita. Se um repositório privado for criado
-dentro de um grupo, todos do grupo terão permissão de leitura e escrita.
-
-
-- **Internal**: é o repositório é fechado para usuários externos ao
-grupo, mas qualquer usuário cadastrado no grupo terá permissão de leitura
-e escrita no repositório.
-
-
-- **Public**: é o repositório é aberto para qualquer pessoa, e fica
-visível para qualquer um (usuário do grupo ou não). Usuários do grupo
-tem permissão de leitura e escrita no repositório. Usuários sem conta
-no grupo podem clonar o repositório, mas não tem permissão para alterar
-o repositório (enviar merge requests por exemplo).
-
-É possível adicionar usuários para colaborar em um repositório. Cada
-usuário pode ter um nível de acesso diferente: **Guest**, **Reporter**,
-**Developer**, **Master**. Em <a href="https://gitlab.c3sl.ufpr.br/help/permissions/permissions">
-permissões</a> é possível visualizar as habilidades concedidas para cada
-nível.
-
-Logo após criar um novo repositório, é recomendável que se crie um arquivo
-`README.md`. Independente da forma como o repositório foi configurado,
-é sempre fundamental que ele contenha o arquivo `README.md`.
-Este arquivo é sempre o primeiro a ser mostrado na página inicial
-de todo repositório. Por esse motivo, é importante que o `README.md`
-contenha no mínimo:
-
-- Uma descrição geral do projeto;
-- Os nomes dos autores do projeto;
-- Instruções de instalação, no caso de softwares;
-- A licença do projeto (especialmente para projetos públicos), ou uma
-orientação sobre o uso do projeto (permissão, citação, entre outros).
-Opcionalmente pode-se criar um arquivo *LICENSE* com a licença.
-Esse arquivo ficará disponível também em uma aba na página inicial do
-projeto.
-- (**Opcional**): um guia de contribuição, se o projeto pretende que
-colaboradores externos colaborem e precisam de algumas orientações básicas
-sobre como colaborar. Criando um arquivo `CONTRIBUTING.md` com este guia,
-ele será automaticamente colocado em uma aba na página inicial do projeto.
-- (**Opcional**): um *changelog* para que sejam registradas as modificações
-realizadas entre uma versão e outra (principalmente para softwares).
-Criando esse arquivo com estas informações, ele aparecerá automaticamente
-em uma aba na página inicial do projeto.
-
-Outra parte fundamental do git, são os **commits**. Além de salvarem as
-alterações realizadas nos arquivos, também são responsáveis por documentar
-as alterações feitas por qualquer usuário e em qualquer arquivo.
-Os commits agilizam o processo de revisão do projeto, e poderá ajudar
-futuros mantenedores do projeto a desvendar o motivo de algum acréscimo
-ou modificação no código. Por causa dessas importâncias, uma mensagem bem
-escrita é a melhor forma de se comunicar a alteração para os demais membros
-do grupo e para você mesmo. Essas mensagens também aparecerão no `git log`
-do projeto,por isso é essencial que sejam bem escritas, de forma clara e
-sigam um padrão.
-
-Algumas **regras de ouro**, que são convenções gerais, para que um projeto
-versionado com git seja bem sucedido são:
-
-- **Faça commits regularmente**: isso faz com que as mudanças de código
-entre um commit e outro sejam menores, tornando mais fácil para todos
-acompanhar as alterações;
-
-- **Não faça commits de trabalhos pela metade**: faça um commit apenas
-quando tiver finalizado o que estava propondo. Isso irá forçar você a
-deixar o trabalho em pedaços menores, e por consequência realizar
-commits regularmente;
-
-- **Teste antes de fazer um commit**: resista à tentação de fazer um commit
-que você pensa que está completo. Teste toda a sua realização para
-ter certeza de que não causará um efeito colateral no projeto;
-
-- **Escreva boas mensagens de commit**: seja claro e objetivo ao escrever
-as mensagens de commit. No entanto, tome cuidado para não ser vago, ou
-escrever apenas `mudança`, `mais mudanças`, etc. Se uma mensagem curta for suficiente, use `git commit -m 'Mensagem'`, mas lembre-se de ser
-informativo sobre a alteração realizada, para ser útil para todos do
-projeto.
-
-Existem outras convenções estabelecidas sobre como escrever mensagens
-de commit contextualizadas, baseadas nas mensagens geradas por mensagens
-de funções do próprio git. Estas convenções podem resumidas nas 7 regras
-que são convenções globais:
-
-1.**Separe o título do corpo do texto com uma linha em branco**: por padrão,
-a primeira linha é o título do commit, e deve ser uma mensagem curta.
-Ao deixar uma linha em branco, é permitido escrever uma mensagem de
-qualquer tamanho, detalhando melhor as modificações feitas.
-Dessa forma, quando `git log` for executado, toda a mensagem de commit
-aparecerá, enquanto que `git log --oneline` mostrará apenas o título do
-commit.
-
-2.**Limite a linha de título em 50 caracteres**: isso faz com que o
-colaborador pense mais para escrever uma mensagem mais informativa.
-Se a mensagem for uma única linha (`git commit -m`), então esse limite
-pode se estender para 72 caracteres.
-
-3.**Capitalize a mensagem**: em todas as mensagens de commit comece com
-letra maiúscula, tanto se for título, corpo da mensagem, ou apenas
-uma mensagem de uma única linha.
-
-4.**Não termine os commits com ponto**: principalmente se for o título
-de uma mensagem de commit mais longa. Espaço é valioso quando se temos
-no máximo 50 ou 72 caracteres.
-
-5.**Use o modo imperativo**: no título de commits longos ou em mensagens
-de commits únicas. O modo imperativo significa escrever como se estivesse
-dando um comando a alguém. Seja direto e objetivo, e escreva no presente.
-Exemplos de mensagens no impertativo:
-```sh
-- Adiciona versão final
-
-- Altera parágrafo da introdução
-
-- Remove funções precipitadas
-```
-
-Algumas mensagens no modo **não** imperativo são:
-```sh
-- Corrigindo o erro
-
-- Mudando a função
-
-- Mais correções para mais funções
-```
-
-
-6.**Limite o corpo da mensagem em 72 caracteres**: ao escrever uma mensagem
-de commit mais longa, devemos manter o corpo da mensagem com no máximo
-72 carateres.
-
-
-7.**Use o corpo da mensagem para explicar "o que" e "porque", e não "como"**: contextualize o que você fez e o motivo. Na maioria dos casos você pode
-deixar de fora como você fez as modificações, pois o código alterado já
-deverá ser auto-explicativo.
-
-
-## 2.Modelos de fluxos de trabalho
-
-A escolha do *workflow* (fluxo de trabalho) depende de cada projeto e das preferências pessoais. Podemos utilizar as informações sobre cada *workflow*, e decidir qual é mais adequado para cada projeto. Existem quatro maneiras
-principais de trabalhar em colaboração com o git e o GitLab:
-
-- #### **Centralized workflow**:
-recomendado para projetos pequenos, e/ou que não necessitam de muitas
-alterações. Nesse workflow, o repositório possui apenas um brach (`master`)
-e as alterações são feitas nesse branch. As revisões só poderão ser
-realizadas depois que tudo foi enviado para o servidor remoto. Com isso,
-há uma grande chance de ocorrerem conflitos.
-
-
- **Exemplo**
-
- Após iniciar um repositório central, os colaboradores devem clonar
- o repositório.
-
- 
-
- FIGURA: Colaboradores clonando o repositório central
-
- Depois de um colaborador terminar seu trabalho remotamente, ele
- publica as modificações para o repositório central, para que os
- demais membros possam ter acesso.
-
- 
-
- FIGURA: Colaborador publicando as modificações no repositório central
-
- Outro membro também termina seu trabalho e resolve publicar no
- repositório central, porém não irá conseguir. O repositório central
- está diferente do seu repositório local.
-
- 
-
- FIGURA: Colaborador não conseguindo publicar as modificações no
- repositório central
-
- Para conseguir enviar as modificações realizadas, o colaborador
- precisa puxar as atualizações feitas para o seu repositório,
- integrá-los com as suas alterações locais, e em seguida, tentar
- novamente.
-
- 
-
- FIGURA: Colaborador puxando as modificações do repositório central
-
- Após feito isso, será possível o colaborador fazer as modificações.
-
- 
-
- FIGURA: Colaborador publica modificações do repositório central
-
-- #### **Feature branch workflow**:
-recomendado para projetos pequenos e grandes que envolvam mais de um
-colaborador. O projeto principal é mantido nobranch master. Se um membro
-quiser realizar alguma alteração, deverá criar um novo branch `feature`,
-e fazer as alterações nesse branch e sugerir um `merge request`. Com isso,
-os demais colaboradores poderão revisar as alterações sugeridas e discutir as modificações, até que uma pessoa habilitada faça o merge desse branch
-`freature` para o branch `master`.
-Dessa forma, evita-se os possíveis conflitos e garante que tais alterações
-não causaram algum problema. Esse workflow é altamente recomendado por
-ser simples de gerenciar, evitar grandes conflitos, e ser relativamente
-fácil para usuários novos do git.
-
-
- **Exemplo**
-
- Antes de começar a desenvolver um recurso, é preciso de criar um
- ramo isolado para trabalhar
-
- 
-
- FIGURA: Criando um novo ramo para o trabalho
-
- Com isso, o membro poderá iniciar o seu trabalho, e realizar o que
- for necessário nesse ramo (brach). Após finalizar o projeto, o colaborador
- envia suas modificações, irá requirir um `merge request` para que
- as alterações feitas nesse branch, sejam incorporadas no `master`. Os
- demais membros, poderão avaliar se tais modificações são pertinentes
- para o projeto.
-
- 
-
- FIGURA: Colaborador solicita merge, e aguarda revisão dos demais
- colaboradores
-
- Quando as alterações sugeridas para o colaborador forem incorporadas
- o branch poderá ser movido para o `master`.
-
- 
-
- FIGURA: Movendo ramo para o master
-
-- #### **Gitflow workflow**:
-indicado para projetos maiores e/ou com um grande número de colaboradores.
-Esse workflow envolve a criação de alguns branches com funções específicas.
-Todo o desenvolvimento é realizado no branch `develop`. Quando uma versão
-está pronta, ela é movida para o branch `release`, onde é testada e
-finalmente incorporada ao ramo master, que contém apenas versões finais
-(estáveis). É extremamente recomendado esse workflow para desenvolvimento
-de softwares, porém exige de mais familiaridade com o git. Permite, por
-exemplo, que os usuários de um software, instalem tanto uma versão estável
-(do branch `master`) quanto uma versão em desenvolvimento
-(do branch `develop`).
-
- **Exemplo**
-
- São criados branches com funções específicas, como no exemplo `Hotfix`,
- `Release` e `Develop`.
-
- 
-
- FIGURA: Ilustração dos branches específicos
-
- *Develop* é semelhante ao master do feature branch workflow. *Release*
- serve "lançar" possíveis bugs gerados no código. *Hotfix* contém as
- correções dos bugs do release que não podem aguardar o lançamento
- do mesmo.
-
-
-- #### **Forking workflow**:
-recomendado para projetos abertos, onde se espera usuários externos façam contribuições. Esse workflow consiste de um repositório oficial, de onde
-os colaboradores fazem um `fork` desse repositório, e passam a desenvolver
-o projeto de maneira independente. Assim, cada colaborador poderá adotar
-o workflow de preferência, e não precisará ter acesso ao repositório
-oficial, apenas colaborar enviando `merge`.
-
- **Exemplo**
-
- Criado o repositório central, os colaboradores fazem um `fork`
- poderão trabalhar de maneira independente.
-
- 
-
- FIGURA: Ilustração dos forks de um projeto
-
- Independente da escolha do workflow para cada projeto é importante sempre
-informar o método que está sendo utilizado para seus colaboradores,
-para que eles possam seguir o mesmo padrão. Essas informações poderão ser
-descritas em `README.md` ou no `CONTRIBUTING.md`.
-
-## 3.Fluxo de trabalho PET no GitLab
-
-O PET-Estatística UFPR possui um grupo no Git para o desenvolvimento de
-projetos. Utilizaremos a seguinte ilustração para entender o fluxo do
-trabalho do PET.
-
-(figura que haverá um dia)
-
-FIGURA: Ilustração do fluxo de trabalho do PET
-
-Conforme a demanda de projetos, é criado o repositório para armazená-lo.
-Após isso, são criados as `milestones` - marcadores de
-classificação dos arquivos. Esses passos são feitos no `Owner`.
-
-Indo para o `master`, temos os seguintes passos:
-
-- Conforme a demanda do projeto, é criado um `issue` para adição de
-contribuições;
-- Atualiza o ramo `devel`;
-- Após isso, é necessário criar um `branch` (ramo) para incluir as
-contribuições;
-
-Entrando no `developer`, teremos o ciclo de trabalho em que adiciona
-as modificações (`git add`), registra as mesmas (`git commit`) e após
-realizar todo o trabalho, é feito o `git push` enviando ao
-servidor remoto.
-
-A próxima etapa é a requisição de `merge`. Com esse `merge`, é feita as
-discussões a respeito da contribuição, assim podendo retornar ao ciclo
-do `developer` para as devidas correções e sugestões.
-Após a certeza dessa contribuição, é movida para o ramo `devel` e fechado
-o `issue`referente ao trabalho feito.
-
-Depois de terminar todas etapas do projeto, completa-se as `milestones`,
-realiza o `merge` do `devel` no `master`, e cria a tag de versão.
-
-
-### Referências
-https://git-scm.com/book/pt-br/v1/Git-Distribu%C3%ADdo-Contribuindo-Para-Um-Projeto
-
-https://prezi.com/_lm8kozmii8n/git-workflow/
-
-https://www.atlassian.com/zh/git/workflows\#!workflow-overview
-
-http://git.leg.ufpr.br/leg/gitlab-rautu/blob/master/CONTRIBUTING.md