Corrige ortografia

cap05.Rmd

@@ -26,9 +26,9 @@ discussão. Para que um desenvolvedor saiba o que os outros fizeram, ele
 terá que periodicamente dar `fetch`, navegar no histórico, ver *diffs*,
 etc.
 
-O Git tem muitos serviços web voltados justamente para ter um local que
-centralize o projeto bem como ofereça recursos administrativos e
-colaborativos. Esses serviços possuem contas *free* etc...
+O Git tem vários serviços web voltados para ter um local que centralize 
+o projeto bem como ofereça recursos administrativos ecolaborativos. 
+Esses serviços possuem contas *free*, entre outros.
 
 O objetivo desse capítulo é apresentar os serviços web para repositórios
 Git, descrever suas principais características, indicar como criar e
@@ -42,8 +42,8 @@ as funcinalides desses serviçõs voltados à colaboração.
 
 O [GitHub] é um serviço Web para hospedagem, gestão e compartilhamento
 de repositórios Git que oferece recursos para desenvolvimento e
-colaboração. A principal slogam do GitHub é: *"Build software better,
-together."* que justamente enfatiza o compromisso principal que é dar
+colaboração. O principal slogam do GitHub é: *"Build software better,
+together."* que justamente enfatiza o principal compromisso que é dar
 suporte ao desenvolvimento colaborativo.
 
 O GitHub foi fundado em 8 de Fevereiro de 2008, em São Francisco, por
@@ -55,15 +55,15 @@ trimestre de 2014 haviam 22 milhões de repositórios. A linguagem
 total de *pushes* enquanto que a linguagem `R` foi a com maior número de
 novas cópias por repositório (6.45).
 
-Diferente da forma tradicional de usar o Git, por linha de comando, que
-fizemos até agora, o GitHub é um serviço web com interface gráfica
-repleta de funções para o desenvolvimento e acompanhamento de um projeto
-Git. Tais recursos vão desde administrar tarefas até a permitir a
-colaboração de outras pessoas, até mesmo desconhecidos. Dentre os
-principais recursos disponíveis, tem-se:
+Diferente da forma tradicional de usar o Git por linha de comando, o GitHub 
+é um serviço web com interface gráfica repleta de funções para o 
+desenvolvimento e acompanhamento de um projeto Git. Tais recursos vão 
+desde administrar tarefas até permitir a colaboração de outras pessoas, 
+mesmo sendo desconhecidos. Dentre os principais recursos disponíveis, 
+tem-se:
 
   * README: é um arquivo texto escrito em liguagem de marcação
-    (Markdown, RST, Textile, Org, etc) que é renderizada para
+    (Markdown, RST, Textile, Org, etc) no qual é renderizada para
     exibição. O README é a capa do seu repositório, ou seja, o conteúdo
     apresentado na *home* do projeto e serve para informar o visitante
     dos objetivos do repositório, seus desenvolvedores e pode conter
@@ -71,12 +71,12 @@ principais recursos disponíveis, tem-se:
   * Wiki: a Wiki de cada repositório serve para divulgação e
     documentação. Também é escrita em linguagem de marcação, tornando
     fácil e rápido a escrita pelo desenvolvedor e simples a leitura e a
-    navegação pelo visitante. Como a Wiki é também um repositório Git,
+    navegação pelo visitante. Como a Wiki é um repositório Git,
     ela pode inclusive ser editada por meios dos recursos de edição do
-    prórpio GitHub, além de versionada, claro. Com isso, não diferente
+    próprio GitHub, além de ser versionada. Com isso, não diferente
     do restante, a edição da Wiki também é colaborativa.
-  * *Issues*: Por *issues* é que se faz a correção de bugs e agendamento
-    de tarefas. Usuários criam *issues* para notificar um bug encontrado
+  * *Issues*: Pelos *issues* é que se faz a correção de bugs e agendamento
+    de tarefas. Os usuários criam *issues* para notificar um bug encontrado
     de forma que ele possa ser rapidamente corrigido. Criar *issues*
     também serve como ferramenta de admistração de tarefas nas quais os
     *issues* descrevem algo a ser feito e por quem.
