Git para usuarios de Subversion

O mejor dicho:

Git NO es para usuarios de Subversion

Ir de svn a git, no puede ser:

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Siendo usuario SVN, Usar git traduciendo los comandos que ejecutarias si usaras svn (epic fail),
• Encontraran esa experiencia fea mientras sacan en conclusión que git posee una complejidad innecesaria y es muy difícil de usarlo

"Para un usuario de svn siempre sera mas facil usar svn que git"

Par ir de svn a git, es mejor seguir estos pasos:

• Siendo usuario SVN, leer guia "Como volverse un usuario de git"
• Siendo usuario git, Usar git de manera natural

Asi git se usaria mejor, pero quedan dos problemas:

• "Para un usuario de git siempre sera mas facil usar git que svn" , es decir, que una vez acostumbrado a git usar svn se vuelve complicado.
• Y mas importante, cambiar de el svn mindset al git mindset no es para nada algo trivial

Si se sigue insistiendo con git, como una mera variante de svn, esto es lo q podria pasar (lo mas comun):

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
• Librarse de git de alguna manera y volver al placido y reconfortante svn (o cvs :( )

O si no, esto es mas raro que pase:

• Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
• Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
• Aprender como funciona y hacer "cosas que con svn no hacia", explotar sus ventajas
• Volverse "usuario git" al "entender como funciona" a costa de todo el sufrimiento previo
• Optar por git como control de versiones preferido en todo al punto de creer que usar subversion en realidad un obstáculo

De todo esto se concluye que es muy difícil que alguna tabla de equivalencia de comandos o "mini-tutorial" sirva para que un usuario que esta cómodo con svn pueda trabajar igual de cómodo y feliz con git, o por lo menos que valga la pena el cambio, para eso un usuario debe volverse "usuario de git" antes de usarlo y/o en primeras etapas del uso de la herramienta.

Que es ser un usuario de svn y que es ser un usuario de git (mindsets)

En esta seccion me voy a referir a un "usuario de svn" a alguien que usa svn desde hace mucho tiempo, y que esta comodo y feliz con la herramienta ya que tiene ese "mindset". Lo mismo para un "usuario de git".

No obstante, la característica mas importante a analizar no es la herramienta, sino la manera de pensar las cosas, los conceptos y en ultima instancia como resuelve las situaciones del dia a dia con su herramienta favorita. Como esto no es "git evangelism", y el foco es estudiar como pasar de svn a git, sere lo mas objetivo posible

Lo mas sencillo sera mostrar la siguiente tabla:

Problema o concepto	Usuario de svn	Usuario de git
Tengo código que quiero guardar, pero "no esta listo" para integrarlo al trunk por lo que no quiero commitearlo ¿Que hago?	"Facil: tengo tres opciones: copio el codigo, y lo pego en un notepad, copio en el mismo archivo pero comentado No hago nada, porque se que puedo volver atrás con ctrl+Z crear un branch, pero preferiria que no"	"Facil: puedo commitear ya que ese commit es local, o si no también puedo crear un branch"
Estoy trabajando en una feature nueva que todavia no commitie, y alguien me pide que resuelva un bug ¿que hago?	GTFO, esperar hasta que termine la feature y haga el commit Hacer checkout del mismo repo en otro directorio, arreglarlo ahi y commitearlo Copiar el codigo a otro directorio, revertir la WC, arreglarlo ahi y copiarlo	Guardo un "stash", arreglo el bug, commit, push. restauro el stash Hago un branch
Tengo una funcionalidad a medio hacer sin commitear y me tengo que ir a mi casa, mis compañeros se quedan y podrian continuarla	No commiteo, solo yo sigo mi trabajo mañana commiteo aunque el trunk quede inestable Les doy mi computadora Hago un zip con el codigo y se los mando Me quedo hasta que pueda commitear algo bueno	Commiteo (es local) y despues pusheo a un branch asi los demas pueden seguir trabajando en el
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que tardara un mes	Ahora si se justifica crear un branch Pair-Programming y commitear cuando termine (no conviene) Fragmentar en features mas pequeñas y commitear todos los días siempre y cuando "no rompan nada"	Definitivamente hay que crear un branch
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que se completara en el dia	Pair-Programming y commit cuando se complete	Branch
Commit	"Es la esencia de esto, hay que hacer update antes del commit para integrar los cambios del servidor"	"Puedo commitear cuando quiera independientemente de que ocurra en el 'servidor'"
Branch	"Creare branches solo cuando sea estrictamente necesario (por ej: features que tardaran mucho mucho tiempo) o lo indique la gente de SCM"	"Lo mas importante es saber manipular branches, porque aparecen todo el tiempo si se trabaja de manera distribuida"
Merge	"Pasa automatico cuando hago update pero hacer un merge manual es un quilombo y tarda, por eso no convienen los branches"	"Pasa automaticamente cada vez que hago un pull y hacerlo manual es trivial y rapido"
Historia	"La historia se almacena en una secuencia de changesets, por eso cada revision tiene un numero, eso lo hace sencillo"	"La historia se almacena como un DAG (Arbol) de commits, entender eso es importante para comprender los branches"

El usuario de svn usa los sencillos comandos provistos por svn y varias herramientas mas como editores, IDE, compresores, mail, etc... para resolver los problemas del dia a dia, mientras que el usuario de git para resolver los mismos problemas diarios usa solamente git, que para ser justos, git en realidad es un filesystem mas un set muy extenso de herramientas sencillas, pero git como conjunto de herramientas es complejo, quiere ser lo suficientemente complejo y sofisticado para cubrir todas las necesidades y que no sean necesarios ni notepads, ni código comentado, ni mails, ni ctrl-Z para manejar versiones de código.

Un usuario de git estara pensando todo el tiempo que hace control de versiones en branches, para el es fundamental saber como manipular branches (crear, mergear, etc...) ya que sabe que los branches se crean todo el tiempo por trabajar de manera distribuida. Asumen el concepto de que es literalmente imposible trabajar sin branches en un equipo de desarrollo y por lo tanto no buscaran el imposible de "evitar branch a toda costa" sino solamente se dedicaran a controlar los branches que surgen para que no diverjan demasiado.

Consideran que todas las versiones son parte de un arbol que muestra la divergencia.

Un usuario de svn se enfoca principalmente en la "linea principal" y pensara en branches solo si surgen ciertas situaciones puntuales como por ej una feature que tardara demasiado tiempo (que en general es mejor evitar) o una version alterna del producto a medida. Asumen que la creación de branches siempre conlleva un overhead que en muchos casos solo sirven para complicar mas las cosas, muchos usuarios svn concuerdan en que si un branch va a durar mucho tiempo (digamos semanas) y se justifica podria aceptarse si el beneficio que se presume traera el branch supera ese overhead. Asi mismo cuando un branch se extiende en el tiempo y diverge mucho la integracion a la linea principal se vuelve mas complicada por lo que la integracion de esos "branches mounstruosos" es algo que no se busca (true story).

No consideran que la diferencia entre su working copy y lo que hay en el servidor sea un branch por que commitear y updatear es mucho mas facil que manipular branches.

Ven las versiones del repositorio como algo lineal

¿ Que pasa cuando hay que usar una herramienta "diferente" ?

Si un usuario svn, pasa a usar git con la consigna "reemplazo svn con git en mi set de herramientas", se encontrara que la complejidad de git, que es mayor que la de svn, sumada a la complejidad de las herramientas que esta acostumbrado a usar (bloc de notas, mails, etc...) se convertira en una molestia y no podría trabajar bien. Mientras que un usuario habituado a git, usa git para una mayor cantidad de cosas aprovechando al maximo posible las posibilidades de la herramienta (que son la cara buena de esas complejidades) y no permitiendo que surja necesidad de usar algo adicional, asi es como muchos se maravillan con git mientras otros no entienden porque si git es tan complicado.

Por ejemplo, a un usuario svn generalmente no se le ocurriría crear branches de corta duracion, porque tiene la idea de que son complicados y no valen la pena, ahi habria una ventaja que no se aprovecharía (mientras que lidear con muchas de las cosas complicadas esta implícito en el uso dirio). A alguien habituado con svn tambien le causaria mucha confusion el hacer un git pull y que el merge automatico no funcione, que se haya arrepentido o lo que sea ya que lo que hay en git no puede ser visualizado con un modelo lineal.

También es complicado para un usuario de git trabajar con svn, ya que tiene la costumbre de manejar el versionado de código solamente con una herramienta, se encontrara con que en svn los branches cortos no valen la pena y que hay muchas herramientas que faltan en comparación con git al que esta habituado y como esta acostumbrado a usar git todo el tiempo casi no conoce de herramientas "extras" y trabajar con svn le seria dificil.

Por eso el philosoraptor de la imagen se pregunta porque no existen manuales de svn para usuarios de git (mas bien seria manuales de las herramientas adicionales que hacen falta para complementar svn) si existen manuales de git para usuarios de svn.

Conclusión, como pasar de svn a git

• Comprender que con git las cosas se hacen diferente, que hacerlas "a la vieja usanza" es mas complicado que con la herramienta de siempre
• Abordar git de cara a las ventajas (ej: branching, merging, distribuido, forks, staging area, versionado local, etc...)
• Cambiar la manera de hacer las cosas, para aprovechar funcionalidades de git (no pensar, tal funcionalidad no la uso porque así no hago las cosas, cambiar la manera de hacer las cosas)
• Pensar "out of the box", estar listo para cambiar las estructuras de pensamiento mas elementales
• Al enfrentarse a complejidades adicionales que no había en svn, buscar comprender porque es asi, como eso se relaciona con ventajas de la herramienta y como aprovechar esas ventajas
• Ver las versiones como un arbol y manipularlas de esa forma. NO tratar de que las cosas funcionen como en svn (por ej: no pretender que git pull funcione como svn update porque son cosas diferentes)
• Invertir tiempo, mucha gente que usa git dice que lo vale. No existe una manera rápida de aprender git pero el aprenderlo vale la pena

Links

Libro GitMagic: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/es/book.pdf

Libro ProGit: http://progit.org/

Blog GitEvangelism: http://gitevangelism.blogspot.com/

Generador de memes: http://memegenerator.net/

¡concluyo CodeCamp 2011!

Y me puse la camiseta para dar una charla de git, junto con mi colega Nico Paez, quien obviamente no tardo en escribir este post acerca del tema (les recomiendo visitar el post ya que da acceso a interesantes recursos)

La charla que di

Gestion de la configuracion con nuget y Git (si, nuget tachado), la charla mas que nada empezo siendo iniciativa de Nico Paez quien se ve que la tiene muy clara en la oratoria sobretodo en lo didactico (enseña en la UBA) y se logro una exposicion muy copada, a pesar de que realmente no nos alcanzo el tiempo (esto mas bien significa que teniamos mucho para decir, y que sobre siempre es mejor a que falte ;) )

