Repositorios de control de versiones distribuidos

Sobre mi

@ialcazar

http://farmerdev.com

spainjs.org  

madridjs.org  

Freelance

UN POCO DE HISTORIA

Introducción a los VCS

1972: Source Code Control System (SCCS): Código cerrado, libre con Unix. 1982: Revision Control System (RCS) : Multiplataforma. Open Source. Mas funcionalidades y mas rápido. Solo podía trabajar con un fichero a la vez. 1986-1990: Concurrent Versions System (CVS): Trabajo de múltiples usuarios en el mismo fichero. Open Source.

Introducción a los VCS

2000: Apache Subversion. Snapshot de un directorio no solo de un fichero. Commits transaccionales. Más rápido. 2000: BitKeeper SCM. Código cerrado, propietario. Control de versiones distribuido. Versión para la comunidad era gratis. Utilizado por el proyecto del kernel de Linux en 2002-2005.

Abril 2005: Versión comunidad deja de ser libre.

Git Hits

§  Git nace en 2005

§  GitHub nace en 2008 como hosting de repositorios git.

§  2009: Github 50000 repos y 100000 usuarios.

§  2011: Github 2M repos y 1M usuarios

ARQUITECTURA

Mira la luz…

¡Hay qué desaprender!

Hay que tener en cuenta que…

§  Git trabaja en local (repositorio local)

§  Podemos “empujar” cambios a otros repositorios (repositorios remotos)

Hay que tener en cuenta que…

Trabajamos en local

Empujamos los cambios

Snapshots

Otros VCS

Almacena información como una lista de cambios (deltas)

Snapshots

Git: Conjunto de snapshots

Toma una foto del estado de cada fichero en cada momento y almacena una referencia a esa instantanea.

Snapshots

Git: Conjunto de snapshots

Si el fichero no tiene cambios Git no lo almacena otra vez.

Instalación

http://git-scm.com/downloads

PROBLEMÁTICA DEL DESARROLLO

Trabajo con ramas

Rama estable

Rama “en desarrollo” (trunk, master, default)

Tag  v.1.0  

Trabajo con ramas

Rama estable

Rama “en desarrollo” (trunk, master, default)

Tag  v.1.0  

Funcionalidades  

Resolución  Bugs  

SERVIDORES CENTRALIZADOS

h;p://subversion.apache.org/  

Subversion

Surge en el 2000 tratando de mejorar algunas deficiencias de CVS. Su modelo, diseño e interfaz son muy parecidas a CVS.

Subversion: Pros

§  Muchas de las características de CVS.

§  Versionado de directorios, no solo ficheros.

§  Copiado y borrado son operaciones de versionado.

§  Commit atómicos: “o todo o nada”

§  Creación de ramas y tags más rápidos que CVS

Subversion: Contras

§  Las ramas y etiquetas son copias físicas de los archivos.

§  No disponible sin conexión

§  Resolución de merge puede ser problemática à trabajo solo sobre el histórico de revisiones

Subversion: Contras

En conclusión, contosa la creación de ramas

y resolución de conflictos.

CARACTERÍSTICAS DE LOS REPOSITORIOS DISTRIBUIDOS:GIT

Características

Trabajo fácil con ramas locales. Velocidad de manejo de ramas

Características

Rapidez Cada operación se realiza en el repositorio local. No es necesario conexión con otro servidor. Trabajo offline sin problemas. Rápido

Características

Rapidez - Operaciones en local, velocidad constante

Git  

Características

Distribuido -  Clonación del repositorio completo

-  Múltiples backups

-  Diferentes flujos de trabajo.

Características

Integridad  de datos Cada elemento se idenficia por un código hash. Es imposible cambiar el contenido de un fichero o directorio sin que se entere Git. No podemos perder información o corromper el repo sin que se detecte.

Características

Integridad de datos -  Representación de los ficheros mediante código

SHA en función del contenido.

Checksum (sha1):

24b9da6552252987aa493b52f8696cd6d3b00373  

Zonas

Zona de staging (Índice) Zona intermedia donde los commits son preparados