@@ -86,9 +86,9 @@ principais recursos disponíveis, tem-se:
     prazo para conclusão, por exemplo.
   * *Pull request* ou *merge request* (MR): é uma requisição de
     fusão. Os membros da equipe fazem suas contribuições em ramos de
-    desenvolvimento e ao concluir pedem um MR pela interface. O
+    desenvolvimento e ao concluir, pedem um MR pela interface. O
     responsável por avaliar o MR pode ver os *diffs* nos arquivos e
-    fazer o merge direto pela interfaçe, de dentro do serviço sem
+    fazer o merge direto pela interface, de dentro do serviço sem
     precisar baixar o ramo, aplicar o merge e subí-lo.
   * *Fork*: é uma forma de se fazer uma cópia do projeto de alguém para
     livremente experimentar modificações sem afetar o projeto
@@ -100,8 +100,8 @@ principais recursos disponíveis, tem-se:
 
 De acordo com [Klint Finley], *fork* e MR são o que tornam o GitHub tão
 poderoso. Quando o mantenedor recebe um MR ele pode ver o perfil do
-contribuidor onde estão listados todos os projetos no qual este deu
-contribuição. Ao aceitar o MR, é acrescentado mais uma colaboração a
+contribuidor onde estão listados todos os projetos no qual este
+contribuiu. Ao aceitar o MR, é acrescentado mais uma colaboração a
 reputação do colaborador. Esse mecanísmo, então, beneficia as duas
 partes.
 
@@ -118,8 +118,8 @@ ver as modificações no código (*diffs*) comaprando *commits* e
 O GitHub não hospeda apenas código fonte mas sim todo e qualquer arquivo
 que você tenha sob versionamento. É possível hospedar dados, por
 exemplo, em formato texto (csv), e disponibilizá-los por meio da URL
-para download ou leitura direta. Para nós que somos usuários de R, essa
-é uma característica que permite não só disponibilizar dados, mas também
+para download ou leitura direta. Para usuários de R, essa é uma 
+característica que permite não apenas disponibilizar dados, mas também
 coleções de funções que podem ser carregadas com um `source()`.
 
 Com o plano *free* do GitHub, você pode ter inúmeros repositórios
@@ -129,8 +129,8 @@ ter repositórios privados, o plano mais básico custa U$ 7 e dá direito a
 5 repositórios. Existem outros planos individuais, e também planos
 organizacionais, para todos os tamanhos de projeto e equipe. Além dessas
 formas, pode-se ter o GitHub em um servidor próprio, o
-[GitHub Interprise], que tem vantagens além das já mencionadas, no
-entanto, tal como qualquer plano privado, tem seu custo.
+[GitHub Interprise], que tem suas vantagens além das já mencionadas, e 
+terá seu custo como qualquer plano privado.
 
 É uma fonte de conhecimento onde você encontra *scripts* nas mais
 diferentes linguagens de programação. Você pode livremente estudar o
@@ -143,10 +143,10 @@ JSON, SQL, XML, csv) e aplica os realces (highlights) que facilitam a
 leitura do código.
 
 O GitHub é o serviço web para Git mais popular quanto ao número de
-projetos hospedados. No entanto, existem serviços com as mesmas e até
-com funcionalidades que o GiHub não oferece no plano básico. O GitLab e
-o Bitbucket estão entre os 5 mais populares e permitem, por exemplo, ter
-alguns repositórios privados com a conta *free*.
+projetos hospedados. No entanto, existem serviços com as mesmas 
+funcionalidades e até com outras que o GiHub não oferece no plano básico. 
+O GitLab e o Bitbucket estão entre os 5 mais populares e permitem, 
+por exemplo, ter alguns repositórios privados com a conta *free*.
 
 ## GitLab ##
 
