Ajustes cap3

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -110,7 +110,7 @@ Já que o branch `hotfix` que você mesclou aponta para o commit `C4` que está
 Em outras palavras, quando você tenta mesclar um commit com outro commit que pode ser alcançado por meio do histórico do primeiro commit, o Git simplifica as coisas e apenas move o ponteiro para a frente
 porque não há nenhum alteração divergente para mesclar -- isso é conhecido como um merge ``fast-forward.''
 
-Agora, a sua alteração está no snapshot do commmit para o qual o branch `master` aponta, e você você enviar a correção.
+Agora, a sua alteração está no snapshot do commmit para o qual o branch `master` aponta, e você pode enviar a correção.
 
 .o branch `master` sofre um "fast-forward" até `hotfix`
 image::images/basic-branching-5.png[o branch `master` sofre um 'fast-forward' até `hotfix`.]
@@ -177,7 +177,7 @@ Esse tipo de commit é chamado de commit de merge, e é especial porque tem mais
 .Um commit de merge
 image::images/basic-merging-2.png[Um commit de merge.]
 
-Agora que seu trabalho foi integrado, você não precisa mais do brnach `iss53`.
+Agora que seu trabalho foi integrado, você não precisa mais do branch `iss53`.
 Você pode encerrar o chamado no seu sistema e excluir o branch:
 
 [source,console]
@@ -235,7 +235,7 @@ O seu arquivo contém uma seção que se parece com isso:
 >>>>>>> iss53:index.html
 ----
 
-Isso significa que a versão em `HEAD` (o seu branch `master`, porque era o que estava selecionado quando você executou o comando merge) é a parte superior daquele bloco (tudo após `=======`), enquanto que a versão no branch `iss53` contém a versão na parte de baixo.
+Isso significa que a versão em `HEAD` (o seu branch `master`, porque era o que estava selecionado quando você executou o comando merge) é a parte superior daquele bloco (tudo acima de `=======`), enquanto que a versão no branch `iss53` contém a versão na parte de baixo.
 Para solucionar o conflito, você precisa escolher um dos lados ou mesclar os conteúdos diretamente.
 Por exemplo, você pode resolver o conflito substituindo o bloco completo por isso:
 
