Gastón Ramos

"La mayoría de las gaviotas no se molesta en aprender sino las normas de vuelo más elementales: como ir y volver entre playa y comida. Para la mayoría de las gaviotas, no es volar lo que importa, sino comer. Para esta gaviota, sin embargo, no era comer lo que le importaba, sino volar. Más que nada en el mundo, Juan Salvador Gaviota amaba volar".

Git tip: Deshacer un merge o pull

Lo que sigue es una traducción hecha por mí de una parte de “man git-reset”, es útil por ejemplo cuando estamos en una rama local
y hacemos git pull y tenemos un conflicto y en el caso de que nuestros cambios locales no nos interesen:

               $ git pull                         (1)
               Auto-merging nitfol
               CONFLICT (content): Merge conflict in nitfol
               Automatic merge failed; fix conflicts and then commit the result.
               $ git reset --hard                 (2)
               $ git pull . topic/branch          (3)
               Updating from 41223... to 13134...
               Fast-forward
               $ git reset --hard ORIG_HEAD       (4)

1. Intentar actualizar desde el upstream resultó en montón de conflictos; vos no estás listo para perder un montón de tiempo en mergear ahora, entonces decides hacer esto más tarde.

2. “pull” no ha hecho el merge commit, entonces “git reset –hard” que es sinónimo de: “git reset –hard HEAD” limpia el desorden desde el índice en el working tree.

3. Mergear el topic-branch en el branch actual resultó en un fast-fordward.

4. Pero decidiste que el topic- branch no está listo para abrirlo al público aún. “pull” o “merge” siempre dejan el tip original del branch actual en ORIG_HEAD, entonces haciendo reset hard hacia este va a dejar tu archivo de índice y el working tree de nuevo en ese estado, reseteando el tip del branch a ese commit.

Qué es el archivo índice de git?


fast-forward-git-merge

Pasión, el mundo de los hackers

Hace un tiempo bastante considerable tuve que ir a trabajar a las oficinas de una empresa de desarrollo bastante conocida de USA, era mi primer viaje fuera del país. Acortando todos los trámites del viaje Santa Fe – Bs As – Bs As – Estados Unidos, en realidad fué mucho más complicado dado que mi vuelo tenía 3 combinaciones. Al llegar a la empresa en cuestión me presenté y me llevaron con dos tipos, no importa los nombres, pero eran dos tipos con cargos mas o menos altos ahí adentro, ellos me preguntaron que era lo que yo hacía, mi experiencia, entonces les conté un poco lo que me acordé y lo que pude explicarles en el idioma de ellos (inglés) que en ese momento creo que era bastante peor que mi nive actual que ya es bastante malo.
Luego me llevaron al lugar dónde se trabajaba, que era una oficina gigante con más de 50 personas trajando juntas (primer punto en contra). La cuestión que después de que estos dos grandes genios de la programación decidieran cual era el equipo más adecuado, yo ya estaba laburando ahí. Fueron pasando los días y yo pasaba mi tiempo adentro de una oficina muy lujosa, dónde podías desayunar una comida espectacular si llegabas a las 8:30, dónde había heladeras con frutas, snacks y gaseosas gratis todo el tiempo, programando con tipos que no conocía.
La forma de trabajo era la siguiente: Llegábamos y teníamos una reunión stand up general que terminaba con un aplauso único motivador, en esta reunión se comentaban las cosas que de interés para todos los equipos, cosas nuevas, problemas solucionados, etc. luego de esta reunión cada equipo se iba la reunión stand up particular, con la típica estructura (qué hice ayer, que voy hacer hoy, que problemas tuve) luego de la stand up se armaban los pares, a… no les dije? en esta empresa se trabajaba de a pares siempre, y trabajar solo en algo era algo raro y hasta te diría no muy bien visto. Luego de estas reuniones
existían otras, de las que me acuerdo: IPM, Retro, Post-Mortem, Charlas de mediodia (durante el almuerzo), seguramente me estoy olvidano varias.
Continuando covenciendo-hackers-600x310n las prácticas, que eran: Test Driven Development (No tan test driven), poco y nada de refactoring, diría más nada que poco, miedo a cambiar, jugar al ping pong (esta es la que sí me gustó) etc.
Ahora bien, pese a todas estas prácticas de desarrollo “ágil” y todas las cosas extras, comida, ping pong, guitarra, charlas, etc, etc.
Hay algo que no pude encontrar en ninguna de las personas que trabajaba ahí y es Pasión, podemos hacer todas las prácticas que se nos antoje pero si no estamos entusiasmados y en consecuencia motivados con lo que estamos haciendo es muy difícil que las cosas salgan bien, el código que escribían ahí era un código de mierda, nadie estaba entusiasmado por mejorar nada y ni que hablar de cambiar una gema o intentar un refactoring.
Parece que esta empresa tiene buen marketing, hay otras empresas que intentan hacer el mismo proceso con la misma cantidad absurda de reuniones, con horarios extremadamente duros, estructuras, jefes, cosas que no se pueden tocar. Amigo, el mundo de los hackers no funciona así y eso se ve claramente reflejado en el código.