@@ -156,16 +156,16 @@ FIGURA O guaxinim (*raccoon* em inglês) é o macote do GitLab.
 
 Assim como o GitHub, o [GitLab] é um serviço Web para repositórios
 Git. O GitLab é um projeto *open source* desenvolvido em Ruby que deu
-início em 2011 pelo Ucrâniano Dmitriy Zaporozhets. Em 2013, a Companhia
+início em 2011 pelo ucrâniano Dmitriy Zaporozhets. Em 2013, a Companhia
 GitLab tinha 11 membros e mais de 10 mil organizações.
 
-O GitLab, além de ser um serviço gratuíto (com planos extras)
+O GitLab, além de ser um serviço gratuito (com planos extras)
 colaboração, é também um programa que você pode instalar em servidor
 local para ter seus repositórios na intraweb, se for o caso.
 
 Como serviço web, o GitLab oferece basicamente todos os recursos do
-GitHub e do BitBucket [^1]. No entanto, com uma conta gratuíta no
-<http://gitlab.com> você pode ter, além dos repositórios públicos e
+GitHub e do BitBucket [^1]. No entanto, com uma conta gratuita no
+<http://gitlab.com> você pode ter, os repositórios públicos e
 colaboradores, ilimitados repositórios privados sem pagar por nada. Isso
 faz do GitLab.com o lugar certo para pequenas equipes com pouco recurso
 ou que desenvolvem trabalhos sem fins lucrativos, como é o caso de
