GitHub puede ser, en esencia, una fachada web de git. Sin embargo, ésta proporciona algo que la diferencia y que es la esencia alrededor de la que gira su éxito y razón de ser: los forks.

Curiosamente, estas bifurcaciones en el desarrollo de todo proyecto de software que mantiene su «repositorio» en GitHub resultan ser, creo yo, la principal fuente de dudas y confusiones cuando pasa  lo que naturalmente tiene que pasar: el origen de la bifurcación avanza y ofrece cambios posteriores al fork.

El procedimiento para resolver la diferencia está plenamente documentada en git, consta de tan sólo cinco pasos, pero curiosamente hay mucha gente que busca ese botón en la interfaz web que les permita hacerlo en sólo un click. Hay quienes han encontrado algún workaround o truco mediante la interfaz de GitHub, con algún efecto colateral o consecuencia (no las documentaré aquí pues, al final, no dejan de ser una forma incorrecta de hacer las cosas propias de alguien flojo y no voy a perpetrar eso; dejo mejor referencias a artículos que exponen muy bien el caso^1-3, a uno personal destacando la importancia de la herramienta y servicio⁴ y a un par más tratando el asunto de los «repositorios» y flujos de trabajo^5,6).

Entonces, lo primero es entender, como he mencionado, que los forks son una adición de GitHub

Lo segundo es recordar que GitHub no deja de ser más que una interfaz para facilitar el uso de git como una herramienta colaborativa a través de la web. Seguir el flujo natural de git es lo correcto. Debe evitarse buscar atajos con GitHub.

Este flujo natural, perfectamente ilustrado en los dos diagramas previos se resume a los comandos git:

$ git remote add upstream https://github.com/Original-Owner-Username/Original-Repository.git
$ git fetch upstream
$ git checkout master
$ git merge upstream/master
$ git push

donde lo que se está haciendo, como se ha ilustrado, es agregar el «repositorio» original como uno adicional al «bifurcado» (add upstream, que crea una ramificación local de nombre upstream/master); conjuntar lo que el orignal pueda tener con el ramificado(fetch upstream) y así obtener lo últmo del original (esto no altera lo que se tenga en master sólo en  upstream/master); fijar el repositorio ramifcado como el de trabajo; unir cambios (merge) dejando que git haga lo que se supone debe hacer y su razón de ser; y, finalmente, actualizar (push) nuestro contenedor y finalizar la sincronización.

Véase la página dedicada a Freeling 4 en este sitio como un  ejemplo de este proceso.

Referencias

1. Jason Arnold, «How to Keep a GitHub Fork In Sync,» Medium, blog. Posted: 2016.10.03; consulted: 2017.12.30. URL: https://medium.com/@thejasonfile/how-to-keep-a-github-fork-in-sync-4a2968364e07.
2. Tab Akins Jr., «Cleanly Handling a Fork on GitHub«, xanthir.com, web. Published: 2016.06.08; consulted: 2017.12.29. URL: https://www.xanthir.com/b4hf0.
3. Justin James, «Sync your Git Fork to the Original Repo,» digitaldrummerj.me, web. Published: 2015.10.27; consulted: 2017.12.29. URl: http://digitaldrummerj.me/git-sync-fork-to-master/
4. Eduardo René Rodríguez Ávila, «De git, GitHub y el control de versiones«, ERAvila, post. Publicado: 2016.01.30; revisado: 2017.12.30. URL: https://eravila.wordpress.com/2016/01/30/foro-git/.
5. Mike Nikles, «A monorepo, GitHub Flow and automation FTW,» hackernoon.com, web. Published: 2017.12.23; consulted: 2017.12.29. URL: https://hackernoon.com/a-monorepo-github-flow-and-automation-ftw-c41a2d9c48bb.
6. Markus Oberlehner, «Monorepos in the Wild,» Medium, blog. Published: 2017.06.12; consulted: 2017.12.30. URL: https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9.