diff --git a/cap05.Rmd b/cap05.Rmd
index aa20608d07be7bd79fd68a0c2d6ae7020254bc5b..049812dba810ac380edfdaa4e8663036a9a68deb 100644
--- a/cap05.Rmd
+++ b/cap05.Rmd
@@ -32,9 +32,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
@@ -53,8 +53,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
@@ -66,15 +66,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
@@ -82,12 +82,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.
@@ -97,9 +97,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
@@ -111,8 +111,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.
@@ -129,8 +129,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
@@ -140,8 +140,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
@@ -154,10 +154,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 ##
@@ -170,16 +170,16 @@ alguns repositórios privados com a conta *free*.
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
@@ -189,11 +189,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
@@ -201,11 +201,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
@@ -220,7 +220,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
@@ -233,7 +233,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
@@ -302,6 +302,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
@@ -338,18 +339,17 @@ permitem repositórios públicos.
\end{figure}
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.
@@ -365,7 +365,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:
@@ -399,8 +399,8 @@ 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
+<https://github.com/walmes/emacs/settings/>. Para renomear, deletar ou
+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
@@ -415,7 +415,7 @@ públicas.
\label{github_repo_home}
\end{figure}
-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
@@ -430,7 +430,7 @@ 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.
@@ -452,7 +452,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
@@ -462,7 +462,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.
@@ -470,29 +470,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
@@ -504,7 +504,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.
@@ -778,7 +778,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
@@ -802,7 +802,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.
@@ -862,7 +862,7 @@ para incorporar algo ao projeto e, portanto, não são permanentes - uma
vez incorporados, são removidos.
Nos esquemas de trabalho, os membros são instruídos a fazerem o
-desenvolvimentos nos ramos de demandae jamais nos ramos permanentes. Ao
+desenvolvimentos nos ramos de demanda e jamais nos ramos permanentes. Ao
concluir essa unidade de trabalho, esse *branch* é enviado para o
servidor com um `push`
@@ -872,14 +872,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*.
@@ -897,11 +897,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.
@@ -915,9 +915,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).