Cabe aclarar que Nico posee profundos conocimientos de muchos otros temas (los que hicieron posible la presentación). Aun asi, sus conocimientos de git todavia no son suficientes para que pueda ver 100% de las ventajas que git ofrece y tuve que dar un empuje (push?) en ese sentido en etapas de preparacion de la presentacion.

A los planteos de "seguir el tema", lo mas probable es que escriba algunos cuantos post, con resumenes tecnicos y continuando lo que quedo pendiente de la charla y no pudo ser en el momento

Por ultimo quiero felicitar a Nico Paez pues ha sido un gusto compartir esa actividad y tuvo mas aceptacion de lo que me imaginaba (vean los smiles en la foto). Ademas saque una enseñanza importante acerca de las presentaciones con diapositivas:

NO hay que poner diapositivas llenas de texto porque distraen al publico de lo que el/los oradores dicen, hay que recurrir a graficos, o a titulo sencillos que indiquen de que se esta hablando, en ocasiones yo como publico tambien me distraje leyendo diapositivas con texto

Links de la charla:

Post en el blog de Nico con el quickstart de git

Diapositivas usadas en la sesion

Las charlas a las que fui

Actualizacion: Ahora si funciona el sitio codecamp, talvez el dia de la jornada quedo saturado, ahi agregue los links

