diff --git a/cap03.Rmd b/cap03.Rmd index c725951c5117f89c8fcc0c34a94818ff3aea3bbb..79d1cf6a26da2cc8beafc43f29e68b3fc0a0abcc 100644 --- a/cap03.Rmd +++ b/cap03.Rmd @@ -24,10 +24,10 @@ 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. Casos você queira usufruir das +desse tutorial algo reproduzível. Casos você queira usufruir das ferramentas gráficas vá para o capítulo 6. -Sabendo que você executou os comandos de perfil que no capítulo +Sabendo que você executou os comandos de perfil do capítulo anterior, temos o Git devidamente configurado, com credenciais (nome e e-mail) e configurações aplicadas. Vamos então ver como o sistema de controle de versão acontece. @@ -81,7 +81,7 @@ cd meu1repo git <instrução> <complementos ...> ``` -Os comandos abaixo revelam tudo o Git possui, embora dizer o que ele tem +Os comandos abaixo revelam tudo o que o Git possui, embora dizer o que ele tem não signifique nada diante do que ele pode fazer com o que tem. ```{r, engine="bash", echo=-c(1:2)} @@ -102,7 +102,7 @@ git init O Git retorna a mensagem de inicializaçã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 +diretório. É por essa razão que ele é oculto. Alterar seu 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 @@ -123,12 +123,12 @@ diretórios. Se você usa distribuição Debian, instale com `sudo apt-get install tree`. Windows: [tree][]. Vamos começar da maneira mais simples: criando um arquivo com uma linha -de texto apenas. Bem, vale avisar que ao longo desse capítulo, os +de texto apenas. Vale ressaltar que ao longo desse capítulo, os arquivos serão sempre bem pequenos e dificilmente realistas, mas como o -enfoque está no funcionamento, não haverá prejuízo. +enfoque está no funcionamento não haverá prejuízo. Vamos criar o arquivo com conteúdo também pelo terminal. Se você -preferir, abra eu editor de texto favorito (Emacs, Gedit, Geany, +preferir, use um editor de texto de sua preferência (Emacs, Gedit, Geany, RStudio, Bloco de Notas, Notepad++, etc) e faça algo mais criativo. ```{r, engine="bash", echo=-c(1:2)} @@ -170,10 +170,10 @@ traduzidos. \label{fig:cap03_pversion} \end{figure} -De forma geral temos 3 estágios \ref{fig:cap03_pversion} de arquivos +De forma geral temos 3 estágios (\ref{fig:cap03_pversion}) de arquivos considerados no sistema de controle de versionamento Git. São eles -*working directory*, *Staged Area* e *Committed*, os discutiremos ao -logo do texto. Todo arquivo criado em um diretório versionado deve +*working directory*, *Staged Area* e *Committed*. Seus assuntos serão abordados +ao longo do texto. Todo arquivo criado em um diretório versionado deve necessariamente passar pelos três estágios. Voltando para a nossa situação temos o arquivo `README.txt` criado e atualmente ele está no estágio *working directory*, faremos todo o procedimento para que chegue @@ -193,7 +193,7 @@ para serem registradas (*changes to be commited*). A melhor tradução de *commit*, pensando no seu uso em Git, é **fechar sob segurança**. Quando um *commit* é feito, cria-se um instante na linha do tempo que salva o estado do projeto. Para esse instante o projeto pode ser retrocedido, -voltando o condição/conteúdo de todos os arquivos para o momento no qual +voltando a condição/conteúdo de todos os arquivos para o momento no qual o mencionado *commit* foi feito. Você pode voltar para um *commit* de semanas e até anos atrás. @@ -256,7 +256,7 @@ mesmo de projetos moderados ou grandes. # Complementos # Para o registro de desenvolvimento, existe marcação por tags, que -seriam commits especiais, geralmente usado para marcar pontos de +seriam commits especiais, geralmente usada para marcar pontos de destaque do projeto, por exemplo versão alfa, beta, teste servidor. ```{r, engine = "bash", echo =-c(1:2), eval = FALSE} @@ -293,9 +293,7 @@ git rm README.txt # Versões de Arquivos Diferentes # Vamos criar mais arquivos e acrescentar conteúdo ao já rastreado pelo -Git para percebermos o funcionamento. Escrever uma lista de razões para -usar o Linux. Deixei a lista curta poder ampliar no futuro e com erros -de português para corrigir depois. +Git para percebermos o funcionamento. ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -335,8 +333,8 @@ git status ``` O Git retornou dois campos. No primeiro ele diz que existem mudanças no -`README.txt` não encaminhadas para receber registro (*not staged for -commit*) e no segundo ele aponta que o `porqueLinux.txt` é um arquivo +'`README.txt`' não encaminhadas para receber registro (*not staged for +commit*) e no segundo ele aponta que o '`porqueLinux.txt`' é um arquivo não rastreado (fora de monitoramento). Vamos explorar um pouco mais os recursos do Git antes de adicionar as @@ -396,7 +394,7 @@ git status Ainda resta o `REAMDE.txt` para receber registro. Você não precisa fazer agora. Pode continuar editando caso não tenha atingido uma quantidade de -modificação merecedora de *commit*. Lembre-se que registros geram +modificações 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 @@ -439,14 +437,14 @@ cd meu1repo git diff HEAD@{1} ``` -Instruímos o Git mostrar as diferenças para um *commit* atrás. A cabeça +Instruímos o Git a 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 instrução abaixo. -Agora inspecionado uma distância de 2 *commits* a partir do último. Aqui +Agora inspecionando 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. @@ -461,13 +459,11 @@ cd meu1repo git diff --name-only HEAD@{2} HEAD@{0} ``` - -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! +Ao abrir um arquivo no seu editor de texto e modificá-lo conforme necessário, +tal modificação compreeenderá a uma linha apenas. Futuramente, ao acrescentar +novas informações, o git diff mostrará as diferenças. Em um primeiro momento, +vale ressaltar que as diferenças são entre os *commits* dado que o conteúdo +adicionado ainda não recebeu notificação. ```{r, engine="bash", include=FALSE} cd meu1repo @@ -514,13 +510,13 @@ cd meu1repo less porqueLinux.txt ``` -Bateu o arrependimento? Tem formas de poder retroceder com mudanças +Caso decida reverter a situação, existem 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, +em outro diretório e experimente ele lá. Isso previne eventuais problemas, pois algumas ações podem ser irreversíveis. ```{r, engine="bash", echo=-c(1:2)} @@ -842,8 +838,8 @@ git log --oneline ``` É 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. +atual. Isso é extremamente útil para resolver os erros. Vamos fazer um +segundo ramo a partir do *commit* anterior à inclusão do arquivo R. ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -872,9 +868,7 @@ cd meu1repo ## O histório existente nesse ponto. git log --name-only --oneline ``` - -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. +Vamos conferir o conteúdo do *commit* mais recente. ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -1027,7 +1021,7 @@ git log --graph --oneline --decorate --date=relative --all 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 +novo ramo porque atualmente estamos em um ramo suspenso (*detached HEAD*) que não é persistente. ```{r, engine="bash", echo=-c(1:2)} @@ -1131,7 +1125,7 @@ cd meu1repo git log --graph --oneline --decorate --date=relative --all ``` -Agora nos temos o *feature01* na frente do master e o *feature02* ao +Agora nós 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 @@ -1184,7 +1178,7 @@ 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 ressurgir se você voltar no tempo. +história do projeto e podem ressurgir se você voltar no tempo. ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -1292,7 +1286,7 @@ git commit -m "Arquivo de experimento em BIB. Trunca cabeçalho 4 digitos." 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. +essa pessoa vai passar o cabeçalho para caixa alta. ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -1313,7 +1307,7 @@ cd meu1repo wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt' ``` -Ao encurtar o nome para quatro dígitos, fica assim. +Ao encurtar o nome para quatro dígitos, o resultado é dado por: ```{r, engine="bash", echo=-c(1:2)} cd meu1repo @@ -1369,7 +1363,7 @@ cd meu1repo less bib1.txt | head -10 ``` -Então deu conflito e o Git informa que ele deve ser resolvido. Resolver +Como podemos observar, 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 (`<<<<<<<`,