@@ -250,7 +250,7 @@ Essa solução tem um pouco de cada versão, e as linhas com os símbolos `<<<<<
 Após solucionar cada uma dessas seções em cada arquivo com conflito, execute `git add` em cada arquivo para marcá-lo como solucionado.
 Adicionar o arquivo ao stage o marca como resolvido para o Git.
 
-Se você quiser usar uma ferramenta gráfica para resolver os conflitos, você pode executar `git mergetool`, que inicia uma ferramente de mesclagem visual apropriada e guia você atravès dos conflitos:(((git commands, mergetool)))
+Se você quiser usar uma ferramenta gráfica para resolver os conflitos, você pode executar `git mergetool`, que inicia uma ferramenta de mesclagem visual apropriada e guia você através dos conflitos:(((git commands, mergetool)))
 
 [source,console]
 ----

book/03-git-branching/sections/nutshell.asc

@@ -18,7 +18,7 @@ $ git commit -m 'The initial commit of my project'
 ----
 
 Quando você faz um commit executando `git commit`, o Git verifica cada subdiretório (neste caso, apenas o diretório raiz do projeto) e armazena esses objetos no repositório do Git.
-O Git então cria um objeto de commit que possui os metadados e um ponteiro para a raiz do projeto para que ele possa recriar aquele snapshots quando necessário.
+O Git então cria um objeto de commit que possui os metadados e um ponteiro para a raiz do projeto para que ele possa recriar aquele snapshot quando necessário.
 (((git commands, commit)))
 
 Seu repositório Git agora contém cinco objetos: um blob para o conteúdo de cada um dos seus três arquivos, uma árvore que lista o conteúdo do diretório e especifica quais nomes de arquivo são armazenados e quais seus blobs e um commit com o ponteiro para essa árvore e todos os metadados de commit.
@@ -38,7 +38,7 @@ Cada vez que você faz um novo commit, ele avança automaticamente.
 
 [NOTE]
 ====
-O branch `` master '' no Git não é um branch especial. (((Master)))
+O branch ' `master` ' no Git não é um branch especial. 
 É exatamente como qualquer outra ramificação.
 A única razão pela qual quase todo repositório tem um é que o comando `git init` o cria por padrão e a maioria das pessoas não se preocupa em alterá-lo.
 ====
@@ -86,7 +86,7 @@ f30ab (HEAD -> master, testing) add feature #32 - ability to add new formats to
 98ca9 The initial commit of my project
 ----
 
-Você pode ver os branches `` master '' e `` testing '' que estão bem ali ao lado do commit `f30ab`.
+Você pode ver os branches `master` e `testing` que estão bem ali ao lado do commit `f30ab`.
 
 [[r_switching_branches]]
 ==== Alternando entre Branches
@@ -100,7 +100,7 @@ Vamos mudar para o novo branch `testing`:
 $ git checkout testing
 ----
 
-Isso move o `HEAD` e o aponta para o branch` testing`.
+Isso move o `HEAD` e o aponta para o branch `testing`.
 
 .HEAD aponta para o branch atual
 image::images/head-to-testing.png[HEAD points to the current branch.]
@@ -117,7 +117,7 @@ $ git commit -a -m 'made a change'
 .O branch do HEAD avança quando um commit é feito
 image::images/advance-testing.png[The HEAD branch moves forward when a commit is made.]
 
-Isso é interessante, porque agora seu branch `testing` avançou, mas seu branch` master` ainda aponta para o commit em que você estava quando executou `git checkout` para alternar entre os branches.
+Isso é interessante, porque agora seu branch `testing` avançou, mas seu branch `master` ainda aponta para o commit em que você estava quando executou `git checkout` para alternar entre os branches.
 Vamos voltar para o branch `master`:
 
 [source,console]
@@ -129,7 +129,7 @@ $ git checkout master
 image::images/checkout-master.png[HEAD moves when you checkout.]
 
 Esse comando fez duas coisas.
-Ele moveu o ponteiro HEAD de volta para apontar para o branch `master`, e reverteu os arquivos em seu diretório de trabalho de volta para o snapshots para o qual` master` aponta.
+Ele moveu o ponteiro HEAD de volta para apontar para o branch `master`, e reverteu os arquivos em seu diretório de trabalho de volta para o snapshot para o qual `master` aponta.
 Isso também significa que as alterações feitas a partir deste ponto irão divergir de uma versão mais antiga do projeto.
 Essencialmente, ele retrocede o trabalho que você fez em seu branch `testing` para que você possa ir em uma direção diferente.
 
@@ -152,7 +152,7 @@ $ git commit -a -m 'made other changes'
 Agora o histórico do seu projeto divergiu (consulte <<rdivergent_history>>).
 Você criou e mudou para um branch, fez algum trabalho nele e, em seguida, voltou para o seu branch principal e fez outro trabalho.
 Ambas as mudanças são isoladas em branches separados: você pode alternar entre os branches e mesclá-los quando estiver pronto.
-E você fez tudo isso com comandos simples `branch`,` checkout` e `commit`.
+E você fez tudo isso com comandos simples `branch`, `checkout` e `commit`.
 
 [[rdivergent_history]]
 .Histórico de diferenças
@@ -172,12 +172,12 @@ $ git log --oneline --decorate --graph --all
 * 98ca9 initial commit of my project
 ----
 
-Como um branch no Git é na verdade um arquivo simples que contém a verificação SHA-1 de 40 caracteres do commit para o qual ele aponta, branches são fáceis para criar e destruir.
+Como um branch no Git é na verdade um arquivo simples que contém a verificação SHA-1 de 40 caracteres do commit para o qual ele aponta, branches são fáceis de criar e destruir.
 Criar um novo branch é tão rápido e simples quanto escrever 41 bytes em um arquivo (40 caracteres e uma nova linha).
 
-Isso está em nítido contraste com a forma como as ferramentas de Versionamento mais antigas se ramificam, o que envolve a cópia de todos os arquivos do projeto em um segundo diretório.
+Isso está em nítido contraste com a forma como as ferramentas de versionamento mais antigas se ramificam, o que envolve a cópia de todos os arquivos do projeto em um segundo diretório.
 Isso pode levar vários segundos ou até minutos, dependendo do tamanho do projeto, enquanto no Git o processo é sempre instantâneo.
 Além disso, como estamos gravando os pais quando fazemos o commit, encontrar uma base adequada para a mesclagem é feito automaticamente para nós e geralmente é muito fácil de fazer.
 Esses recursos ajudam a incentivar os desenvolvedores a criar e usar branches com frequência.
 
-Vamos ver por que você deve fazer isso.
+Vamos ver por que você deve fazer isso.

book/03-git-branching/sections/rebasing.asc

@@ -72,14 +72,14 @@ Finalmente, você voltou ao seu branch de servidor e fez mais alguns commits.
 image::images/interesting-rebase-1.png[A history with a topic branch off another topic branch.]
 
 Suponha que você decida que deseja mesclar suas alterações do lado do cliente em sua linha principal para um lançamento, mas deseja adiar as alterações do lado do servidor até que seja testado mais profundamente.
-Você pode pegar as mudanças no cliente que não está no servidor (`C8` e `C9`) e reproduzi-las em seu branch `master` usando a opção `--onto` do `git rebase`:
+Você pode pegar as mudanças no cliente que não estão no servidor (`C8` e `C9`) e reproduzi-las em seu branch `master` usando a opção `--onto` do `git rebase`:
 
 [source,console]
 ----
 $ git rebase --onto master server client
 ----
 
-Isso basicamente diz: ``Pegue o branch `client`, descubra os patches, desde que divergiu do branch `server`, e repita esses patches no branch `client` como se fosse baseado diretamente no branch `master`.''
+Isso basicamente diz: ``Pegue o branch `client`, descubra os patches, desde que divergiu do branch `server`, e repita esses patches no branch `client` como se fosse baseado diretamente no branch `master`''.
 É um pouco complexo, mas o resultado é bem legal.
 
 .Rebase o tópico de um branch de outro branch
@@ -143,7 +143,7 @@ Se você seguir essa diretriz, ficará bem.
 Do contrário, as pessoas irão odiá-lo e você será desprezado por amigos e familiares.
 
 Quando você faz o rebase, você está abandonando commits existentes e criando novos que são semelhantes, mas diferentes.
-Se você enviar commits para algum lugar e outros puxá-los para baixo e trabalhar com base neles, e então você reescrever esses commits com `git rebase` e colocá-los novamente, seus colaboradores terão que fazer um novo merge em seus trabalhos e as coisas ficarão complicadas quando você tentar puxar o trabalho deles de volta para o seu.
+Se você enviar commits para algum lugar e outras pessoas fizerem o pull e basearem seu trabalho neles, e então você reescrever esses commits com `git rebase` e enviá-los novamente, seus colaboradores terão que fazer um novo merge em seus trabalhos e as coisas ficarão complicadas quando você tentar puxar o trabalho deles de volta para o seu.
 
 Vejamos um exemplo de como o rebase de um trabalho que você tornou público pode causar problemas.
 Suponha que você clone de um servidor central e faça algum trabalho a partir dele.
@@ -158,7 +158,7 @@ Você o busca e mescla o novo branch remoto em seu trabalho, fazendo com que seu
 .Buscar mais commits e fazer merge em seu trabalho
 image::images/perils-of-rebasing-2.png["Fetch more commits, and merge them into your work."]
 
-Em seguida, a pessoa que empurrou o trabalho mesclado decide voltar e realocar seu trabalho; eles fazem um `git push --force` para sobrescrever o histórico no servidor.
+Em seguida, a pessoa que enviou o trabalho mesclado decide voltar atrás e realizar um rebase no trabalho em vez disso; ele faz um `git push --force` para sobrescrever o histórico no servidor.
 Você então busca daquele servidor, derrubando os novos commits.
 
 [[r_pre_merge_rebase_work]]
@@ -189,10 +189,10 @@ Se você puxar o trabalho que foi reescrito e fazer o rebase sobre os novos comm
 
 Por exemplo, no cenário anterior, se em vez de fazer uma fusão quando estamos em <<r_pre_merge_rebase_work>> executarmos `git rebase teamone/master`, Git irá:
 
-* Determine qual trabalho é exclusivo para nosso branch (C2, C3, C4, C6, C7)
-* Determine quais não são confirmações de merge (C2, C3, C4)
-* Determine quais não foram reescritos no branch de destino (apenas C2 e C3, uma vez que C4 é o mesmo patch que C4')
-* Aplique esses commits no topo de `teamone/master`
+* Determinar qual trabalho é exclusivo para nosso branch (C2, C3, C4, C6, C7)
+* Determinar quais não são confirmações de merge (C2, C3, C4)
+* Determinar quais não foram reescritos no branch de destino (apenas C2 e C3, uma vez que C4 é o mesmo patch que C4')
+* Aplicar esses commits no topo de `teamone/master`
 
 Então, em vez do resultado que vemos em <<r_merge_rebase_work>>, acabaríamos com algo mais parecido com <<r_rebase_rebase_work>>.
 

book/03-git-branching/sections/remote-branches.asc

@@ -12,7 +12,7 @@ Branches de rastreamento remoto agem como marcadores para lembrá-lo de onde est
 
 Eles assumem a forma `(remoto)/(branch)`.
 Por exemplo, se você quiser ver como era o branch `master` em seu branch remoto `origin` da última vez que você se comunicou com ele, você deve verificar o branch `origin/master`.
-Se você estava trabalhando em um problema com um parceiro e ele enviou um branch `iss53`, você pode ter seu próprio branch local `iss53`; mas o branch no servidor apontaria para o commit em `origin/iss53`.
+Se você estava trabalhando em um problema com um parceiro e ele enviou um push branch `iss53`, você pode ter seu próprio branch local `iss53`; mas o branch no servidor apontaria para o commit em `origin/iss53`.
 
 Isso pode ser um pouco confuso, então vamos ver um exemplo.
 Digamos que você tenha um servidor Git em sua rede em `git.ourcompany.com`.
@@ -42,7 +42,7 @@ Este comando procura em qual servidor está a ``origin'' (neste caso, é `git.no
 .`git fetch` atualiza suas preferências remotas
 image::images/remote-branches-3.png[`git fetch` updates your remote references.]
 
-Para demonstrar a existência de vários servidores remotos e como se parecem os branches remotos para esses projetos, vamos supor que você tenha outro servidor Git interno usado apenas para desenvolvimento por uma de suas equipes.
+Para demonstrar a existência de vários servidores remotos e como as branches remotas desses projetos remotos se parecem, vamos supor que você tenha outro servidor Git interno usado apenas para desenvolvimento por uma de suas equipes.
 Este servidor está em `git.team1.ourcompany.com`.
 Você pode adicioná-lo como uma nova referência remota ao projeto em que está trabalhando atualmente executando o comando `git remote add` conforme abordamos em <<ch02-git-basics#ch02-git-basics>>.
 Nomeie este servidor remoto como `teamone`, que será o seu apelido para toda a URL.
@@ -80,7 +80,7 @@ To https://github.com/schacon/simplegit
 ----
 
 Este é um atalho.
-O Git expande automaticamente o branch `serverfix` para `refs/heads/serverfix:refs/heads/serverfix`, o que significa, ``Pegue meu branch local serverfix e empurre-o para atualizar o branch serverfix remoto.''
+O Git expande automaticamente o branch `serverfix` para `refs/heads/serverfix:refs/heads/serverfix`, o que significa, ``Pegue meu branch local serverfix e empurre-o para atualizar o branch serverfix remoto''.
 Veremos a parte `refs/heads/` em detalhes em <<ch10-git-internals#ch10-git-internals>>, mas geralmente você pode deixá-la desativada.
 Você também pode fazer `git push origin serverfix:serverfix`, que faz a mesma coisa - ``Pegue meu serverfix e torne-o o serverfix remoto.''
 Você pode usar esse formato para enviar um branch local para um branch remoto com um nome diferente.
