| ... | ... | @@ -245,4 +245,123 @@ santiagomr@pc:~/interior/ansible-zabbix-server$ git push origin master |
|
|
|
Total 0 (delta 0), reused 0 (delta 0)
|
|
|
|
To github.com:UdelaRInterior/ansible-zabbix-server.git
|
|
|
|
4a42c3f..812a747 master -> master
|
|
|
|
``` |
|
|
\ No newline at end of file |
|
|
|
```
|
|
|
|
|
|
|
|
## ¿Y si trabajamos en el repo forkeado sin haber hecho todo esto inicialmente? Don't panic!
|
|
|
|
|
|
|
|
Hasta acá consideramos el caso en que iniciamos un fork de un repo GitHub y ponemos ese orden que tienen las cosas desde un inicio. ¿Pero qué pasa si hacemos un fork y nos lanzamos a trabajar en él sin ni siquiera haber creado la rama `upstream-master`? Bueno, hay que ser cuidadosx, pero se puede poner orden a posteriori.
|
|
|
|
|
|
|
|
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í.
|
|
|
|
- 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)
|
|
|
|
|
|
|
|
Supongamos primero que la rama `upstream-master` aún no existe. Nos paramos en algún punto de nuestro repo, rama, tag o incluso commit:
|
|
|
|
```
|
|
|
|
yo@micompu:mi__fork$ git checkout master
|
|
|
|
```
|
|
|
|
Si ya tenemos configurado el remote upstream, y que hicimos un fetch a éste, podemos identificar el camino de nuestra rama de todo lo que agregamos desde el fork:
|
|
|
|
```
|
|
|
|
git log upstream/master..HEAD
|
|
|
|
```
|
|
|
|
La definición más precisa de lo que hace ese .. es que muestra todos los commits que están en la rama de la derecha, pero que no están en la de la izquierda.
|
|
|
|
|
|
|
|
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:
|
|
|
|
```
|
|
|
|
git log upstream/master..HEAD --oneline
|
|
|
|
```
|
|
|
|
Nos paramos entonces en ese hash:
|
|
|
|
```
|
|
|
|
$ git checkout ce4a63d
|
|
|
|
Nota: actualizando el árbol de trabajo 'ce4a63d'.
|
|
|
|
|
|
|
|
Te encuentras en estado 'detached HEAD'. Puedes revisar por aquí, hacer
|
|
|
|
cambios experimentales y confirmarlos, y puedes descartar cualquier
|
|
|
|
commit que hayas hecho en este estado sin impactar a tu rama realizando
|
|
|
|
otro checkout.
|
|
|
|
|
|
|
|
Si quieres crear una nueva rama para mantener los commits que has creado,
|
|
|
|
puedes hacerlo (ahora o después) usando -b con el comando checkout. Ejemplo:
|
|
|
|
|
|
|
|
git checkout -b <nombre-de-nueva-rama>
|
|
|
|
|
|
|
|
HEAD está ahora en ce4a63d Work with postgreSQL and create the robots
|
|
|
|
```
|
|
|
|
Yo entiendo que ese mensaje nos dice esencialmente que puede quedar trabajo perdido si trabajamos desde ahí sin cuidado...
|
|
|
|
|
|
|
|
Estamos entonces parados en el primer commit que agregamos luego del fork. Vamos a subir en el tiempo de un commit en la misma rama:
|
|
|
|
```
|
|
|
|
$ git checkout HEAD^
|
|
|
|
La posición previa de HEAD era ce4a63d Work with postgreSQL and create the robots
|
|
|
|
HEAD está ahora en 4b39b93 Merge pull request #5 from stuvusIT/fixes
|
|
|
|
```
|
|
|
|
Estamos entonces en el último commit de la rama master al momento del fork. Podemos verificar que es un commit del equipo del repo forkeado:
|
|
|
|
```
|
|
|
|
$ git log -1
|
|
|
|
commit 4b39b936d8f2263109e7de016ff8bf9585f973a3 (HEAD)
|
|
|
|
Merge: 1477c34 3c50eb9
|
|
|
|
Author: Janne Heß <janne@hess.ooo>
|
|
|
|
Date: Fri Jun 21 18:06:45 2019 +0200
|
|
|
|
|
|
|
|
Merge pull request #5 from stuvusIT/fixes
|
|
|
|
|
|
|
|
Add fixes
|
|
|
|
```
|
|
|
|
Pues es ahí que podemos crear nuestra rama `upstream-master`, y pararnos en ella:
|
|
|
|
```
|
|
|
|
$ git branch upstream-master
|
|
|
|
$ git checkiut upstream-master
|
|
|
|
```
|
|
|
|
Rama así bien injertada en el arbol del repo, de manera a que se actualice sin conflicto:
|
|
|
|
```
|
|
|
|
$ 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`).
|
|
|
|
|
|
|
|
Ahí sí conviene, no re-escribir la histria, sino corregir una versión mal reportada de la historia.
|
|
|
|
|
|
|
|
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:
|
|
|
|
```
|
|
|
|
$ git checkout upstream-master
|
|
|
|
$ git branch upstream-master-adulterada
|
|
|
|
```
|
|
|
|
Ahora sí, seguro no perdemos nada. Empezamos por encontrar de la misma manera la bifurcación entre la rama `upstream-master` y `upstream/master`:
|
|
|
|
```
|
|
|
|
$ git log upstream/master..upstream-master --oneline | tail -1
|
|
|
|
xxxxxxx Bla Bla Bla
|
|
|
|
$ git checkout xxxxxxx
|
|
|
|
$ git checkout HEAD^
|
|
|
|
```
|
|
|
|
Y ahí es que borramos la falsa historia:
|
|
|
|
```
|
|
|
|
$ git reset --hard
|
|
|
|
```
|
|
|
|
Y ahora la actualizamos con la versión del upstream que nunca hubiera debido dejar de reflejar fielmente:
|
|
|
|
```
|
|
|
|
$ git pull upstream/master
|
|
|
|
```
|
|
|
|
|
|
|
|
### Perderle del todo el miedo al rebase
|
|
|
|
|
|
|
|
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?
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Lo que propone ese artículo es que, al momento de llevar a master una rama de feature, conviene agrupar todos los commits en un solo juego de modificaciones.
|
|
|
|
|
|
|
|
A la fecha de hoy, nuestra rama master se recorre en 775 commits:
|
|
|
|
```
|
|
|
|
$ date
|
|
|
|
mié feb 12 23:30:12 -03 2020
|
|
|
|
$ git log --oneline | wc -l
|
|
|
|
775
|
|
|
|
```
|
|
|
|
Probablemente sea una historia que se cuente mejor en menos capítulos. |
|
|
\ No newline at end of file |
