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.
- 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
O mejor dicho: 