Gapand - por qué odio git?
1 recomendación904 vistas
El documento detalla la experiencia negativa del autor con Git, una herramienta de control de versiones. A lo largo del texto, se enumeran dificultades y frustraciones personales con comandos y configuraciones complicadas, así como la transición a Git como sistema de gestión de código en su entorno laboral. Se concluye con un mensaje sarcástico sobre el uso y la popularidad de Git en el desarrollo de software.
Gapand - por qué odio git?
- 2. Por qué odio GIT
- 3. Fernando Escolar Development & Cloud Lead Consultant fernando.escolar@tokiota.com @fernandoescolar
- 4. TOKIOTA, the Microsoft leading partner for innovative technology solutions, empowering our customers while taking care of our people.
- 6. Se funda el centro nacional de supercomputación En Barcelona
- 7. Apple Lanza MacOS X 10.4 Tiger y el iPod 5G
- 8. Lo peta en el mercado con sus modelos N70 y N90 Nokia
- 9. Sony Computers Lanza la Play Station Portable
- 11. Microsoft .Net Framework 2.0 Visual Studio 2005
- 12. Visual Source Safe, Subversion, CVS… SCM’s
- 13. Y entonces…
- 14. Linus Torvalds comienza a desarrollar “GIT”
- 16. Menos mal que le cambiaron el logo
- 17. Cuentan las leyendas que lo hizo en un fin de semana…
- 19. Años más tarde…
- 20. Microsoft incorpora GIT en todas sus herramientas de desarrollo…
- 22. Vamos a montar GIT como nuevo SCM corporativo. Todos a migrar!!!
- 24. </>Después de muchos meses
- 25. 7 razones por las que GIT me ha destrozado la vida
- 27. Ya no puedo irme pronto a casa
- 29. clone # este comando lo usamos para conectarnos con un repositorio de git $ git clone my-remote http://my-git.com/repository
- 31. El código ya no es mío
- 33. remote # con esto añadimos otro repositorio servidor con alias "tokiota" a nuestro repositorio local $ git remote add tokiota https://tokiota.com/gits/repo.git # así listamos todos los servidores que tenemos asociados $ git remote -v
- 35. Me he quedado sin café!!
- 36. Diferenciales en forma de snapshots
- 37. # comando para recoger los cambios del servidor $ git pull my-remote pull
- 38. Las branches son solo un estado
- 39. branches# así creamos una rama $ git checkout -b my-branch # así cambiamos a esa rama $ git checkout my-branch
- 40. No me fio de las personas que no beben café
- 42. Me obligan a practicar TDD
- 43. commit local # creamos un conjunto de cambios con el comentario entrecomillado $ git commit -m "#Tarea - Red" # otro commit para cuando pasan los tests $ git commit -m "#Tarea - Green" # creamos el último conjunto de cambios $ git commit -m "#Tarea - Refactor" # enviamos todos los commits locales al servidor $ git push my-remote
- 46. logs # así sacamos los commits de la branch actual $ git log commit a8a7bfff366350be2e7c21b8de9cc6504678a61b` Author: Me <me@me.com> Date: ... commit e5e3e4c1ef46ae64aa08e8ab3f988bc917ee1ce4 Author: Me <me@me.com> Date: ... ...
- 47. Gitar Hero
- 49. Perseguido La culpa es siempre mía, me siento
- 50. # Esto: $ git pull my-remote # Es aproximadamente esto: $ git fetch my-remote $ git merge my-branch fetch & merge
- 52. Es complicado Muchos comandos y parámetros
- 53. Ejemplo Echar para atrás un commit
- 54. # Desatachamos el HEAD, que es lo mismo que no tener ninguna rama desprotegida: $ git checkout dd1d7ab32 # si quieres hacer cambios mientras estás en este estado extraño: $ git checkout -b old-state dd1d7ab32 temporalmente
- 55. # Primero no tendrás que tener nada modificado. Todo en commits. # Después borramos el cambio: $ git reset --hard dd1d7ab32 # Si quieres guardar el código modificado, porque no quieres hacer un commit: $ git stash git reset --hard dd1d7ab32 git stash pop si no hemos publicado
- 56. # Esto crea 3 commits separados que desacen los commits indicados: $ git revert a867a4ad 25eff4ca a766c053 # También lo podemos hacer por rango. Borrando los dos últimos commits: $ git revert HEAD~2..HEAD # O podemos tirar para atrás un commit de tipo MERGE: $ git revert -m 1 <merge_commit_sha> si ya está publicado
- 57. Comando base Resultado inutil Comando útil Resultado esperado git branch foo Creates a branch but does nothing with it git checkout -b foo Creates branch and switches to it git remote Shows names of remotes git remote -v Shows names and URLs of remotes git stash Stores modifications to tracked files, then rolls them back git stash -u Also does the same to untracked files git branch Lists names of local branches git branch -rv Lists local and remote tracking branches; shows latest commit message git rebase Destroy history blindfolded git rebase -i Lets you rewrite the upstream history of a branch, choosing which commits to keep, squash, or ditch. git reset foo Unstages files git reset –hard git reset –soft Discards local modifications Returns to another commit, but doesn’t touch working directory. git add Nothing – prints warning git add . git add -A Stages all local modifications/additions Stages all local modifications/additions/deletions Hall of shame
- 58. No voy a usar herramientas de 3os Atlasian SourceTree gitkraken Visual Studio
- 60. En resumen
- 61. Linus Torvalds no es tu amigo
- 62. No importa no estar alineado con todo el mundo
- 63. No le digas a todo el mundo que GIT mola
- 64. publicidad gratuita Deja de darle
- 65. No uses GIT
- 66. Preguntas
- 67. </ironic>
Notas del editor
- #15: Posiblemente porque se aburría.
- #16: Según comenta el propio señor Torvalds, lo diseñó pensando en sus necesidades. Esas que no le aportaban otros SCM. Su idea era que fuera distribuido, fácil, rápido y poco pesado... Y la lunaaaa!!!
- #18: Cuentan las leyendas que lo hizo en un fin de semana y ahora ya no trabaja en ello.
- #19: Quizá esto le debería hacer perder credibilidad a la herramienta. Pero por lo visto causa el efecto contrario.
- #22: Pero no lo sabíamos entonces…
- #28: Antiguamente usábamos un sistema centralizado en el un servidor. Cuando no funcionaba internet, no podías trabajar. Visual Studio te daba problemas. Lo único que podías hacer era trabajar offline. Y las vueltas a online solían ser bastante dolorosas. La única solución razonable era irte a casa o tomar unas cervezas.
- #29: Pero Git es distribuido. Esto se traduce a que cuando te “clonas” un repositorio en tu ordenador, automáticamente estás creando un repositorio como el del servidor. Pero de forma local. Así trabajas en tu máquina hasta que decides sincronizar con el servidor todas las modificaciones que has realizado. Las consecuencias de esto son nefastas: ya no te puedes ir a casa. Aunque no tengas conexión, puedes seguir trabajando. Ya sincronizarás más tarde.
- #32: En este punto, supongo que más de uno se estará preguntando: ¿Qué es eso de que los cambios los guardas en local? ¿Cómo que subes cuando quieres? ¿Un desarrollador puede tener un cambio y no subirlo hasta final de mes? ¿No tiene por qué guardar directamente los cambios en el servidor?. Es evidente que quien desarrolló Git no tiene claro el concepto de Continuous Integration…
- #33: Dentro de estas funcionalidades absurdas, encontramos que un repo Git puede tener varios “remote”. Un “remote” es un servidor con el que sincronizar el repositorio local. Y un mismo repositorio que tienes en local puede estar vinculado con varios servidores diferentes.
- #34: Ahora me imagino a un proveedor diciendo que guardan en sus servidores el código que están escribiendo para nosotros. Y que nos digan que ya sincronizarán con nuestros servidores de vez en cuando… De eso nada. Les estamos pagando. Por lo que ese código es nuestro. No queremos que lo tengan en sus servidores.
- #36: Mi rutina diaria siempre ha sido muy normal. Me gusta llegar a trabajar por la mañana, encender el ordenador y le darle a descargar la última versión del código. Mientras, me acerco a la cafetera y me tomo un ristretto. Para cuando vuelvo a mi puesto, terminan de descargarse los últimos datos.
- #37: Git me ha robado el momento zen del café matutino. Internamente maneja un tamaño de paquetes diferenciales (snapshots) que imagino que serán bastante pequeños. Espero que no pierda cambios por ello. El resultado es que las descargas no dan tiempo a ese café. Y me dejan sin excusa para tomarlo.
- #39: Otro café que ya no me puedo tomar es el de cuando te descargas una branch. Mientras se descargaba podías tener una conversación interesante con los compañeros. Eso también lo hemos perdido. Git maneja un sistema de branches totalmente diferente. Para este sistema una rama es solo un punto en el camino. Marca una posición en la que se aplican solo una serie de cambios. No todos. Así que cuando sincronizas el código ya te descargas todas las ramas.
- #41: Parece que a los programadores de Git no les gusta el café. No me fío de las personas a las que no les gusta el café.
- #43: Hace tiempo que dentro del Definition Of Done figura tener pruebas unitarias para todo el código que subamos. Unas cómodas pruebas. Una vez has terminado la funcionalidad, copias el código y cambias un par de detalles. Así consigues una prueba válida rápidamente. Sin esfuerzo. Y eso sin contar con el apoyo de grandes herramientas como Pex.
- #44: Pues resulta que ahora como tenemos Git, no hace falta que un “commit” vaya directo al servidor. Ese cambio puede residir en nuestro repositorio local. Ahora resulta que tenemos sincronizar el código con al menos tres cambios bien diferenciados: “red”, “green” y “refactor”. Todos los desarrolladores tenemos que pensar primero en una prueba, escribirla y que no pase. Luego hacer el código necesario para que pase ese test. Para finalizar poner todo el código anterior bonito y que las pruebas sigan pasando. Lo que se conoce vulgarmente como Test Driven Development. Que te obliga a pensar más. Y en cualquier momento alguien puede revisar si lo has estado aplicando correctamente. Una verdadera caza de brujas.
- #46: Los commit se pueden aplicar sueltos. Hay bifurcaciones. Puedes montar un puzzle de cambios sin problemas. Una branch puede tener unos commits totalmente diferentes a los de otra. Además la forma de identificarlos son GUID’s. Que no sé si alguno os dice algo un GUID, pero a mi no me aporta ningún valor.
- #48: Un ejemplo gráfico, gracias a una herramienta que nos muestra un mapa de cambios. Otro ejemplo es uno de twitter: El GIT-ar Hero. Si alguien entiende algo de esto, que venga y me lo explique por favor.
- #50: La parte buena de tener semejante conjunto de cambios son los merges grandes. Creo que todos hemos vivido ese momento en el que se junta la rama de hotfix con la principal. La persona encargada suele perder algún código importante en la operación. Es la forma ideal de ocultar otros problemas y ganar tiempo en los desarrollos. Además, nadie te va a echar nada en cara porque la culpa ha sido de quien hizo el merge.
- #51: En Git esta operación de merge se realiza en el momento que descargas el código del servidor. Lo hace cada uno en local. De esta forma, los administradores de VSTS tiran balones fuera. Que los merge los haga cada desarrollador. Que nos comamos nosotros el marrón. Y lo que es peor, al haber muchos commits, es muy fácil encontrar quien ha metido la pata en el código. Sigue la caza de brujas…
- #53: No sé si os habéis percatado de que voy poniendo code-snippets a lo largo de todo este escrito. Está hecho a posta. Si hay una forma de manejar bien Git y sacarle todo el jugo es usar comandos de consola. Como si estuvieramos en el medievo. Alguno me dirá que Visual Studio tiene soporte para Git. Pero realmente no tiene todos los comandos implementados. Sí la mayoría. Pero no todos. Para hacer ciertas operaciones al final tienes que abrir la consola. También hay gente que usa Source Tree. Una aplicación de Atlassian. Me niego en rotundo a instalarme más aplicaciones… Aunque la recomiende Martin Fowler.
- #54: Dentro del mundo de todos los comandos que tiene Git, encontramos que podemos resolver un mismo problema de muchas formas diferentes. Un ejemplo sería echar para atrás un commit. Tendríamos las siguientes alternativas: