¡Git es sencillo!

(2 comentarios)

Como todos sabemos, Git es sencillo en cuanto entiendes que las ramas son simples endofuntores homeomórficos que mapean subvariedades de un espacio de Hilbert. El resto de conceptos básicos son fácilmente deducibles de la tira de ayer de xkcd.

Git

Detached HEAD en Git

(3 comentarios)

Es posible que Git te haya mostrado alguna vez una advertencia del tipo “You are in ‘detached HEAD’ state” al intentar hacer un commit o un push. Lo que nos está diciendo Git es que el puntero HEAD está apuntando directamente a un commit, en lugar de apuntar a una rama que apunte al commit.

[Pulsa para continuar]

Getting Good with Git

(1 comentario)

Getting Good with GitGetting Good with Git
Calificación:
Autor: Andrew Burgess
Año: 2010
Editorial: Rockable

Aunque descargue este libro hace ya varios meses, cuando Nettuts+ lo ofrecía de manera gratuita en su promoción de lanzamiento, no me había animado a empezarlo hasta hace pocos días, en un intento (vano) de compensar la decepción que supuso Pragmatic Version Control Using Git.

“Getting Good with Git” es un libro bastante corto, con poco más de 100 páginas, muy fácil de leer y con un diseño muy cuidado. Hasta aquí sus virtudes. Y es que, aunque no es un mal libro, “Getting Good with Git” adopta un criterio tan absurdo sobre lo que es importante y lo que no, que me hace difícil poder recomendarlo a cualquier novato; mucho menos a usuarios con experiencia, que encontrarán poco de su interés en este libro. Ejemplo de estas prioridades desquiciadas es el hecho de que se dedique todo un capítulo al uso básico de la consola de Windows y Mac OS (comandos como dir o cd) y sólo una línea a explicar el concepto de etiqueta.

Sólo el hecho de que dedique un capítulo entero al uso de GitHub me ha hecho salvarlo de la quema.

Pragmatic Version Control Using Git

(4 comentarios)

Pragmatic Version Control Using GitPragmatic Version Control Using Git
Calificación:
Autor: Travis Swicegood
Año: 2009
Editorial: Pragmatic Bookshelf

“Pragmatic Version Control Using Git” (Control de versiones pragmático usando Git) no es un mal libro. Al contrario, está bien escrito, la experiencia del autor es evidente, me ha aportado varias cosas, y cuenta con un apéndice con los comandos más utilizados que puede sernos útil a modo de referencia. Pero, y siempre suele haber un pero cuando una review comienza de esta forma, “Pragmatic Version Control Using Git” me ha decepcionado.

Puede que se haya debido al alto concepto que tengo de otros libros de Pragmatic Programmer. O puede haber sido su aparente trastorno de personalidad. El hecho de que no termine de decantarse por un publico objetivo, y pueda resultar, a la vez, ligeramente amenazador para una persona que se acerca por primera vez al control de versiones, y algo insustancial para un programador con algo de experiencia con Git.

El libro, en todo caso, es interesante. Está dividido en tres partes mas los apéndices, estando la primera parte (cerca de la cuarta parte de las hojas) dedicada a una ligera introducción al control de versiones y a Git. En la segunda parte se tratan los comandos que un desarrollador cualquiera puede utilizar en su día a día, y se cierra con una tercera parte consistente en unas pocas hojas sobre administración.

  • Git Immersion, un tutorial rápido de lo más recomendable, para aquellos que estén dando sus primeros pasos con este software de control de versiones. (3 comentarios) #

Trunk, branch y tag

(13 comentarios)

Trunk, branch y tag son tres de los conceptos principales a manejar a la hora de utilizar un sistema de control de versiones, como CVS, Subversion, Git o Mercurial. A continuación tenéis una pequeña definición de estos tres términos.

  • Trunk (tronco): la línea principal de desarrollo, donde se llevan a cabo los cambios menos complejos del día a día. Idealmente debería poder compilarse y pasar todas las pruebas en todo momento (ver Integración continua). La persona que rompa la compilación, debe ser públicamente humillada, y debe pagar una penitencia en donuts
  • Branch (rama): cuando se van a llevar a cabo cambios importantes que romperán la compilación, pruebas, experimentos o intentos de optimización, debe crearse una nueva rama de desarrollo, con la que no molestemos a los compañeros, esto es un branch: una copia del código o la rama de la que deriva. En esta copia haremos nuestros cambios, integraremos los arreglos que puedan haberse ido haciendo en el trunk, y, una vez terminado el desarrollo en la rama, integraremos (o no) los cambios en el trunk. También puede crearse una rama para una versión terminada, hacer mantenimiento de esta versión sobre esta rama, y continuar el desarrollo de la nueva versión en el trunk.
  • Tag (etiqueta): etiquetas que sirven para identificar un cierto momento en el desarrollo que queremos preservar. Se utilizan habitualmente para marcar cambios de versión (alfas, betas, RC, RTM) y puntos de interés. Sobre un tag no se puede / no se debe hacer cambios