@@ -130,12 +130,12 @@ Isso lhe dá um branch local no qual você pode trabalhar que inicia onde está
 ==== Rastreando Branches
 
 (((branches, tracking)))(((branches, upstream)))
-Fazer check-out de um branch local de um branch remoto cria automaticamente o que é chamado de ``tracking branch'' (e o branch que ele rastreia é chamado de ``branch upstream'').
+Fazer check-out de um branch local a partir de um branch remoto cria automaticamente o que é chamado de ``tracking branch'' (e o branch que ele rastreia é chamado de ``branch upstream'').
 ``Tracking branch'' são branches locais que têm um relacionamento direto com um branch remoto.
 Se você estiver em um branch de rastreamento e digitar `git pull`, o Git saberá automaticamente de qual servidor buscar o branch para fazer o merge.
 
 Quando você clona um repositório, geralmente ele cria automaticamente um branch `master` que rastreia `origin/master`.
-No entanto, você pode configurar outros branches de rastreamento se desejar - aqueles que rastreiam branches em outros branches remotos ou não rastreiam o branch `master`.
+No entanto, você pode configurar outros branches de rastreamento se desejar - aqueles que rastreiam branches em outros branches remotos, ou não rastreiam o branch `master`.
 O caso simples é o exemplo que você acabou de ver, executando `git checkout -b [branch] [remotename]/[branch]`.
 Esta é uma operação suficiente para que o Git forneça a abreviação `--track`:
 