@@ -175,11 +175,11 @@ Atualmente existem mais de 69 mil projetos públicos e 5840 grupos
 abertos no GitLab.com (https://gitlab.com/explore)
 
 A versão paga do GitLab, a *Enterprise Edition* (EE), tem um preço
-muitas vezes menor que a equivalente do GitHub.
+menor que a equivalente do GitHub.
 
-A versão gratuíta do GitLab para servidores, a *Community Edition* (CE),
-pode ser instalada em servidores Linux, Windows, máquinas vituais e
-servidores na núvem, além de outras opções. Os serviços
+A versão gratuita do GitLab para servidores, a *Community Edition* (CE),
+pode ser instalada em servidores Linux, Windows, máquinas virtuais e
+servidores na nuvem, além de outras opções. Os serviços
 <https://gitlab.c3sl.ufpr.br/explore> e <http://git.leg.ufpr.br/explore>
 são o GitLab CE para servidores rodando no C3SL (Centro de Computação
 Científica e Software Livre) e LEG (Laboratório de Estatística e
@@ -187,11 +187,11 @@ Geoinformação). Estes serviços dão suporte à colaboração em código
 dentro dos departamentos de Informática e Estatística para alunos e
 professores (C3SL) e para a equipe e colaboradores do LEG (LEG).
 
-Em termos finaceiros, vale mais a pena pagar por um servidor na núvem da
+Em termos finaceiros, vale mais a pena pagar por um servidor na nuvem da
 [Digital Ocean] com o GitLab CE (U$ 5/mês) do que ter uma conta para
-repositórios privados no GitHub (U$ 7/mes por 5 repositórios
+repositórios privados no GitHub (U$ 7/mês) por 5 repositórios
 privados). No entanto, conforme já mencionamos, pequenas equipes podem
-ter repositórios privados na conta gratuíta do GitLab.com.
+ter repositórios privados na conta gratuita do GitLab.com.
 
 Além das características essenciais ou comuns aos demais serviços, como
 *issues*, *fork*, *merge requests*, *wiki* e *snippets*, o
@@ -206,7 +206,7 @@ adição de *web hooks*.
 
 # Criar um perfil #
 
-Criar uma conta no Github é tão simples como uma conta de email ou de
+Criar uma conta no Github é tão simples como uma conta de email ou numa
 rede social. Acesse o endereço <https://github.com/join> para preencher
 seus dados pessoais e escolher um plano. Nenhum dos planos tem limitação
 quanto ao número de repositórios ou colaboradores. O que muda é a
@@ -219,7 +219,7 @@ Ao preencher o formulário de criação de conta, você receberá um email
 com uma ulr de ativação. Se optar por planos pagos, terá informar número
 do cartão de crédito para que seja feito o pagamento mensalmente.
 
-Para criar uma conta gratuíta no GitLab, acesse
+Para criar uma conta gratuita no GitLab, acesse 
 <https://gitlab.com/users/sign_in>. Os serviços GitLab que usamos são
 instalações em servidoras próprias (do C3SL e do LEG), no entanto, a
 interface do usuário é a mesma, com excessão de alguns privilégios
@@ -284,6 +284,7 @@ No GitLab, o cadastro de chaves públicas é um processo semelhante. Uma
 vez autenticado, acesse <https://gitlab.c3sl.ufpr.br/profile/keys> para
 adicionar chaves públicas.  Para testar a comunição entre o GitHub e a
 sua máquina, execute:
+
 ```{r, engine="bash", eval=FALSE}
 ## Testa comunição. Retorna um "Welcome!" em caso positivo.
 ssh -T git@gitlab.c3sl.ufpr.br
@@ -317,18 +318,17 @@ permitem repositórios públicos.
 FIGURA XXX: Janela para a criação de um novo repositório no GitHub.
 
 Para criar o projeto dentro de uma Organização, selecione a Organização
-na *drop list* que fica no no campo Owner, a esquerda do campo para o
+na *drop list* que fica no campo Owner, a esquerda do campo para o
 nome do repositório.
 
 Você pode inicilizar o repositório com um arquivo `README.md`, o que é
 altamente recomendado. Como já mencionamos, esse arquivo é a capa do seu
-repositório e serve para documentar o seu objetivo, formas de
-colaboração, colaboradores, formas de instalação do software, caso seja
-um.
+repositório e serve para documentar o seu objetivo, formas de colaboração, colaboradores, formas de instalação do software, caso seja um informativo
+do projeto.
 
 Você pode editar o arquivo `README.md` (ou qualquer outro) no GitHub. As
 moficações que fizer devem ser *commitadas* para serem salvas. O arquivo
-de `README.md`, que é linguagem de marcação MarkDown, é automaticamente
+`README.md`, que é linguagem de marcação MarkDown, é automaticamente
 renderizado pelo GitHub fazendo com que urls sejam clicáveis e códigos
 estejam em ambientes de fonto monoespaço, além de ter títulos com
 tamanho de fonte apropriado e as demais renderizações.
@@ -344,7 +344,7 @@ git clone git@github.com:fulano/ola-mundo.git
 ```
 
 Pode-se clonar repositórios pelo protocolo `http` (*Hypertext Transfer
-Protocol*) também. Em geral, para clonar repositórios de outros usuários
+Protocol*). Em geral, para clonar repositórios de outros usuários
 e fazer testes, usa-se `http`. Embora você possa usar `http` nos seus
 repositórios, prefira o *SSH*. Com `http`, o endereço para a ser:
 
@@ -379,7 +379,7 @@ git push -u origin master
 
 O seu projeto é configurado em
 <https://github.com/walmes/emacs/settings/>. Para renomear, deletar ou
-trasferir o projeto para outro usuário ou organização, vá em
+transferir o projeto para outro usuário ou organização, vá em
 *Options*. Em *Collaborators* você administra os colaboradores do
 projeto. Para genrenciar os ramos de trabalho, como proteger ou remover
 ramos, vá em *Branches*. O uso de de serviços web é configurado no
@@ -388,7 +388,7 @@ públicas.
 
 ![](./images/github_repo_home.png)
 
-Vamos considerar um repositório de bastante atividade para conhecermos
+Vamos considerar um repositório com várias atividades para conhecermos
 um pouco mais dos recursos do GitHub. O repositório
 <https://github.com/yihui/knitr> é o sítio de desenvolvimento do pacote
 `knitr` do R, o principal pacote para a geração de relatórios
@@ -402,7 +402,7 @@ Na figura XXX, logo abaixo do título, tem-se quatro quantificadores:
   * *branches*: este lista os *branches* do projeto, permite comparar
     ramos.
   * *releases*: documenta as modificações de uma versão para outra e
