Merge branch 'git:gh-pages' into gh-pages

Author: Liabaemt

external/book/content/book/de/v2/GitHub-Mitwirken-an-einem-Projekt.html

@@ -26,7 +26,7 @@ <h3 id="_forken_von_projekten">Forken von Projekten</h3>
 <div class="paragraph">
 <p>
 Wenn du zu einem bestehenden Projekt beitragen möchtest, zu dem du keine Push-Berechtigungen hast, kannst du das Projekt „forken“.
-Wenn du ein Projekt „forkst“, erstellt GitHub eine Kopie des Projekts, die ganz dir gehört. Es befindet sich in deinem Namensraum (engl. namespace), und du können Daten dorthin pushen.</p>
+Wenn du ein Projekt „forkst“, erstellt GitHub eine Kopie des Projekts, die ganz dir gehört. Es befindet sich in deinem Namensraum (engl. namespace), und du kannst Daten dorthin pushen.</p>
 </div>
 <div class="admonitionblock note">
 <table>
@@ -37,7 +37,7 @@ <h3 id="_forken_von_projekten">Forken von Projekten</h3>
 <td class="content">
 <div class="paragraph">
 <p>In der Vergangenheit war der Begriff „Fork“ in diesem Zusammenhang etwas Negatives und bedeutete, dass jemand ein Open-Source-Projekt in eine andere Richtung lenkt, manchmal ein konkurrierendes Projekt erstellt und die Beitragenden aufgespaltet hat.
-In GitHub ist ein „Fork“ schlichtweg das gleiche Projekt in deinem eigenen Namensraum, so dass du Änderungen an einem Projekt öffentlich vornehmen kannst und dabei einen transparenten Ansatz verfolgest.</p>
+In GitHub ist ein „Fork“ schlichtweg das gleiche Projekt in deinem eigenen Namensraum, so dass du Änderungen an einem Projekt öffentlich vornehmen kannst und dabei einen transparenten Ansatz verfolgst.</p>
 </div>
 </td>
 </tr>

external/book/content/book/de/v2/_index.html

@@ -8,7 +8,7 @@
   language_code: de
   front_page: true
   repository_url: https://github.com/progit/progit2-de
-  sha: 1c5c77264f1cedc7374e682c9f005396cfffab4a
+  sha: bc96d6144bbb6cd914d270cdb33c00b03731af14
 page_title: Git - Book
 url: "/book/de/v2.html"
 aliases:

external/book/content/book/en/v2/_index.html

@@ -8,10 +8,10 @@
   language_code: en
   front_page: true
   repository_url: https://github.com/progit/progit2
-  sha: 652208f3f9ba3f31a846cf54b4b1aa682dd72e09
-  ebook_pdf: https://github.com/progit/progit2/releases/download/2.1.434/progit.pdf
-  ebook_epub: https://github.com/progit/progit2/releases/download/2.1.434/progit.epub
-  ebook_mobi: https://github.com/progit/progit2/releases/download/2.1.434/progit.mobi
+  sha: 3b3669ae50db7acce37dbbd5ee34222d248e095d
+  ebook_pdf: https://github.com/progit/progit2/releases/download/2.1.435/progit.pdf
+  ebook_epub: https://github.com/progit/progit2/releases/download/2.1.435/progit.epub
+  ebook_mobi: https://github.com/progit/progit2/releases/download/2.1.435/progit.mobi
 page_title: Git - Book
 url: "/book/en/v2.html"
 aliases:

external/book/content/book/nl/v2/_index.html

@@ -8,7 +8,7 @@
   language_code: nl
   front_page: true
   repository_url: https://github.com/progit/progit2-nl
-  sha: 3bc66ea22a540be1237378582abc49802eca25c5
+  sha: 5ab58d95a679160885bcb6f92dd7dbc8c8a99eea
 page_title: Git - Book
 url: "/book/nl/v2.html"
 aliases:

external/book/content/book/pt-br/v2/Branches-no-Git-Branches-em-poucas-palavras.html

@@ -20,7 +20,7 @@
 <p>
 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.</p><p>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.
