Ajustes cap3.6

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>>.