• Git es un sistema de control de versiones distribuído

Dicho de otra forma, en vez de tener un repositorio central donde están alojadas todas las versiones, ahora tenemos en nuestra máquina todo el repositorio. En concreto en Git el repositorio se aloja en la carpeta especial .git

versiones va en cursiva por que el propio Linus, creador de git, dice; "it's content-addressable, and it has a notion of versioning,"

Comandos básicos:

1 $ git init
2 Initialized empty Git repository in /Users/javi/tmp/repo/.git/
3 $ echo 'python FTW' > file
4 $ git add file
5 $ git ci -m "1st commit"
6 [master (root-commit) a9270d1] 1st commit
7  1 files changed, 1 insertions(+), 0 deletions(-)
8  create mode 100644 file

• Los comandos básicos son similares a Subversion
  • git clone url <=> svn checkout url
  • git pull <=> svn update
  • git add <=> svn add

Hay que tener cuidado, porque aunque algunos de los comandos se llaman igual pero no hacen lo mismo, por ejemplo revert.

• Flujo de trabajo pasado de moda

Comandos teniendo en cuenta que no haya conflictos:

1 $ svn checkout https://svn/trunk
2 $ cd trunk
3 $ vim file.py
4 hack hack hack
5 $ svn up # sin conflictos
6 $ svn commit -m "epic win feature, refs #1337"

• Comenzamos con git-svn: Bajamos el repositorio

Comandos:

1 $ git svn init -s https://svn/ # inicializa el repositorio git
2 $ git svn fetch # baja tooodas las revisiones

• Estado del repo

Aquí git se baja todo el repositorio, esto es, todas y cada una de las revisiones en local. Cabe la posibilidad de no bajar todo, ver las opciones del comando git-svn init. También es posible hacer git svn clone directamente.

Si solo quisiesemos bajar una parte del repositorio sería posible usando la URL a la carpeta en cuestión, de la misma forma que con subversion podemos solo bajar una parte del repositorio (mini punto para subversion).

• Empezamos a trabajar

Comandos:

1 $ vim file.py
2 hack 
3 $ git add file.py
4 $ git commit -m "refactoring"
5 hack 
6 $ git add file.py
7 $ git commit -m "improved function"

• Primeros cambios
  • add antes de commit: con svn no sólo hacemos add cuando no está bajo control de versiones

En git hay una fase intermedia entre los cambios que hacemos y el repositorio local, se llama staging area y ahí debemos aculumar los cambios que queramos almacenar en el siguiente changeset.

• cambios en el repositorio local

• Tenemos en local, pero hay que subirlo al repositorio subversion
  • Sabemos que los demás usuarios plebeyos de subversion no se merecen nuestro código de alta calidad...
  • Como siempre, bajamos lo nuevo antes de subir

Comandos:

1 $ git svn rebase

• Cosas nuevas:
  • en subversion para actualizar tendríamos svn update.
  • Nada de pull
  • rebase <- aquí paramos a discutir :)

El rebase hace la siguiente operación: - deshace los commits locales - baja la rama subversion y aplica sus cambios - re-aplica los cambios de nuevo. Sí, puede surgir conflictos

Ahora git tiene una rama remota que apunta al repositorio subversion, a la rama trunk, de forma que debe bajarse esa rama (puedes hacerlo con git svn fetch) y "mezclarla" con los cambios locales.

• Estado del repo

• Hemos sido buenos y hemos actualizado, toca subir nuestros cambios

Comandos:

1 $ git svn dcommit

• Estado del repo

Ahora master está sincronizada con la rama trunk

• Ahora los demás podrán hacer svn update y tener nuestros cambios
• No confundir con push

Push se usa cuando queremos enviar los cambios a un repositorio externo nativo git.

• Una de las grandes mejoras es que podemos hacer branching un poco menos doloroso
  • se pueden crear ramas desde el propio git en el repositorio svn
  • podemos crear ramas locales que "apunten" a las ramas en el repo

Comandos:

1 $ git svn branch -m "bugfix" bug_1234 
2 $ git checkout -b local/bug_1234 bug_1234

La rama no debe llamarse igual ni tener el prefijo local, se puede usar el esquema que se quiera.

Toda la versatilidad que da git la podemos aplicar sin problemas, siempre teniendo en mente que el resultado debe ir al repositorio subversion.