@@ -255,7 +255,7 @@ Hasta acá consideramos el caso en que iniciamos un fork de un repo GitHub y pon
Hay que ser cuidadosx porque eventualmente vamos a utilizar herramientas que permiten "re-escribir la historia". Observen la formulación: en todo lo que sigue, no vamos a re-escribir la historia. Lo que vamos a hacer es dejar una huella mejor ordenada de la historia. Pero vamos a guardar todo, o casi todo. Y en cada caso que se esté haciendo algo que pueda borrar información del repo lo señalaremos. ¿Ya quedó atrás el pánico?
Primero un resumen de la historia:
- al instante de hacer el fork de un repo se lo clona en una nueva instancia eb otro namespace, con todo lo que contienen. Entonces el repo y el fork comparten los commits, ramas, tags, etc. que existían entonces. Comparten al menos el commit inicial y la rama principal, llamémosla master aquí.
- al instante de hacer el fork de un repo se lo clona en una nueva instancia en otro namespace, con todo lo que contienen. Entonces el repo y el fork comparten los commits, ramas, tags, etc. que existían entonces. Comparten al menos el commit inicial y la rama principal, llamémosla master aquí.
- los dos repos evolucionan por separado y recorren caminos o grafos diferentes
- pero siempre siguen compartiendo ese historial inicial común, sobre el cual sólo se agregaron contribuciones diferenciales (de hecho, si hay algo que nunca hay que borrar, es la rama y el commit desde el cual se ha hecho un fork)
...
...
@@ -271,8 +271,19 @@ La definición más precisa de lo que hace ese .. es que muestra todos los commi
Recorremos hasta el último commit del log y copiamos su hash. Si lo único que nos interesa es ir a ver ese hash, podemos resumir los reportes de log:
Pues es ahí que podemos crear nuestra rama `upstream-master`, y pararnos en ella:
```
$ git branch upstream-master
$ git checkiut upstream-master
$ git checkout upstream-master
```
Rama así bien injertada en el arbol del repo, de manera a que se actualice sin conflicto:
```
...
...
@@ -321,11 +332,9 @@ $ git pull upstream/master
```
Y ya tenemos nuestra rama upstream-master lista para preparar PRs para el repo de upstream.
Hasta acá hemos resuelto el órden el el repo sin nisiquiera tener en algo que "re-escribir la historia". Simplemente la recorrimos.
Ahora, si a la hora de ordenarse para hacer PRs en upstream, nos damos cuenta que la rama `upstream-master` ya está creada, y que por alguna razón o error no sigue el mismo camino que su espejo `upstream/master` (¿notan la sutileza? `nom-bre``remote/nombre`).
Hasta acá hemos resuelto el órden el el repo sin ni siquiera tener en algo que "re-escribir la historia". Simplemente la recorrimos.
Ahí sí conviene, no re-escribir la histria, sino corregir una versión mal reportada de la historia.
Ahora bien, si a la hora de prepararse para hacer PRs en upstream, nos damos cuenta que la rama `upstream-master` ya existe, y que por alguna razón o error no sigue el mismo camino que su espejo `upstream/master` (¿notan la sutileza? `nom-bre``remote/nombre`), ahí sí conviene, no re-escribir la histria, sino corregir una versión mal reportada de la misma.
A lo sumo, si por alguna razón no queremos perder el historial de esa rama equivocada, bien podemos preservarla con otro nombre antes de corregirla:
```
...
...
@@ -352,7 +361,7 @@ $ git pull upstream/master
Documentándome un poco para escribir esto, caí sobre un billete de blog que, si sos de los que leen sólo los titulares, te hará hacer muchas cagadas: [Always Squash and Rebase your Git Commits](https://blog.carbonfive.com/2017/08/28/always-squash-and-rebase-your-git-commits/).
Lo que conviene entender de ese título es que en muchos casos, es bueno poner orden a posteriori. La historia escrita en un git puede ser verborrágica. No siempre recordamos hacer `git ---amend` cuando nos olvidamos de un detalle en un commit. ¿cuántas veces hacemos un commit sólo por cambiar de rama o para retomar el trabajo en otra computadora?
Lo que conviene entender de ese título es que en muchos casos, es bueno poner orden a posteriori. La historia escrita en un git puede ser verborrágica. No siempre recordamos hacer `git ---amend` cuando nos olvidamos de un detalle en un commit. ¿Y cuántas veces hacemos un commit sólo por cambiar de rama o para retomar el trabajo en otra computadora?
Todo eso, no sólo no aporta nada y hace ruido, sino que además comprende metadatos que pueden llegar a interactuar con temas de privacidad. Es sano tirar a la basura los borradores y ordenar mejor la biblioteca.