Desarrolla con Node.js + HTML5 + Windows Azure juegos multiplayer realtime y seras millones

¿Que mas hay que decir? ¡Juegos multiplayer! ¡Sentencias/presagios de muerte para flash! ¡Java Lopez! De chico tenia el berretin de hacer jueguitos, despues los hice con QBasic (me siento viejo :S) , despues con VB, despues con Div Games Studio, pero estas historias son para otro post. Lo importante es que volver al mundo del desarrollo videojueguil con esta clase de tecnologias (HTML5 y demas yerbas) seria volver por una de las puertas grandes

Desarrollo de juegos con XNA para WP7 y XBOX

Impresionante charla, queria saber en que estado estaba eso del XNA. Y por lo visto logran cosas muy copadas (con 3D y todo), pero para mi gusto demasiado exclusivo de plataformas microsoft, por el momento me inclinaria mas al HTML5 con javascript, o Java, algo que corra "en todos lados"

C++, el fantasma de las natividades pasadas, presentes y futuras

El pasado lo conociamos casi todos (esta en los libros), el presente lo vi (y no me gusto), a mi y a la mayoria de los presentes en esa charla nos intrigo el futuro,

A mi me gusto la charla, me entere de cosas que no sabia que existian (¡C++ tiene lambdas!) y tambien de cosas del nuevo c++ que hay en windows 8, que no tiene garbage collector ni es managed (a cambio tiene la mega-performance y el bajo nivel) pero tiene reference counting integrado con el lenguaje, interaccion casi "magica" con cualquier otro lenguaje como por

