| ... | ... | @@ -357,7 +357,7 @@ Y ahora la actualizamos con la versión del upstream que nunca hubiera debido de |
|
|
|
$ git pull upstream/master
|
|
|
|
```
|
|
|
|
|
|
|
|
### Perderle del todo el miedo al rebase
|
|
|
|
### Perderle del todo el miedo al rebase (WIP)
|
|
|
|
|
|
|
|
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/).
|
|
|
|
|
| ... | ... | @@ -365,7 +365,7 @@ Lo que conviene entender de ese título es que en muchos casos, es bueno poner o |
|
|
|
|
|
|
|
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.
|
|
|
|
Lo que propone ese artículo - pero nadie está diciendo que sea lo que tengamos que hacer - 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:
|
|
|
|
```
|
| ... | ... | @@ -374,4 +374,4 @@ 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 |
|
|
|
Probablemente sea una historia que se cuente mejor en menos capítulos. Esto último son elementos de reflexión para ir estableciendo nuestros protocolos de trabajo. |
|
|
\ No newline at end of file |