antes de poder realizarlos.

Flujos de trabajo

Enfoque centralizado

Flujos de trabajo

Enfoque distribuido: Flujo manager

Flujos de trabajo

Enfoque distribuido: Flujo Dictador

Gestión de ramas

Master  

Feature  1  

Desarrollo  

Tag  0.1  

Producción  

1) Una rama por cada funcionalidad / tarea (local)

Aceptación?  

Feature  2  

Aceptación?  

Gestión de ramas

Master  

Feature  1  Feature  2  Desarrollo  

Fallo  

Aceptación  Ok  

Producción  

Aceptación  

2) Una rama por cada funcionalidad / tarea (local)

Permite entrega continua

Gestión de bugs

3) Cada bug se resuelve en una rama independiente

Master  HoRixes  Desarrollo  

Tag  0.2  

Incorporación  del  bug  en  Desarrollo  

Tag  0.1  

Producción  

Beneficios

Algunos de los beneficios que pueden obtener los equipos de desarrollo son:

§  Reducir el time to market. §  Releases más estables. §  Evitar la propagación de bugs. §  Mantener la línea principal de desarrollo

limpia. §  Aumenta la versatilidad en la forma de trabajar.

Un ejemplo

REESCRIBIENDO LA HISTORIA

Reescribiendo la historia

Pull con rebase Aplicar cambios por encima de otros. Para mantener coherente el repositorio.

Reescribiendo la historia

Pull con rebase (1)

Repositorio Original

Reescribiendo la historia

Pull con rebase (2)

Hacemos cambios en local

Reescribiendo la historia

Pull con rebase (3a)

Pull sin rebase

Reescribiendo la historia

Pull con rebase (3b)

Pull con rebase git pull --rebase <ALIAS-REPO> <BRANCH>

Merge con Fast Forward

Reescribiendo la historia

Squashing Permite reagrupar commits

Reagrupación  de  commits  

Reescribiendo la historia

Squashing Permite reagrupar commits $ git rebase –i <primer-commit> $ git rebase –i HEAD^4

PROPUESTA DE SOLUCIONES

h;p://github.com  

Repositorios en la nube

h;p://bitbucket.org  

Github.com

Plan   Precio     Nº  Repositorios  privados  

Large   $50  /month   50  

Medium   $22  /month   20  

Small   $12/month   10  

Micro   $7/month   5  

Free   $0/month   0  

Bitbucket.org

Usuarios   Precio    

5   GraXs  

10   $10/month  

25   $25/month  

50   $50/month  

100   $100/month  

Ilimitados   $200/month    

Todos  los  planes  incluyen:  -­‐ Repositorios  privados  ilimitados  -­‐ Revisión  de  código  -­‐ Integración  con  JIRA  -­‐ Soporte  -­‐ Personalización  de  dominios  -­‐   API  Rest  

h;p://sitaramc.github.com/gitolite/index.html  

Open Source

+  h;p://gitlabhq.com/  

Gitolite

§  Open Source

§  Capa de control de acceso sobre Git §  Permisos a repositorios §  Permisos a nivel de branch / tag / directorio / file

§  Administración a través de un repositorio Git

§  Necesita Git y Perl instalados

Gitlab

§  Open Source

§  Basado en Ruby on Rails y Gitolite

§  Manejo visual de permisos

§  Revisión de código

§  Merge Request

§  Integración con LDAP compleja

MIGRACIÓN DE SVN A GIT

svn2git

$ svn2git Migración de proyectos SVN a Git manteniendo trunk, branches y tags https://github.com/nirvdrum/svn2git  

git svn

$ git svn Comando que permite utilizar SVN como repositorio remoto de Git. Para transiciones largas de SVN a Git donde el repositorio SVN es necesario mantenerlo durante un tiempo http://schacon.github.com/git/git-svn.html  

Integración continua

Existe plugin para Jenkins: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin    

Artículo interesante

Don´t use Git: http://svenpet.com/2013/02/21/dont-use-git/        

¿Preguntas?

Israel Alcázar Rodríguez israelalcazar@gmail.com @ialcazar