-    lista os *commits* que tem *tags*. Essa é uma fonte importate.
+    lista os *commits* que tem *tags*. Essa é uma fonte importante.
   * *contributors*: dá um resumo das atividades dos colaboradores do
     projeto. Na aba *members* tem-se uma lista de todos os usuários que
     fizeram o *fork* do seu projeto. Falaremos de *fork* adiante.
@@ -424,7 +424,7 @@ No menu da direita existem links para acessos a mais coisas:
     mescla. Nesta página pode submeter uma requisição e navegar nas
     existentes.
   * wiki: na Wiki de um repositório normalmente é feita uma documentação
-    mais detalhada do projeto. Páginas Wiki de um repositório são também
+    mais detalhada do projeto. Páginas Wiki de um repositório também são
     repositórios Git, portanto, versionáveis.
   * pulse: dá um resumo sobre s quantidade issues presentes, fechados e
     abertos bem como para requisções de mescla. Mostra também um resumo
@@ -434,7 +434,7 @@ No menu da direita existem links para acessos a mais coisas:
     maior colaboração, etc.
 
 Existem ainda mais coisas sobre o GitHub que não podemos deixar de
-comentar que são os recursos disníveis para colaboração. Nas sessões à
+comentar que são os recursos disponíveis para colaboração. Nas sessões à
 frente, trataremos do recurso de *fork*, *issue* e requisições de
 mescla. Antes, no entanto, vamos conhecer um pouco GitLab, um serviço
 web para projetos Git que pode ser instalado no seu servidor.
@@ -442,29 +442,29 @@ web para projetos Git que pode ser instalado no seu servidor.
 O GitLab é o serviço que nós do PET usamos para colaboração em nossos
 projetos. Além disso, é o que os alunos usam para fazerem seus trabalhos
 e desenvolverem o TCC. O uso do Git como ferramenta de trabalho passou
-ser estimulado nesse semestre (2015/2).
+ser estimulado no segundo semestre de 2015.
 
 **GitLab**
 
 Basicamente, o GitLab tem os mesmos recursos, só estão organizados de
 forma diferente.
 
-O GitLab concentra os acessos à outras páginas em um meno do lado
+O GitLab concentra os acessos à outras páginas em um menu do lado
 esquerdo. Do lado direito pode haver informações extras. O botão para
-criar um novo repositório fica no canto superior direit. Ao lado deste
+criar um novo repositório fica no canto superior direito. Ao lado deste
 tem botões para ir para página de configurações, sair, ajuda e explorar
 o GitLab.
 
 No menu da direita tem-se acesso aos projetos do usuário, ao projetos
-favoritos e aos grupos que parcipa. As extradas *Milestones*, *Issues* e
+favoritos e aos grupos que participa. As extras, *Milestones*, *Issues* e
 *Merge request* reúnem as informações sobre todos os projetos do qual o
 usuário participa.
 
-Assim como acontece com outros serviços web, na página inical do projeto
+Assim como acontece com outros serviços web, na página inicial do projeto
 é exibido o arquivo de capa, o `README.md`. Centralizado na página
 encontra-se o endereço para clonar o repositório por SSH ou HTTPS. No
-menu da direita estão as principais informações sobre o
-projeto. *Project* é a página inicial; *Activity* e *Commits* listam a
+menu da direita estão as principais informações sobre o projeto. 
+*Project* é a página inicial; *Activity* e *Commits* listam a
 atividade (predominantemente *commits*); *Files* apresenta diretórios e
 arquivos com opção de mudar o ramo. *Network* o estado de
 desenvolvimento dos ramos do projeto com uma lista de todos os
@@ -476,7 +476,7 @@ requisições de mescla; *Members* faz a gestão da equipe de trabalho como
 adição e redefinição dos níveis de acesso; *Labels* são usados para
 classificar os *issues* - é comum usar *bug*, *fix*, *review*. *Wiki*
 vai para a página Wiki do repositório, útil para divulgação e
