Si bebes, no hagas commits

(0 comentarios)

Si no quieres provocar la ira de tus compañeros y tener que comprar donuts para toda la oficina como ofrenda de paz, es mejor intentar no hacer commits cuando uno tiene sus capacidades mentales mermadas por el alcohol. Si es algo que te suele ocurrir a menudo, además de buscar ayuda, puedes utilizar gitdown, un pequeño script que utiliza un Arduino para medir tu nivel de alcohol en sangre, y te impide hacer commits si supera el 0,05%.

[Pulsa para continuar]

Relájate con esta música generada con la actividad de GitHub

(0 comentarios)

Si eres programador y sueles escuchar música para concentrarte, te encantará GitHub Audio, una aplicación web de código abierto que transforma los eventos de GitHub en notas musicales para generar melodías de lo más relajantes.

Música con GitHub

El proyecto está inspirado en otros similares, como HatNote, que genera sonidos basados en los últimos cambios publicados en la Wikipedia.

¡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

(14 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