Merge branch 'issue#7' into devel

Conflicts: .gitignore

Merge branch 'issue#7' into devel
07c90afe · Eduardo E. R. Junior · 36a26c19 · 7496bd06 · 07c90afe · 07c90afe
Commit 07c90afe authored 9 years ago by Eduardo E. R. Junior
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
 Guia de contribuição
 ====================
 Esse é um projeto público do PET Estatística aberto a
 colaboradores. Para que a colaboração seja bem sucedida, seguem algumas
 intruções e recomendações.
 ## O funcionamento
 O núcleo do tutorial é o arquivo `git_tuto.Rmd`. O arquivo `Rmd` é
 marcado por ser escrito com sintaxe [markdown][] com fragmentos de
 código R. Os fragmentos de código R são interpretados durante a
 compilação feita com a função `render` do pacote [rmarkdown][]. Por ser
 escrito em markdown, o tutorial pode ser compilado em formatos como markdown (`.md`), html e PDF.
 Apesar de `Rmd` normalmente ter fragmentos de código R, nesse tutorial
 predominam fragmentos de código shell, em outras palavras, são
 fragmentos de código executados do terminal do Linux. Para ter um
 fragmento de código shell que seja interpretado na compilação, tem-se
 que fazê-lo conforme abaixo.
    ```{r, engine="sh"}
    comando shell
    ```
 A compilação desse documento cria sempre um projeto Git do zero. Com
 intruções do shell ao longo do documento, no instante da compilação,
 arquivos são criados, adicionados (`git add`), commitados (`git
 commit`), moficados, etc. Esse documento é, portanto, um documento
 reproduzível.
 Para compilar o documento você deve abrir uma sessão R onde o diretório
 de trabalho é o que contém o arquivo `git_tuto.Rmd` e rodar uma chamada
 da função render. Usuários do RStudio podem fazer isso diretamente pelo
 botão de compilar, presente na barra de ferramentas.
    ```{r, engine="sh"}
    library(rmarkdown)
    render("git_tuto.Rmd")
    ```
 Os diretórios criados durante a compilação são sempre apagados, para que ao
 compilar novamente, tudo seja reproduzido. O projeto deve recriar tudo e
 é essa a intenção, apesar do custo. Se os diretórios não fossem
 deletados antes de uma nova compilação, iria-se receber erros de
 compilação.
 Esse documento usa instruções no terminal que podem ser particulares do
 Linux, como o comando `tree` e `sed`. Portando, a reprodutibilidade da
 compilação pode não acontecer em outros sistemas operacionais.
 ## O fluxo de trabalho
 Esse projeto terá dois ramos persistentes:
  * `devel`: que irá receber imediatamente a contribuição dos
    membros e será submetido a teste (no caso compilação). Se bem
    sucedido, a contribuição é movida para o ramo `master`.
  * `master`: que recebe a versão estável do projeto.
 Os membros devem criar ramos de demanda para adicionarem suas
 contribuições. Por exemplo, se existe a demanda (*issue*) de acrescentar uma
 sessão sobre o uso do programa `meld` para resolver conflitos de merge,
 deve-se criar um ramo para isso, adicionar as contribuições e subir esse
 ramo para o repositório remoto. Os *issues* criados no GitLab são
 automaticamente numerados. Para nosso benefício, vamos usar o mesmo
 número ao criar os *branches* para atender as correspondentes
 demandas. Vamos usar o padrão `issue#?` em que `?` representa o número
 do *issue*.
 ```sh
 git branch -b issue#3
 ... trabalha, git add, git commit ...
 ... trabalha, git add, git commit ...
 ... trabalha, git add, git commit ...
 git push origin issue#3
 ```
 Assim que der o `git push`, a próxima etapa é fazer uma requisição de
 *merge*. Isso se faz pela interface do GitLab clicando em
 [merge request][] no menu da esquerda, dentro da página do projeto, e
 depois no botão *New Merge Request*. Lá é onde se designa o responsável
 por avaliar e aplicar o *merge* e quais os *branches* envolvidos
 (doador/receptor).
 Existe apenas uma regra que jamais deve ser quebrada:
 > Nunca dê `push` para os ramos `devel` e `master`.
 Esses ramos se receberão conteúdo provenientes de *merge* dos ramos de
 demanda (*issue*).
 ## Mensagens de commit
 É extremamente recomendado, por questões de organização e produtividade,
 que as mensagens de commit sejam apropriadas. Não use mensagens vagas ou
 óbvias do tipo *Modificações feitas*, *Arquivos incluídos*. Procure algo
 como *Incluí arquivo de estilo CSS*, *Modifica preâmbulo*, *Troca
 'require' por 'library'* ([5 dicas para melhores commits][]).
 Exitem formas especiais de escrever um *commit* que tenha ações do
 repositório remoto como fechar um *issue* ou fazer uma referência a
 outro *commit* ([ações nas mensagens de commit][]). As palavras
 especiais são: `close`, `closes`, `closed`, `fix`, `fixes`, `fixed`,
 `resolve`, `resolves`, `resolved`. Depois das palavras vem uma
 identificação de *issue* ou *sha1*.
 ```sh
 git commit -m "Close #4. Bug devido ao encoding."
 ```
 Visite para mais dicas de como escrever um *commit*:
 [como-escrever-boas-mensagens-de-commit][]
 ## Escrita do código
 Recomensa-se fortemente que ao escrever o código, não se ultrapasse 72
 caracteres por linha. Isso torna o texto/código mais legível nos
 arquivos fontes. Linhas longas são difíceis de ler nos monitores atuais, 
 que possuem uma tela grande.
 Editores de texto (de verdade) geralmente possuem formas de auto quebrar
 linhas, auto indentar/acomodar ou sinalizar a margem direita. O Emacs
 tem [auto break lines][] e [refluxo de texto][]. Outros editores
 permitem exibir uma linha vertical para indicar o limite, como o RStudio
 (> Tools > Global Options > Code > Display > Margin column).
 [markdown]: http://br-mac.org/2013/09/o-que-e-markdown.html
 [rmarkdown]: http://rmarkdown.rstudio.com/
 [merge request]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/merge_requests
 [ações nas mensagens de commit]: https://help.github.com/articles/closing-issues-via-commit-messages/
 [5 dicas para melhores commits]: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
 [auto break lines]: http://emacswiki.org/emacs/LineWrap
 [refluxo de texto]: http://www.emacswiki.org/emacs/FillParagraph
 [como-escrever-boas-mensagens-de-commit]: http://blog.diovani.com/post/101092814586/como-escrever-boas-mensagens-de-commit