ej javascript y seguro un monton de cosas mas que el tiempo no da para explicarlas todas en una sola charla.

No me gusto cierta parte del mensaje tanatico, si puede llamarselo asi, que anuncia que "todo estara en c++" (igual solo es una forma de decir), fuera de ese detalle la charla me gusto bastante y el c++ con todas las implementaciones a nivel IDE que agregaron ahora sera mas "soportable"

Masas de desarrolladores, masas de chocolate

Masividad de desarrolladores talentosos exponiendo ideas y/o curiosos en la cacería de

conocimiento

Masividad de azucar, masas y cafe masivo... la comida/bebida

ideal para las 24x7 de la mayoria de los informaticos, y que en realidad no llevan a la practica por falta de dinero/infraestructura hepatica capaz de procesar toneladas de glucosa diaria

Disclaimer: no llegue a sacarle fotos a las masas, pero eran del estilo de las que se ven en la foto y eran ricas

Unicas Criticas

A la tarde se acabo la azucar (o no se conseguia) para el cafe :(, lo perdono al considerarlo tambien una buena medida para controlar el consumo adictivo de glucosa (combinado con el sedentarismo tipico de la profesion IT puede llegar a ser dañina) y teniendo en cuenta de q las masas ya proveian la sobredosis necesaria de glucosa

No podia ir a las 10 charlas que habia en cada horario a la vez, si bien no eran todas taaaaan interesantes, habia horarios en los que era muy dificil decidir entre dos o tres sesiones interesantes que habian al mismo tiempo

Anti-Pattern legacy: making a zip in the era of DVCS

Un anti-patrón es una solución repetitiva incorporada o aprendida para la cual se demostró que lejos de resultar una buena solución para un problema (como aparentaría en un principio) genera mas problemas que los que soluciona.

Mientras que el concepto se popularizo como anti-patrón de diseño con orígenes en el libro Design Patterns, el concepto de anti-patron se utiliza en variedad de escenarios como en la programación (ej: el infame Codigo spaghetti), project managament (ej: Groupthink)

Anti-Patrones como Patrones Legacy

Algunos (¡y muchos!) anti-patrones como Waterfall model (Desarrollo de software en cascada), son practicas o patrones generalmente aceptados y enseñados en viejas épocas y que ahora al quedar obsoletos fueron reemplazados por otras practicas mas eficaces (Desarrollo iterativo, metodologías agiles, etc...) . A pesar de eso viejas practicas quedan en el knowhow colectivo y lo importante es saber reconocerlos como anti-patrones y no como una practica que haya que fomentar (y también saber cuales son las practicas que son convenientes por estos tiempos).

Anti-Patrones en Control de versiones

Como se había mencionado anteriormente, el concepto de anti-patrón se extendió rápidamente a variedad de entornos, siendo uno de ellos el mundo de las versiones (o como algunos le dicen, SCM), un área del desarrollo de software que crece mas lentamente que otras (el porque de esto seguramente lo tratare en algún que otro post).

A pesar de no haberse desarrollado mucho, SCM (o abreviado CM) fue un ciencia/brujería/técnica que paso por varias fases a lo largo de su historia pasando por herramientas que solo servían para trabajar individualmente, sistemas de control de versiones concurrentes para equipos (CVS :P), sistemas centralizados mas avanzados para dar mejor soporte a ramas aunque no sea lo suficientemente bueno (ej: SVN), sistemas distribuidos (ej: Mercurial) (para información detallada vean este excelente articulo acerca de la historia del source control).
Esta historia es la que habilita la posibilidad de que determinadas buenas practicas muy comunes y que resultaban satisfactorias ayer sobrevivan mas allá de su obsoletización para convertirse en anti-patrones hoy.

Los Patches que se usaban antes

Una de las practicas que fue muy utilizada durante un tiempo fueron los patches, sobretodo en los entornos de desarrollo open source, en épocas donde la internet estaba en pañales y cosas como codeplex, github, googlecode no existían ni en la imaginación (es mas, muchas de esas compañías ni siquiera existían), cuando alguien realizaba una contribución a un proyecto lo que generalmente este hacia era generar un patch (que no es mas que un .tar.gz o .zip del diff entre determinadas versiones y/o el contenido de esas versiones) y posteriormente se lo hacia llegar, era común mandarlos por email firmados, adjuntarlos en foros, BBS, etc... En definitiva, no existía el concepto de "commitear a un repo en la nube".

El "Make a zip" que se usa ahora

Posteriormente exploto la internet, llegaron los servicios, se estabilizaron y herramientas como SVN pudieron cobrar mas protagonismo, yo por ejemplo usaba el servicio de http://www.assembla.com/, que por esos momentos ofrecia SVN (estamos hablando del 2006 aprox.).

Sin embargo, existía cierta "cosa" por la cual "commitear al repo" no era tan frecuente, estaba (y esta) vigente Continuous Integration, una excelente herramienta para llevar a cabo proyectos integros aprovechando al máximo un versionador, pero que inadvertidamente dejaba varios asuntos de lado.

Uno de esos asuntos es el intercambio de código "unmanaged", es decir, código que no debería ser parte de la mainline en ese momento, pero que lo seria en el futuro o que tiene que por diversas razones tiene que "estar en algún lugar".

Noten que hasta el momento no use la palabra con B.

Entonces, generalmente es fácil caer en este razonamiento: "Si ahora se esta usando un repositorio para compartir una mainline, y eso es fabuloso, entonces como envió el código que no tengo que commitear por H o por B razon ? Uso lo que ya conozco, y hago un patch para poder enviar el contenido" ( o en otras palabras, hacer un zip ) lo cual parece que es algo bueno porque era una practica normal y promovida en las viejas épocas, y al trabajar con sistemas de control de versiones centralizado como el mas popular de esa generacion (svn) incluso yo creo que trabajar con codigo "unmanaged" de esa forma es mas practico que hacer branches la mayoria de las veces.

DVCS's y la palabra con B

Pero la practica de realizar patches, en DVCS's como Mercurial o Git solo existe como una practica legacy, un anti-pattern (aunque siempre habrá excepciones, pero deben ser las menos y muy poco frecuente). En herramientas distribuidas de versionamiento, las soluciones alternativas al problema del código "unmanaged" están a mano y es mas facilitada por la herramienta que ofrece alternativas mas practicas que el uso de patches, mails con código o archivos zip y por supuesto mas practicas que las soluciones ofrecidas por herramientas de generaciones anteriores.

Intercambiar código con otros desarrolladores solamente a travez del repositorio y usar otros métodos solo para los que por alguna razón no puedan, no deseen, o no sepan como acceder al repositorio.

Deshacer el push en git

Actualizacion: Quick fix

Alguien pusheo commits que no debia, o por alguna razon se pretende "deshacer" commits que ya se enviaron al servidor central.

Quick fix

Buscar el commit a donde se pretende volver: (usar git log o git reflog, etc...), y despues hay que ejecutar estos commandos (donde a_donde_volver se reemplaza por el commit):

git reset a_donde_volver
git checkout HEAD .
git push --force

Y a trabajar

NOTA: usar --force solo para casos especificos como este, ya que directamente sobreescribe cambios en la rama remota (que es lo que se pretende hacer en este caso)

Narrado (for dummys)

Todo lo que voy a explicar es asumiendo que se esta trabajando en la rama master (que es la default en git), si no estas trabajando en la rama master, el comando "git branch" muestra la rama de trabajo en la que estas trabajando

Antes, que nada, se puede hacer un tag del master actual:

git tag ultimo_master master

Posteriormente, hay que encontrar el commit al cual se quiere volver, se pueden revisar los logs (el nombre de la rama es opcional, si no se indica usa la rama de trabajo actual):

git log [master]

Supongamos que el commit al que se quiere volver es 0123456789abcd..., puede ser util taguearlo para referenciaro facilmente mas adelante (aunque se puede hacer todo referenciando al commit, directamente)

git tag a_donde_volver 0123456789abcd...

Posteriormente, se hace un reset a para que la rama master local referencie a ese commit, y despues un checkout para cambiar los archivos y que coincidan

git reset a_donde_volver
git checkout HEAD .

Despues, hay que sobreescribir la referencia master remota con la actual, pero hay que usar --force para que git no verifique si se trata de un fast-forward (porque sino rechaza la operacion), recordar usar --force solamente en casos especificos como este.

git push --force

Y despues se puede seguir trabajando normalmente

Bonus track

Puede ser util crear un branch en el servidor a partir del master original antes de que se revierta (para poder analizarlo entre todos, etc...), para hacer esto:

git push origin ultimo_master:refs/heads/old_master

Y en este post explico como usar los branches:

http://nilclass.blogspot.com/2009/08/branches-remotos-en-git.html

En github solo se tarda 60 SEGUNDOS

Esta mañana, entre a la internet con la idea de migrar un proyecto que tenia en googlecode (con svn) a git (y el mas conocido repositorio gratuito en internet de git es github)
El hecho de tener que migrar commits de svn a git ademas de la registracion, setup del repo git y demas cosas me hacian imaginar q seria una experiencia de trabajo.
Pero me soprendi: no solo registrarse y crear el repositorio fueron tres simples clicks, sino que tambien hay literalmente un boton "migrar SVN a GIT" en el cual solo te pedia la url del servidor svn... tras la operatoria (que encima fue rapida), pude ver mis commits convertidos a git.
Asi que el que este entusiasmado con git, sabe que no solo puede registrarse facilmente a un repositorio git gratuito sino que puede tambien migrar cualquier repositorio de svn para no perder la valiosa informacion de los commits en la mudanza.

Enlaces:

GitHub:
http://github.com/

GoogleCode ( Aun asi esta bueno si quieren usar un repo svn y el issue-tracker les puede gustar :) ):
http://code.google.com/

