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 [email protected] @ialcazar
Top Related