book/03-git-branching/sections/workflows.asc

@@ -10,7 +10,7 @@ Como o Git usa uma mesclagem simples de três vias, mesclar de um branch para ou
 Isso significa que você pode ter vários branches que estão sempre abertos e que você usa para diferentes estágios do seu ciclo de desenvolvimento; você pode mesclar regularmente alguns deles com outros.
 
 Muitos desenvolvedores Git têm um fluxo de trabalho que adota essa abordagem, como ter apenas código totalmente estável em seu branch `master` - possivelmente apenas código que foi ou será lançado.
-Eles têm outro branch paralelo chamado `developers` ou `next`, a partir do qual trabalham ou usam para testar a estabilidade - nem sempre é necessariamente estável, mas sempre que chega a um estado estável, pode ser mesclado com o `master`.
+Eles têm outro branch paralelo chamado `developers` ou `next`, a partir do qual trabalham ou usam para testar a estabilidade - não é necessáriamente sempre estável, mas sempre que chega a um estado estável, pode ser mesclado com o `master`.
 É usado para puxar branches de tópico (de curta duração, como seu anterior `iss53`) quando eles estão prontos, para garantir que eles passem em todos os testes e não introduzam bugs.
 
 Na realidade, estamos falando sobre indicadores que aumentam a linha de commits que você está fazendo.
@@ -59,5 +59,5 @@ image::images/topic-branches-2.png[History after merging `dumbidea` and `iss91v2
 
 Iremos entrar em mais detalhes sobre os vários fluxos de trabalho possíveis para seu projeto Git em <<ch05-distributed-git#ch05-distributed-git>>, portanto, antes de decidir qual esquema de ramificação seu próximo projeto usará, certifique-se de ler esse capítulo.
 
-É importante lembrar quando você estiver fazendo tudo isso, que esses branches são completamente locais.
-Quando você está ramificando e mesclando, tudo está sendo feito apenas em seu repositório Git - nenhuma comunicação de servidor está acontecendo.
+É importante lembrar quando você estiver fazendo tudo isso que esses branches são completamente locais.
+Quando você está ramificando e mesclando, tudo está sendo feito apenas em seu repositório Git - nenhuma comunicação com o servidor está acontecendo.

ch03-git-branching.asc

@@ -5,7 +5,7 @@
 (((branches)))
 Quase todo Sistema de Controle de Versionamento tem alguma forma de suporte a ramificações (Branches).
 Ramificação significa que você diverge da linha principal de desenvolvimento e continua a trabalhar sem alterar essa linha principal.
-Em muitas ferramentas versionamento, este é um processo um tanto difícil, geralmente exigindo que você crie uma nova cópia do diretório do código-fonte, o que pode demorar muito em projetos maiores.
+Em muitas ferramentas de versionamento, este é um processo um tanto difícil, geralmente exigindo que você crie uma nova cópia do diretório do código-fonte, o que pode demorar muito em projetos maiores.
 
 Algumas pessoas se referem ao modelo de ramificação do Git como seu ``recurso matador'' e certamente diferencia o Git na comunidade de sistemas de versionamento.
 Por que isso é tão especial?