Analisis de mergeo en git

Cada vez que se mergea una rama en otra, es necesario conocer que modificaciones se estarian introduciendo concretamente en la rama de destino antes de proceder al mergeo mismo.

El comando git-merge-base permite saber cual es el "common parent" de dos commits dados, es el "merge-base" el que define que segemento de cambios se incluiran al hacer el mergeo.

Supongamos que se quiere mergear a la rama xxxxx, los cambios de la rama yyyyy, pero antes se desea conocer que cambios se incluiran

# se cambia la rama de trabajo a yyyyy
$ git checkout yyyyy

# se busca el "merge base
$ git merge-base HEAD xxxxx
123456789abcdef

# se analizan los cambios que se incluiran viendo el segemento de cambios desde el merge-base
# hasta el ultimo commit de xxxxx
$ git log 123456789abcdef..xxxxx
( aparece una enumeracion de los commits que se van a incluir si se procede al mergeo)

# o tambien, se podria
$ git log $(git merge-base HEAD xxxxx)..xxxxx
( aparece la misma salida que del comando anterior)

# si se aceptan los commits vistos en el log, se procede al mergeo
git merge xxxxx

NOTA: Ademas de usar estos practicos comandos ayuda bastante mantener una nomeclatura y una gestion ordenada de las ramas que permitan tener en claro cuales son los "merge-base" de los mergeo que se ejecutaran.