--- a/README.md
+++ b/README.md
 Tutorial de Git
 ===============
 O [Git][] é um sistema de controle de versão distribuído cuja finalidade
 é permitir que muitas pessoas colaborem no mesmo projeto facilmente
 "juntando" as contribuições dos membros e incorporando ao projeto com o
 mínimo de esforço possível.
 Esse projeto tem a finalidade de aprofundar o conhecimento do Git e
 documentar tal aprendizado em uma apostila que seja útil tanto para
 iniciantes quanto para usuários intermediários.
 O projeto é desenvolvido no serviço GitLab do C3SL e acessado pelo link:
 <https://gitlab.c3sl.ufpr.br/pet-estatistica/apostila-git>
 Todas as contribuições ao projeto são bem vindas, tanto por meio de
 [issue][] quando por *fork*.
 **PET Estatística UFPR**
  * [Alessandra Zeizer Dimas](https://gitlab.c3sl.ufpr.br/u/pazd11)
  * [Ângela Luiza Cunha Legey](https://gitlab.c3sl.ufpr.br/u/alcl12)
  * [Daniel Ikenaga](https://gitlab.c3sl.ufpr.br/u/di12)
  * [Eduardo Elias Ribeiro Junior](https://gitlab.c3sl.ufpr.br/u/eerj12)
  * [Gabriel Sartori Klostermann](https://gitlab.c3sl.ufpr.br/u/gsk12)
  * [Jhenifer Caetano Veloso](https://gitlab.c3sl.ufpr.br/u/jcv13)
 [Git]: https://git-scm.com/book/pt-br/v1/Primeiros-passos-No%C3%A7%C3%B5es-B%C3%A1sicas-de-Git
 [issue]: https://gitlab.c3sl.ufpr.br/pet-estatistica/git-tutorial/issues
\ No newline at end of file
--- a/git_tuto.Rmd
+++ b/git_tuto.Rmd
@@ -4,9 +4,11 @@ author: "PET Estatística UFPR"
 output:
  html_document:
    highlight: pygments
-    toc: true
+    keep_md: yes
    theme: flatly
-    keep_md: true
+    toc: yes
+  pdf_document:
+    toc: yes
 ---
 ```{r, include=FALSE}
@@ -1840,6 +1842,103 @@ opts_chunk$set(eval=FALSE)
 ****
 ## Ignorando arquivos e diretórios
+Há momentos em que é necessário a criação de arquivos e pastas, dentro do 
+repositório git, que não devem ser versionados, como é o caso de uma 
+compilação Latex, que gera arquivos auxiliares que não é preciso deixar 
+disponível a terceiros. Para esse intuito, o git possui um recurso que permite
+que arquivos e pastas fiquem "invisíveis" para o software.
+Para que isso ocorra, é indispensável a criação de um arquivo com extensão 
+`.gitignore`, que o git irá reconhecer e efetuar leitura a procura de 
+pastas e arquivos a ignorar. Dentro deste arquivo, é imprescindível que seja
+escrito, por linha, somente um nome de pasta ou arquivo a ser ignorado.
+### Padrões de formatos para o `.gitignore`
+* Linhas em branco não são lidas, servindo apenas como modo de separar e 
+organizar o arquivo.
+* Os caracteres ` # ` e ` ! ` são reservado do git. Para pastas ou arquivos
+que os nomes comecem com ` # ` (Exemplo: #git.txt) ou ` ! ` (Exemplo: !git.txt), 
+deve-se usar uma barra invertida na frente do padrão (Exemplo: \\#ddd.txt, \\!ddd.txt).
+* O caracter ` # ` serve para efetuar comentários, ou seja, a linha que iniciar com `#`
+não será interpretada pelo git.
+* O caracter `!` serve para negar um padrão, por exemplo, pode-se mandar o git 
+ignorar todos os arquivos de determinada pasta (Usando: Nome_Dir/*),
+mas deixar de ignorar um arquivo específico dentro dela 
+(Exemplo: !Nome_Dir/Arquivo.txt).
+* O asterisco ` * ` pode ser usado para substituir parte do nome de 
+arquivos e pastas, ou o nome inteiro. Isso é valido também para a 
+extensão do arquivo.
+* Um diretório pode ser ignorado adicionando seu nome e uma barra ao final deste.
+* Dois asteriscos ` ** ` podem ser usados para substituir caminhos de subpastas, 
+como por exemplo, para ignorar o diretório Subpasta, 
+o caminho `/Exercicio/Teste/Pasta/Subpasta/` pode ser substituido por `/**/Subpasta/`.
+### Exemplo
+O código abaixo é um exemplo de um arquivo com extensão `.gitignore`:
+```{r, engine="sh", eval=FALSE}
+# Esta linha é um comentário.
+# Ignorando arquivos com extensão .aux menos o arquivo EXEMPLO.aux:
+*.aux
+!EXEMPLO.aux
+# Ignorando todos os arquivos com nome EXEMPLO:
+EXEMPLO.*
+# Ignorando arquivos que possuam HTML no nome:
+HTML*.*
+# Ignorando as Subpastas e os arquivos da pasta DIR:
+DIR/*
+# Não ignorar apenas a Subpasta1 da pasta DIR:
+!DIR/Subpasta1/
+```
+Vale ressaltar que, no exemplo acima, por mais que esteja sendo ignorado arquivos 
+com o nome EXEMPLO, e arquivos com extensão .aux, 
+o arquivo EXEMPLO.aux (que está pecedido do sinal `!`) não será ignorado.
+### Tornando Global
+Cada vez que cria-se um novo projeto, para que arquivos sejam ignorados, 
+deve-se criar um novo arquivo `.gitignore`. Para que isso não ocorra, e 
+possível configurar o arquivo globalmente, ou seja, ele estará incorporado
+as configurações do git do seu computador.
+```{r, engine="sh", eval=FALSE}
+git config --global core.excludesfile ~/.gitignore_global
+```
+ Depois de executar o código acima, o `.gitignore` da pasta atual 
+ (pasta do seu projeto) será atribuido como global no arquivo de 
+ configuração do git (`.gitconfig`).
+ Uma observação importante a ser feita é que, se adicionado arquivos para
+ serem ignorados globalmente, como arquivos PDF (Usando: *.pdf), por exemplo,
+ todos os arquivos  com essa extensão serão ignorados pelo git,
+ não somente os do projeto atual. 
+ Portanto, é recomendado somente definir um `.gitignore` como global, 
+ se ele apenas desconsiderar arquivos auxiliares, ou seja, que não serão necessários
+ para compilações futuras.
 ****
 ## Autenticando em contas do GitLab (c3sl) e GitHub

--- a/git_tuto.md
+++ b/git_tuto.md