+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.</p><p>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?
 A forma como o Git cria branches é incrivelmente leve, tornando as operações de ramificação quase instantâneas, alternando entre os branches geralmente com a mesma rapidez.
 Ao contrário de muitos outros sistemas, o Git incentiva fluxos de trabalho que se ramificam e se fundem com frequência, até mesmo várias vezes ao dia.
@@ -48,7 +48,7 @@ <h2 id="r_git_branches_overview">Branches em poucas palavras</h2>
 </div>
 <div class="paragraph">
 <p>Quando você faz um commit executando <code>git commit</code>, 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.
 </p>
 </div>
 <div class="paragraph">
@@ -83,7 +83,7 @@ <h2 id="r_git_branches_overview">Branches em poucas palavras</h2>
 </td>
 <td class="content">
 <div class="paragraph">
-<p>O branch ‘` master '’ no Git não é um branch especial. 
+<p>O branch ' <code>master</code> ' 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 <code>git init</code> o cria por padrão e a maioria das pessoas não se preocupa em alterá-lo.</p>
 </div>
@@ -147,7 +147,7 @@ <h3 id="r_create_new_branch">Criando um Novo Branch</h3>
 </div>
 </div>
 <div class="paragraph">
-<p>Você pode ver os branches ‘` master <em>’ e `` testing '</em> que estão bem ali ao lado do commit <code>f30ab</code>.</p>
+<p>Você pode ver os branches <code>master</code> e <code>testing</code> que estão bem ali ao lado do commit <code>f30ab</code>.</p>
 </div>
 </div>
 <div class="sect3">
@@ -163,7 +163,7 @@ <h3 id="r_switching_branches">Alternando entre Branches</h3>
 </div>
 </div>
 <div class="paragraph">
-<p>Isso move o <code>HEAD</code> e o aponta para o branch` testing`.</p>
+<p>Isso move o <code>HEAD</code> e o aponta para o branch <code>testing</code>.</p>
 </div>
 <div class="imageblock">
 <div class="content">
@@ -188,7 +188,7 @@ <h3 id="r_switching_branches">Alternando entre Branches</h3>
 <div class="title">Figure 15. O branch do HEAD avança quando um commit é feito</div>
 </div>
 <div class="paragraph">
-<p>Isso é interessante, porque agora seu branch <code>testing</code> avançou, mas seu branch` master` ainda aponta para o commit em que você estava quando executou <code>git checkout</code> para alternar entre os branches.
+<p>Isso é interessante, porque agora seu branch <code>testing</code> avançou, mas seu branch <code>master</code> ainda aponta para o commit em que você estava quando executou <code>git checkout</code> para alternar entre os branches.
 Vamos voltar para o branch <code>master</code>:</p>
 </div>
 <div class="listingblock">
@@ -204,7 +204,7 @@ <h3 id="r_switching_branches">Alternando entre Branches</h3>
 </div>
 <div class="paragraph">
 <p>Esse comando fez duas coisas.
-Ele moveu o ponteiro HEAD de volta para apontar para o branch <code>master</code>, 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 <code>master</code>, e reverteu os arquivos em seu diretório de trabalho de volta para o snapshot para o qual <code>master</code> 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 <code>testing</code> para que você possa ir em uma direção diferente.</p>
 </div>
@@ -238,7 +238,7 @@ <h3 id="r_switching_branches">Alternando entre Branches</h3>
 <p>Agora o histórico do seu projeto divergiu (consulte <a href="{{< relurl "book/pt-br/v2/ch00/rdivergent_history" >}}">Histórico de diferenças</a>).
 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 <code>branch</code>,` checkout` e <code>commit</code>.</p>
+E você fez tudo isso com comandos simples <code>branch</code>, <code>checkout</code> e <code>commit</code>.</p>
 </div>
 <div id="rdivergent_history" class="imageblock">
 <div class="content">
@@ -262,11 +262,11 @@ <h3 id="r_switching_branches">Alternando entre Branches</h3>
 </div>
 </div>
 <div class="paragraph">
-<p>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.
+<p>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).</p>
 </div>
 <div class="paragraph">