Recuperar commits "perdidos" en git

Cada tanto puede pasar que de checkout en checkout, nos encontramos con:

"¡oh no!, todos los commits que hice hoy no estan en la rama, incluso nisiquiera se donde estan"

Pareciera que todo el trabajo del dia quedo "perdido", pero no es asi, si se commiteo, esos commits estan en alguna parte... quiza no apuntados por ninguna referencia, pero estan.

Una de las maneras mas practicas de encontrarlo es usando el comando

git reflog

Que da por salida un registro de las operaciones que se hicieron, algo como esto:

8705300... HEAD@{0}: commit: aplicado metodo para desactivar los metodos privado
104683b... HEAD@{1}: commit: corregida restauracion de constantes
0a714ab... HEAD@{2}: commit: corregido error
f47b0e6... HEAD@{3}: commit: implementado metodo para activar y desactivar privi
7760e03... HEAD@{4}: commit: definido metodo permit, para definir muy facilmente
2936507... HEAD@{5}: commit: renombrado metodo para preguntar el permiso para ej
93757af... HEAD@{6}: commit: agregados enable y disable privileges con prints
4a2e9c3... HEAD@{7}: commit: agregado metodos para crear bloques unprivileged y
f19eb66... HEAD@{8}: commit: completado holder de manera que puede tener el codi
abc82d0... HEAD@{9}: commit: separado metodo create_holder
5185142... HEAD@{10}: commit (initial): primer commit

