PDF de programación - Introducción a Git y GitHub - Día 1

INTRODUCCIÓN
A GIT Y
GITHUB - DÍA 1

SERGIO GÓMEZ BACHILLER

Esta página se ha dejado vacía a propósito

Índice de contenidos

Capítulo 1 Sistemas de control de versiones . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Definición, clasificación y funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Introducción a git. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Capítulo 2 Aspectos básicos de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Instalación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Configuración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Capítulo 3 Uso básico de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Crear un proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Trabajando con el historial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Capítulo 4 Uso avanzado de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Deshacer cambios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Moviendo y borrando archivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Capítulo 5 Ramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1 Administración de ramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Fusión de ramas y resolución de conflictos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Mezclando con la rama master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Capítulo 6 Flujo de trabajo con Git (git flow) . . . . . . . . . . . . . . . . . . . . . . . 41
6.1 La importancia de la organización del flujo de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 La extensión flow de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Esta página se ha dejado vacía a propósito

4

Capítulo 1
Sistemas de control de
versiones

1.1 Definición, clasificación y funcionamiento
Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los
elementosdealgúnproductoounaconfiguracióndelmismo.Unaversión,revisiónoedi-
ción de un producto, es el estado en el que se encuentra dicho producto en un momento
dado de su desarrollo o modificación. Aunque un sistema de control de versiones puede
realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten
esta gestión dando lugar a los llamados sistemas de control de versiones o SVC (del inglés
System Version Control).
Estos sistemas facilitan la administración de las distintas versiones de cada producto
desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún
cliente específico). Ejemplos de este tipo de herramientas son entre otros: CVS, Subver-
sion, SourceSafe, ClearCase, Darcs, Bazaar , Plastic SCM, Git, Mercurial, Perforce.
1.1.1 Terminología
Repositorio ("repository")

El repositorio es el lugar en el que se almacenan los datos actualizados e históricos de
cambios.

Revisión ("revision")

Una revisión es una versión determinada de la información que se gestiona. Hay
sistemas que identifican las revisiones con un contador (Ej. subversion). Hay otros
sistemas que identifican las revisiones mediante un código de detección de
modificaciones (Ej. git usa SHA1).

5

Capítulo 1 Sistemas de control de versiones

Introducción a Git y GitHub - Día 1

Etiqueta ("tag")

Los tags permiten identificar de forma fácil revisiones importantes en el proyecto. Por
ejemplo se suelen usar tags para identificar el contenido de las versiones publicadas
del proyecto.

Rama ("branch")

Un conjunto de archivos puede ser ramificado o bifurcado en un punto en el tiempo
de manera que, a partir de ese momento, dos copias de esos archivos se pueden
desarrollar a velocidades diferentes o en formas diferentes de forma independiente el
uno del otro.

Cambio ("change")

Un cambio (o diff, o delta) representa una modificación específica de un documento
bajo el control de versiones. La granularidad de la modificación que es considerada
como un cambio varía entre los sistemas de control de versiones.

Desplegar ("checkout")

Es crear una copia de trabajo local desde el repositorio. Un usuario puede especificar
una revisión en concreto u obtener la última. El término 'checkout' también se puede
utilizar como un sustantivo para describir la copia de trabajo.

Confirmar ("commit")

Confirmar es escribir o mezclar los cambios realizados en la copia de trabajo del
repositorio. Los términos 'commit' y 'checkin' también se pueden utilizar como
sustantivos para describir la nueva revisión que se crea como resultado de confirmar.

Conflicto ("conflict")

Un conflicto se produce cuando diferentes partes realizan cambios en el mismo
documento, y el sistema es incapaz de conciliar los cambios. Un usuario debe resolver
el conflicto mediante la integración de los cambios, o mediante la selección de un
cambio en favor del otro.

Cabeza ("head")

También a veces se llama tip (punta) y se refiere a la última confirmación, ya sea en el
tronco ('trunk') o en una rama ('branch'). El tronco y cada rama tienen su propia
cabeza, aunque HEAD se utiliza a veces libremente para referirse al tronco.

Tronco ("trunk")

La única línea de desarrollo que no es una rama (a veces también llamada línea base,
línea principal o máster).

6

Introducción a Git y GitHub - Día 1

Capítulo 1 Sistemas de control de versiones

Fusionar, integrar, mezclar ("merge")

Una fusión o integración es una operación en la que se aplican dos tipos de cambios en
un archivo o conjunto de archivos. Algunos escenarios de ejemplo son los siguientes:
• Un usuario, trabajando en un conjunto de archivos, actualiza o sincroniza su

copia de trabajo con los cambios realizados y confirmados, por otros usuarios, en
el repositorio.

• Un usuario intenta confirmar archivos que han sido actualizado por otros
usuarios desde el último despliegue ('checkout'), y el software de control de
versiones integra automáticamente los archivos (por lo general, después de
preguntarle al usuario si se debe proceder con la integración automática, y en
algunos casos sólo se hace si la fusión puede ser clara y razonablemente resuelta).

• Un conjunto de archivos se bifurca, un problema que existía antes de la

ramificación se trabaja en una nueva rama, y la solución se combina luego en la
otra rama.

• Se crea una rama, el código de los archivos es independiente editado, y la rama

actualizada se incorpora más tarde en un único tronco unificado.

1.1.2 Clasificación
Podemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utili-
zada para el almacenamiento del código:

Locales

Los cambios son guardados localmente y no se comparten con nadie. Esta arquitectura
es la antecesora de las dos siguientes.

7

Capítulo 1 Sistemas de control de versiones

Introducción a Git y GitHub - Día 1

Figura 1.1Sistema de control de versiones local

Centralizados

Existe un repositorio centralizado de todo el código, del cual es responsable un único
usuario (o conjunto de ellos). Se facilitan las tareas administrativas a cambio de
reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama)
necesitan la aprobación del responsable. Algunos ejemplos son CVS y Subversion.

8

Introducción a Git y GitHub - Día 1

Capítulo 1 Sistemas de control de versiones

Figura 1.2 Sistema de control de versiones centralizado

Distribuidos

Cada usuario tiene su propio repositorio. Los distintos repositorios pueden
intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio,
que está normalmente disponible, que sirve de punto de sincronización de los
distintos repositorios locales. Ejemplos: Git y Mercurial.

Figura 1.3Sistema de control de versiones distribuido

Ventajas de sistemas distribuidos

• No es necesario estar conectado para guardar cambios.
• Posibilidad de continuar trabajando si el repositorio remoto no está accesible.
• El repositorio central está más libre de ramas de pruebas.

9

Capítulo 1 Sistemas de control de versiones

Introducción a Git y GitHub - Día 1

• Se necesitan menos recursos para el repositorio remoto.
• Más flexibles al permitir gestionar cada repositorio personal como se quiera.
1.2 Introducción a git
Gitesunsistemadecontroldeversionesdistribuidoquesediferenciadelrestoenelmodo
en que modela sus datos. La mayoría de los demás sistemas almacenan la información co-
mo una lista de cambios en los archivos, mientras que Git modela sus datos más como un
conjunto de instantáneas de un mini sistema de archivos.

Figura 1.4Modelo de datos de los sistemas distribuidos tradicionales

Figura 1.5Modelo de datos de Git

1.2.1 Los tres estados
Gittiene tres estados principales enlosque sepueden encontrar tus archivos: confirmad