-<p>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.
+<p>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.</p>

external/book/content/book/pt-br/v2/Branches-no-Git-Branches-remotos.html

@@ -32,7 +32,7 @@ <h2 id="r_remote_branches">Branches remotos</h2>
 <div class="paragraph">
 <p>Eles assumem a forma <code>(remoto)/(branch)</code>.
 Por exemplo, se você quiser ver como era o branch <code>master</code> em seu branch remoto <code>origin</code> da última vez que você se comunicou com ele, você deve verificar o branch <code>origin/master</code>.
-Se você estava trabalhando em um problema com um parceiro e ele enviou um branch <code>iss53</code>, você pode ter seu próprio branch local <code>iss53</code>; mas o branch no servidor apontaria para o commit em <code>origin/iss53</code>.</p>
+Se você estava trabalhando em um problema com um parceiro e ele enviou um push branch <code>iss53</code>, você pode ter seu próprio branch local <code>iss53</code>; mas o branch no servidor apontaria para o commit em <code>origin/iss53</code>.</p>
 </div>
 <div class="paragraph">
 <p>Isso pode ser um pouco confuso, então vamos ver um exemplo.
@@ -84,7 +84,7 @@ <h2 id="r_remote_branches">Branches remotos</h2>
 <div class="title">Figure 32. <code>git fetch</code> atualiza suas preferências remotas</div>
 </div>
 <div class="paragraph">
-<p>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.
+<p>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 <code>git.team1.ourcompany.com</code>.
 Você pode adicioná-lo como uma nova referência remota ao projeto em que está trabalhando atualmente executando o comando <code>git remote add</code> conforme abordamos em <a href="{{< relurl "book/pt-br/v2/ch00/ch02-git-basics" >}}">[ch02-git-basics]</a>.
 Nomeie este servidor remoto como <code>teamone</code>, que será o seu apelido para toda a URL.</p>
@@ -132,7 +132,7 @@ <h3 id="r_pushing_branches">Empurrando (Push)</h3>
 </div>
 <div class="paragraph">
 <p>Este é um atalho.
-O Git expande automaticamente o branch <code>serverfix</code> para <code>refs/heads/serverfix:refs/heads/serverfix</code>, o que significa, “Pegue meu branch local serverfix e empurre-o para atualizar o branch serverfix remoto.”
+O Git expande automaticamente o branch <code>serverfix</code> para <code>refs/heads/serverfix:refs/heads/serverfix</code>, o que significa, “Pegue meu branch local serverfix e empurre-o para atualizar o branch serverfix remoto”.
 Veremos a parte <code>refs/heads/</code> em detalhes em <a href="{{< relurl "book/pt-br/v2/ch00/ch10-git-internals" >}}">[ch10-git-internals]</a>, mas geralmente você pode deixá-la desativada.
 Você também pode fazer <code>git push origin serverfix:serverfix</code>, 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.
@@ -198,13 +198,13 @@ <h3 id="r_pushing_branches">Empurrando (Push)</h3>
 <h3 id="r_tracking_branches">Rastreando Branches</h3>
 <div class="paragraph">
 <p>
-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 <code>git pull</code>, o Git saberá automaticamente de qual servidor buscar o branch para fazer o merge.</p>
 </div>
 <div class="paragraph">
 <p>Quando você clona um repositório, geralmente ele cria automaticamente um branch <code>master</code> que rastreia <code>origin/master</code>.
-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 <code>master</code>.
+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 <code>master</code>.
 O caso simples é o exemplo que você acabou de ver, executando <code>git checkout -b [branch] [remotename]/[branch]</code>.
 Esta é uma operação suficiente para que o Git forneça a abreviação <code>--track</code>:</p>
 </div>

external/book/content/book/pt-br/v2/Branches-no-Git-Fluxo-de-Branches.html

@@ -31,7 +31,7 @@ <h3 id="_branches_de_longa_duração">Branches de longa duração</h3>
 </div>
 <div class="paragraph">
 <p>Muitos desenvolvedores Git têm um fluxo de trabalho que adota essa abordagem, como ter apenas código totalmente estável em seu branch <code>master</code> - possivelmente apenas código que foi ou será lançado.