Incluye los "SHA1" de los commits hechos recientemente, de los cuales se pueden tomar los cambios y enviarlos al lugar correspondiente con git merge, crear branches o lo que sea necesario hacer.

Tags remotos en git

Correccion: parametros de git push cambiados para que el envio de la ref sea mas propio

Otro elemento importante que aporta el versionador git, son los tags... No es muy intuitivo tampoco como hacer que los tags sea remotos, pero es parecido a como se hacen los branches e incluso mas simple (ya que no hay nada que trackear)


1) Enviar al repositorio central el ref de ese tag (en el ejemplo es el actual commit)

git push origin HEAD:refs/tags/nombre_del_tag

Este comando envio el "ref" local refs/tags/nombre_del_tag al servidor con el nombre refs/tags/nombre_del_tag
Cuando alguien haga pull del repositorio central recibira los tags y va a poder trabajar con ellos como si los hubieran creado con git tag en su repositorio.

Branches remotos en git

Git es un poderoso sistema de gestion de versiones, que entre otras cosas, esta pensado para gestionar branches ( cosa que por ej svn no tiene ), al ser git descentralizado y al ser de uso comun con varios repositorios para un mismo proyecto, surge la necesidad de crear ramas de manera distribuida tambien, algo que no es muy intuitivo.

