Fast-forward.
[cursogit.git] / Merge.mdwn
index 3c5c709..79a16ef 100644 (file)
@@ -87,6 +87,34 @@ quando não se deve reescrevê-la.
 
 ## Fast-foward
 
+Quando realizamos um push em um repositório, enviamos nossas
+atualizações. No entanto, existe uma condição para que o Git aceite esta
+atualização sem emitir um aviso. O novo commit enviado deve conter todos
+os commits já presentes no branch sendo atualizado. Significa que o novo
+commit deve ter o velho commit como ancestral em seu grafo de histórico.
+
+No exemplo anterior em que fizemos o amend, tanto o branch amend quanto
+o branch devel não têm o branch master como ancestral. Isto significa
+que a atualização do branch master para um destes commits não avançaria
+o histórico. Não seria o que chamamos de fast-forward.
+
+Fazer uma atualização que não é fast-forward seria como apagar o
+histórico que já ocorreu. Substituir um ramo por outro. É o que muitos
+chamam de fork. Fazer fork utilizando diferentes repositórios por
+diferentes pessoas, ou diferentes branches com o propósito de realizar
+merges é saudável pra uma comunidade. É o que permite o envolvimento de
+mais pessoas em um projeto, e a experimentação. Mas substituir um mesmo
+branch público por algo que apaga parte de seu histórico pode introduzir
+vários problemas no fluxo de trabalho de uma comunidade, como merges
+duplicados e desnecessários, reescritas de histórico em toda a cadeia de
+branches e forks, criando um efeito cascata.
+
+Portanto, não publique branches que não pretenda manter de forma
+fast-forward, a não ser que fique claro no workflow como aquele branch
+será consumido em outro branch fast-forward, ou deixando claro que o
+branch será reescrito, e não deve ser utilizado como base a não ser que
+o contribuidor esteja preparado para lidar com as reescritas.
+
 ## Merge
 
 Integração de código e histórico.