-documentação; Finalmente, em *Settings* são feitas as configurações
+documentação. Finalmente, em *Settings* são feitas as configurações
 gerais do projeto como definição de nome, descrição, nível de
 visibilidade e adição e *Web Hooks*. Nessa mesma página pode-se
 renomear, transferir ou remover o projeto.
@@ -527,7 +527,7 @@ tarefas. Combinado com as *milestones*, cada membro cria um *issue*
 correspondente ao que vai fazer no projeto no período de uma semana. Com
 isso, todos os demais membros são notificados de que alguém já vai
 trabalhar na tarefa A do projeto, eliminando foco duplicado. O *issue* é
-parte do fluxo de trabalho do PET Estatística que será descrito em outro
+parte do fluxo de trabalho do PET-Estatística que será descrito em outro
 capítulo.
 
 As *milestones* são uma espécie de coleção de *issues* que tenham algo
@@ -551,7 +551,7 @@ serviços web até tem formas de fazer *hiperlinks* facilmente para os
 
 A palavra *fork*, como substantivo, representa forquilha,
 bifurcação. Como verbo, representa bifurcar. Esse recurso está presente
-nas interfaces web para permitir que usuários facam cópias livres de
+nas interfaces web para permitir que usuários façam cópias livres de
 projetos de outras pessoas. Como essa cópia é do projeto em determinado
 instante, há grande chance de divergência entre cópia e original a
 partir desse instante, por isso é apropriado a palavra bifurcamento.
@@ -621,14 +621,14 @@ git push origin issue#33
 ```
 
 Na interface web, o membro faz um *merge request* desse ramo para um
-ramo permamente, que em projetos simples é o *master* mas em projetos
+ramo permamente, no qual em projetos simples é o *master* mas em projetos
 maiores é usualmente o *devel*.
 
 Em ambos os serviços, o *merge resquest* leva para um página na qual
 você escolhe que ramo de demanda (doador) será incorporado a um ramo
 permamente (receptor). Ao confirmar os ramos envolvidos, tem-se uma
-caixa de texto destinada as informações sobre o que as modificações a
-serem incorporadas. Elas servem para justificar, esclarecer e informar o
+caixa de texto destinada as informações sobre quais as modificações devem
+ser incorporadas. Elas servem para justificar, esclarecer e informar o
 responsável pelo *merge* sobre a incorporação. Quando o projeto é
 coletivo e não individual, um membro pode ser indicado como responsável
 pelo *merge*.
@@ -646,11 +646,11 @@ ou 2) incorporar ao *master* do original. Outra opção é incorporar ao
 para o *master* do original. Essa última é útil quando a quantidade de
 modificações é maior e portanto, o trabalho vai levar mais tempo.
 
-O próprio serviço Web tem recurso para a apliação do *merge* sem
+O próprio serviço Web tem recurso para a aplicação do *merge* sem
 precisar copiar os ramos envolvidos. Isso facilita bastante o
 trabalho. Porém, não haver conflito de *merge* não significa que as
 modificações incorparadas estão funcionais, ou seja, as modificações
-feitas precisam ser testadas localmente para verificar de tiveram
+feitas precisam ser testadas localmente para verificar surgiram
 efeito. É possível habilitar o serviço Git para checar se o projeto é
 executável, em caso de softwares. Esse recurso se chama intergração
 contínua e veremos na próxima sessão.
@@ -664,9 +664,9 @@ que já reconheçe que o *merge* foi feito e fecha a requisição.
 
 Recomenda-se que os ramos de demanda sejam removidos após a incorporação
 nos ramos permanentes. Isso torna o projeto mais claro e concentrado em
-ramos definitivos colhedores de desenvolvimento. Pode-se exluir o ramo
+ramos definitivos colhedores de desenvolvimento. Pode-se excluir o ramo
 de demanda incorporado direto pela interface. Por linha de comando
-também é possível
+também é possível.
 
 ```{r, engine="bash", eval=FALSE}
 ## Deleta o branch issue#33 no servidor (origin).