1) Con git push se crea el branch en el repositorio remoto (en este caso origin), asi de simple

git push origin HEAD:refs/heads/nombre_del_branch

2) Despues tenemos que asegurarnos de tener actualizado el repositorio

git fetch origin

3) Verificamos que el branch remoto ha sido creado

git branch -r

4) Generar un branch local que "trackee" el branch remoto

git checkout --track -b nombre_del_branch origin/nombre_del_branch

Ese ultimo comando crea un branch local que "trackea" el branch que se creo antes en el repositorio remoto. Y con trackear implica que los cambios y commits del branch remoto vendran a este branch local al hacer git pull e iran de nuestro branch remoto al hacer git push.

Fuente: http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/

Aprendiendo git-svn en 5 minutos

Este finde estuve viendo las posibilidades que tiene git-svn, nunca use git pero me llamo mucho la atención el manejo que tiene de múltiples repositorios, cuya primera utilidad que le vi es poder trabajar "offline", es decir, sin acceso al repositorio central, y mantener la granularidad de los commits ya que se puede commitear al repositorio "local" cuantas veces se quiera hasta que en un momento se mandan todos los commits en un "push". En el caso de git-svn, se pueden visualizar y analizar en los logs del servidor SVN cada uno de esos commits como si hubiese mandando cada uno de ellos de manera "normal". git-svn también puede ser de agrado para los fanáticos de git cuando se vean forzados a trabajar con un repo svn y seguramente tiene un sin-fin de utilidades mas.

Actualizacion: Usuarios de svn pueden aprender git de una manera muy facil en Git - Svn Crash Course

Lo primero y principal para utilizar esta herramienta es instalarla, yo que uso fedora, me basto con:

yum install git-svn

Seguramente, para los usuarios de debian y afines sera suficiente (corrijanme si me equivoco):

apt-get install git-svn

Posteriormente, se aprende como utilizar la herramienta para clonar un repositorio SVN para los usuarios de git, o "checkautear" usando git, para los usuarios de svn:

git-svn clone $URL

Donde $URL es la url completa del servidor svn como "file:///usr/srv/svn/proyecto" o "http:///www.websvn.com/svn/proyecto", lo que hace el comando, es crear una copia local del repositorio SVN, al estilo de git, esto equivale al checkout de svn y por lo tanto solo debe hacerse la primera vez, obviamente es necesario tener acceso al repositorio para poder hacer esto

A partir de haber clonado el repositorio, ya se puede trabajar con el repositorio local, para los que sean usuarios de git es simple: es lo mismo que en git (guarda al final que no se pushean los cambios de la misma manera), y para los que no conocen el maravilloso mundo de git, también es sencillo, simplemente hay que ejecutar el siguiente comando con cada commit:

git commit archivo -m 'mensaje' 

El comando es igualito al de svn, pero tengan presente de que este comando "commitea" solo al repositorio local, el que se clono al principio, asi mismo NO requiere acceso al repositorio ni ninguna conexión con el, pueden hacer este commit todas las veces que hagan faltan sin necesidad de contactar al repositorio.

Cuando logran conexión con el repositorio o cuando lo crean conveniente, llega la hora de hacer el "push" (mandar todos los commits que se hicieron local al repositorio central), el comando el siguiente:

git-svn dcommit

Cuando ejecuten el comando, verán como git-svn manda cada commit que se efecto localmente desde la que se clono el repo o se hizo el ultimo dcommit, y lo mas importante, lo que da todo el sentido a esto: a cada commit que efectuaste con "git commit", le corresponde UN commit de svn que puede analizarse y verse en los logs del servidor svn por cualquier otro usuario y con las herramientas svn clásicas.

Bueno, esto fue git-svn para Fedora 32 y espero que les haya gustado. Chau!!!