-Eles têm outro branch paralelo chamado <code>developers</code> ou <code>next</code>, 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 <code>master</code>.
+Eles têm outro branch paralelo chamado <code>developers</code> ou <code>next</code>, 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 <code>master</code>.
 É usado para puxar branches de tópico (de curta duração, como seu anterior <code>iss53</code>) quando eles estão prontos, para garantir que eles passem em todos os testes e não introduzam bugs.</p>
 </div>
 <div class="paragraph">
@@ -101,8 +101,8 @@ <h3 id="r_topic_branch">Branches por tópicos</h3>
 <p>Iremos entrar em mais detalhes sobre os vários fluxos de trabalho possíveis para seu projeto Git em <a href="{{< relurl "book/pt-br/v2/ch00/ch05-distributed-git" >}}">[ch05-distributed-git]</a>, portanto, antes de decidir qual esquema de ramificação seu próximo projeto usará, certifique-se de ler esse capítulo.</p>
 </div>
 <div class="paragraph">
-<p>É 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.</p>
+<p>É 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.</p>
 </div>
 </div>
 <div id="nav"><a href="{{< previous-section >}}">prev</a> | <a href="{{< next-section >}}">next</a></div>

external/book/content/book/pt-br/v2/Branches-no-Git-O-básico-de-Ramificação-Branch-e-Mesclagem-Merge.html

@@ -176,7 +176,7 @@ <h3 id="r_basic_branching">Ramificação Básica</h3>
 porque não há nenhum alteração divergente para mesclar — isso é conhecido como um merge “fast-forward.”</p>
 </div>
 <div class="paragraph">
-<p>Agora, a sua alteração está no snapshot do commmit para o qual o branch <code>master</code> aponta, e você você enviar a correção.</p>
+<p>Agora, a sua alteração está no snapshot do commmit para o qual o branch <code>master</code> aponta, e você pode enviar a correção.</p>
 </div>
 <div class="imageblock">
 <div class="content">
@@ -262,7 +262,7 @@ <h3 id="r_basic_merging">Mesclagem Básica</h3>
 <div class="title">Figure 25. Um commit de merge</div>
 </div>
 <div class="paragraph">
-<p>Agora que seu trabalho foi integrado, você não precisa mais do brnach <code>iss53</code>.
+<p>Agora que seu trabalho foi integrado, você não precisa mais do branch <code>iss53</code>.
 Você pode encerrar o chamado no seu sistema e excluir o branch:</p>
 </div>
 <div class="listingblock">
@@ -324,7 +324,7 @@ <h3 id="r_basic_merge_conflicts">Conflitos Básicos de Merge</h3>
 </div>
 </div>
 <div class="paragraph">
-<p>Isso significa que a versão em <code>HEAD</code> (o seu branch <code>master</code>, porque era o que estava selecionado quando você executou o comando merge) é a parte superior daquele bloco (tudo após <code>=======</code>), enquanto que a versão no branch <code>iss53</code> contém a versão na parte de baixo.
+<p>Isso significa que a versão em <code>HEAD</code> (o seu branch <code>master</code>, porque era o que estava selecionado quando você executou o comando merge) é a parte superior daquele bloco (tudo acima de <code>=======</code>), enquanto que a versão no branch <code>iss53</code> 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:</p>
 </div>
@@ -341,7 +341,7 @@ <h3 id="r_basic_merge_conflicts">Conflitos Básicos de Merge</h3>
 Adicionar o arquivo ao stage o marca como resolvido para o Git.</p>
 </div>
 <div class="paragraph">
-<p>Se você quiser usar uma ferramenta gráfica para resolver os conflitos, você pode executar <code>git mergetool</code>, que inicia uma ferramente de mesclagem visual apropriada e guia você atravès dos conflitos:</p>
+<p>Se você quiser usar uma ferramenta gráfica para resolver os conflitos, você pode executar <code>git mergetool</code>, que inicia uma ferramenta de mesclagem visual apropriada e guia você através dos conflitos:</p>
 </div>
 <div class="listingblock">
 <div class="content">