Introducción a Git y Bitbucket 1 INTRODUCCIÓN A GIT Y BITBUCKET Un Sistema de Control de Versiones (SVC) es un sistema informático encargado de registrar los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que se pueden gestionar las diferentes versiones producidas: recuperar, mezclar, comparar, etc. El uso de SVC facilita el trabajo en modo colaborativo y paralelo, mediante el uso de ramas y de funcionalidades como la capacidad de combinar o mezclar (merge) versiones diferentes de un mismo documento. En general cualquier SVC ofrece capacidades para revertir un archivo o un proyecto entero a un estado anterior. Se ofrecen también facilidades para comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un SVC también permite recuperar archivos o parte de archivos perdidos con mucha facilidad.
1.1 CLASIFICACIÓN DE LOS SISTEMAS DE CONTROL DE VERSIONES Típicamente los SVC se clasifican en tres grandes categorías:
SVC Locales: Llevan registro de todos los cambios realizados sobre los archivos a nivel local, en una computadora. No facilitan el trabajo colaborativo, están orientados al trabajo individual Ejemplos: RCS (Revision Control System), el cual se encuentra todavía en uso, por ejemplo se incluye como herramienta de desarrollo en MacOS y en muchas herramientas de wiki.
SVC Centralizados: Constan de un único servidor (el punto centralizado) que 1
contiene todos los archivos versionados, y varios clientes que descargan los archivos desde ese lugar central Ejemplos: CVS, Subversion (SVN) y Perforce
SVC distribuidos: los clientes
no descargan la última instantánea de los archivos sino que replican completamente el repositorio, así pues aunque haya un repositorio centralizado, se puede trabajar de forma totalmente online. Ejemplos: Mercurial (hg), Git,
Bazaar, Darcs
1.2 SISTEMAS CENTRALIZADOS VS DISTRIBUIDOS En general los SVC centralizados no favorecen el trabajo colaborativo por los siguientes motivos: • •
El servidor central se convierte en un cuello de botella, hace que las operaciones de cambio del repositorio sean costosas, lentas. Los cambios en alguna de las ramas afectan a todos porque son globales, no se favorece la ramificación.
2
• •
Son necesarias políticas de nomenclaturas y ser cuidadosos con las políticas de escritura. No se favorece la confirmación de cambios, sino que se tiende a esperar a tener bastantes cambios y bien pulidos antes de confirmarlos (y subirlos al repositorio).
Los SVC distribuidos se han popularizado mucho porque solucionan casi todos esos problemas: • •
•
Elimina la dependencia de un servidor central Se pueden realizar cambios (confirmados) sin afectar a los demás. Esto favorece la experimentación y fomenta la ramificación de los proyectos, a la que vez que elimina la necesidad e incomodidad de las políticas de control de acceso Al poder trabajar en local aumenta mucho la eficiencia. Las operaciones de modificación de un repositorio son mucho menos costosas que en un SVC centralizado.
INTRODUCCIÓN A GIT
1.3
Git es un sistema de control de versiones distribuido, creado por Linus Torvalds, el creador del núcleo Linux –
Cualquier copia es un repositorio Git completo y autosuficiente
–
No depende de acceso a la red o de un repositorio central.
–
No es necesario tener un repositorio central, aunque sí opcional
–
Permite intercambio directo entre los repos de diferentes personas sin pasar por el repositorio central
Características principales de Git –
Super rápido
–
Muy eficiente en el uso del espacio. Sólo se guardan las diferencias entre los archivos.
–
Mecanismo de branching y merging sofisticado, con muchas opciones
–
Muy robusto frente a la corrupción de datos
Para hacernos una idea de la eficiencia y velocidad de Git bastan un par de ejemplos • •
Rapidez: Mostrar las diferencias de todo el kernel, 74,000 commits, cuesta pocos segundos. Eficiencia memoria: El repositorio en CVS del Mozilla Project es de 3GB, en Subversion es de 12GB en formato fsfs. EnGit es de 300 Mb
1.3.1 Conceptos básicos de Git Todos los datos utilizados para el control de versiones mediante git se almacenan en una carpeta denominada .git, la cual típicamente se crea dentro de la carpeta raíz del proyecto que queremos mantener bajo control. Git funciona mediante el uso de instantáneas, las cuales capturan el estado del proyecto en un momento dado y permiten recuperar ese estado cuando se desee.
3
El historial de un proyecto versionado con Git se representa como una colección de instantáneas agrupadas secuencialmente en ramas. Rama: una rama es una entidad que permite trabajar simultáneamente con diferentes instantáneas o versiones de un proyecto. Las ramas diferentes a la rama principal, o master, se crean como bifurcaciones de una rama raíz, cuyo historial de confirmaciones copian. A partir de su creación, una rama puede seguir su propio camino, divergiendo más o menos de su rama de origen Es posible mezclar ramas entre sí, e incluso reordenar las diferentes confirmaciones (rebase) Instantánea: una instantánea se refiere al estado concreto del proyecto en un momento determinado, correspondiente a una confirmación en particular. Cada instantánea (y la confirmación que la produce) recibe un código SHA-1 (variante de código Hash) que la identifica inequívocamente. Una misma instantánea puede estar presente en varias ramas. La figura siguiente ilustra los principales conceptos necesarios para entender cómo funciona Git y algunos de los comandos más utilizados.
1. Espacio de trabajo (workspace). En el espacio de trabajo se encuentran los archivos actuales de la carpeta raíz de nuestro proyecto, es lo que se ve desde el sistema de archivos nativo, el contenido con el cual podemos trabajar directamente (añadir, borrar o editar archivos). Contiene cualquier cambio no añadido al repositorio. 2. Índice (index o stage area): contiene una instantánea del espacio de trabajo con aquellos cambios que se van a añadir a la próxima confirmación. Es posible añadir archivos desde el espacio de trabajo al índice con el comando add.
4
3. Repositorio local: contiene todas las confirmaciones realizadas en el proyecto, las cuales pueden pertenecer a diferentes ramas de trabajo. Para guardar una nueva versión de un archivo en el repositorio es necesario confirmarlo con el comando commit. En principio sólo los archivos añadidos previamente al índice se pueden confirmar, pero hay una opción que permite incluir en una confirmación aquellos archivos modificados todavía no añadidos al índice: commit –a. 4. Repositorio remoto (origin/upstream): se trata de un repositorio Git almacenando en algún servidor conectado a Internet, el cual permite compartir contenido con diferentes personas. Es posible pasar contenido de un repositorio remoto a otro local mediante los comandos fetch o pull. El primero se baja los cambios al repositorio local, pero no modifica nuestro espacio de trabajo, de tal manera que es posible revisar los cambios antes de mezclarlos con el contenido local. El segundo en cambio además de bajarse los cambios actualiza nuestro espacio de trabajo con la última instantánea descargada desde el repositorio remoto. Otro comando muy utilizado que hay conocer es checkout, el cual se utiliza para cambiar el contenido del espacio de trabajo, por ejemplo tras bajar los cambios en una rama desde un repositorio remoto, cuando queremos cambiar de rama, o si queremos ver el estado del sistema en otro instante. 1.3.2 Instalación de Git Se pueden obtener archivos para su instalación desde la página: http://git-scm.com/ Hay versiones para los principales S.O.: Windows, Mac OS y Linux.
1.4 INTRODUCCIÓN A BITBUCKET Bitbucket es una plataforma Web para gestionar repositorios de proyectos que utilicen el sistema de control de versiones Git o Mercurial. Sus principales características son • • • • • • • • •
Almacenamiento de repositorios Git y Mercurial para equipos de desarrollo de software, aunque permite cualquier contenido. Permite repositorios privados sin límite de cantidad Permite gestión de equipos de trabajo (gratuito hasta 5 miembros) Permite navegar por el código con total libertad, explorando diferentes ramas y momentos temporales (confirmaciones) Gestión de incidencias Permite mantener una wiki Soporte para compartir archivos adicionales (no versionados) Soporte para divisiones y peticiones de integración (forks y pull requests) Integración con herramientas profesionales: Jira, Crucible, Bamboo, Jenkin…
2 CREAR UNA CUENTA EN BITBUCKET Y UN REPOSITORIO GIT Lo primero que tenemos que hacer para poder trabajar con Bitbucket es crear una cuenta. Para ello nos vamos a la página principal de bitbucket: https://bitbucket.org/ 5
Pulsamos sobre el botón “Sign up for free” y eso nos llevará al formulario de creación de nueva cuenta de usuario. Si queremos añadir o modificar contenido en nuestra cuenta de Bitbucket, necesitamos confirmar la dirección de correo electrónico usada en el registro de usuario. Una vez completada la creación de la cuenta de usuario, lo siguiente que vamos a hacer es crear un repositorio, el cual usaremos durante el resto de la asignatura para llevar un control del proyecto de prácticas. En la siguiente imagen puedes ver un ejemplo de cómo quedaría el formulario de creación de repositorios.
Instrucciones para crear nuestro primer repositorio: • • • • • • •
Introduce el nombre (GPR) y la descripción del repositorio. Nivel de acceso: privado Forks: Permitir solo forks privados Tipo de repositorio: Git En administración de proyecto puedes activar la gestión de incidencias y la wiki, aunque esto lo podéis hacer también más tarde. No marques ningún idioma, ya que no vamos a usar el repositorio para desarrollo de software. Opcionalmente puedes permitir el chat integrado (enable hipchat notifications) para comunicarte con los demás miembros del equipo de prácticas.
Una vez creado el repositorio se nos abrirá la interfaz correspondiente a la gestión de un repositorio. Desde esta pantalla se pueden realizar numerosas acciones para seguir el estado
6
de nuestro proyecto, gestionarlo o comunicarte con otros participantes Puedes empezar a explorar la interfaz para familiarizarte con el entorno y ver las principales opciones disponibles.
Cada repositorio tiene los siguientes elementos: 1. La barra de menús se utilizar para navegar por el repositorio. 2. Los botones de acción principal usados para clonar, crear ramas, crear solicitudes de integración, comparar o dividir (forking). 3. El botón de configuración del repositorio. 4. Lista de consejos para empezar, la cual se sustituye por las notificaciones de actividad del repositorio una vez que se tiene alguna actividad. Puedes hacer clic en elementos de la barra para ver qué hay detrás de cada uno. También puedes navegar utilizando métodos abreviados de teclado. La lista de métodos abreviados se puede consultar pulsando ‘?’ en el teclado. Si entras en la sección de confirmaciones en la barra de navegación, verás que no tienes ninguna confirmación registrada todavía, ya que no has creado ningún contenido todavía. Tu repositorio es privado, y no has invitado a nadie, por lo que sólo tú como propietario puedes crear o editar contenido. Para invitar a otros usuarios a nuestro proyecto hay que ir al apartado de administración de acceso (Access management), y ahí introducir el nombre de usuario bitbucket al que queremos invitar o una dirección de correo electrónico.
7
3 CLONAR UN REPOSITORIO GIT Y AÑADIR CONTENIDO Clonar consiste en realizar una copia completa de un repositorio Git. Típicamente se realizan clones de un repositorio remoto a un repositorio local para poder trabajar sobre él. En Bitbucket ve a tu repositorio y pincha en la acción “clonar”, podrás obtener un enlace con el comando necesario: git clone https://
[email protected]/cuenta/gpr.git Nota: Git admite varias formas de instalación en Windows, siendo la más habitual y la menos intrusiva la que usa un terminal propio, GitBash, para introducir comandos Git. Otra opción es modificar el entorno para poder invocar comandos Git desde un terminal Windows normal (Cmd). Abrimos un terminal para ejecutar comandos de git. En Linux/MacOS podemos ejecutar los comandos de Git en cualquier terminal. Si estamos en Windows, caben varias opciones. Aunque es posible configurar Windows para usar Git desde la consola del SO, la instalación para Windows de Git incluye un terminal específico, denominado Git Bash. Seguimos los pasos siguientes: • •
Cambiamos de directorio, a la ruta donde queramos almacenar alojar nuestro proyecto. Clonamos mediante el comando git clone
El siguiente fragmento muestra los comandos a ejecutar, así como la información ofrecida por Git.
Welcome to Git (version 1.9.4-preview20140815) Run 'git help git' to display the help index. Run 'git help
' to display help for specific commands. Mario@HAL ~ $ cd repos Mario@HAL ~/repos $ git clone https://[email protected]/magomar/gpr.git Cloning into 'gpr'... Password for 'https://[email protected]': warning: You appear to have cloned an empty repository. Checking connectivity... done.
Tras introducir la contraseña pertinente, nos informa de que hemos clonado un repositorio vacío.
8
La siguiente imagen muestra los pasos necesarios para crear un archivo por consola (en el ejemplo se ha utilizado el comando echo, aunque podría hacerse por cualquier otra vía, como un editor de texto) y cómo queda el repositorio tras su creación. Para obtener una descripción del estado actual del repositorio se utiliza el comando git status.
Mario@HAL ~/repos $ cd gpr Mario@HAL ~/repos/gpr (master) $ echo "Nombre propio y usuario de Bitbucket" >> participantes.txt Mario@HAL ~/repos/gpr (master) $ git status On branch master Initial commit Untracked files: (use "git add ..." to include in what will be committed) participantes.txt nothing added to commit but untracked files present (use "git add" to track)
Untracked files nos indica que hay contenido nuevo que no está siendo “seguido” por el sistema de control de versiones, dicho de otro modo, no ha pasado al índice (muy conocido también como stage area), se encuentra tan solo en el espacio de trabajo.
Mario@HAL ~/repos/gpr (master) $ git add participantes.txt warning: LF will be replaced by CRLF in participantes.txt. The file will have its original line endings in your working directory. $ git status On branch master Initial commit Changes to be committed: (use "git rm --cached ..." to unstage) new file: participantes.txt master from origin.
Ahora, Git nos informa de que hay cambios registrados en el índice, que necesitan ser confirmados si queremos guardar una instantánea del proyecto. En Git se promueve la 9
realización de frecuentes confirmaciones correspondientes a pequeños cambios, no vale la pena esperar a tener muchos cambios dado lo poco que cuesta crear una instantánea (tanto en tiempo como en espacio).
3.1 CONFIGURACIÓN BÁSICA DE GIT Antes de poder modificar el repositorio (mediante una confirmación) necesitamos configurar Git para indicarle la autoría de los cambios realizados. Lo primero que hay que configurar es el nombre de usuario y la cuenta de correo, para establecer la autoría de las confirmaciones. La información de configuración se guarda en el fichero .gitconfig en el directorio home (por defecto ~/.gitconfig). Mas o menos contendrá esto: [user] name = Nombre Apellido1 Apellido2 email = [email protected] [core] autocrlf = true excludesfile = …\\gitignore_global.txt Podemos cambiar la configuración con comandos de consola, como sigue.
$ git config --global user.name “Nombre Apellido1 Apellido2" $ git config --global user.email “[email protected]"
3.2 GUARDAR UNA INSTANTÁNEA DEL SISTEMA Ya podemos confirmar (comando git commit) los cambios producidos en nuestro proyecto. Al confirmar los cambios en el índice, se crea una nueva instantánea (snapshot) en el repositorio local, lo que nos permitirá recuperar el estado del proyecto en el momento de realizar esa confirmación (en la rama activa). Al confirmar sólo se almacenan en el repositorio los cambios correspondientes a archivos previamente añadidos al índice. Sin embargo, es posible saltarse el paso de añadir al índice, pasando directamente del espacio de trabajo al repositorio local. Se hace añadiendo la opción –a al comando commit.
10
A continuación se muestra un ejemplo de confirmación, comando commit. Con la opción –m y una cadena de texto se asocia un mensaje a la confirmación. Este mensaje se suele utilizar para describir en que consisten los cambios confirmados en esta instantánea.
Mario@HAL ~/repos/gpr (master) $ git commit -m 'Confirmación inicial con participantes.txt' [master (root-commit) 5f7ca45] Confirmación inicial con participantes.txt warning: LF will be replaced by CRLF in participantes.txt. The file will have its original line endings in your working directory. 1 file changed, 1 insertion(+) create mode 100644 participantes.txt $ git status On branch master Your branch is based on 'origin/master', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working directory clean
Finalmente, nos quedará subir la nueva instantánea del proyecto a nuestro repositorio remoto. Para ello contamos con el comando push, cuyo uso queda reflejado en el siguiente cuadro.
Mario@HAL ~/repos/gpr (master) $ git push -u origin master Password for 'https://[email protected]': Counting objects: 3, done. Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To https://[email protected]/magomar/gpr.git * [new branch]
master -> master
Branch master set up to track remote branch master from origin.
Una vez completada la subida de la instantánea, la rama actual, que es la que subimos con el push, quedará emparejada a la rama remota, lo que le permitirá seguir los cambios producidos en esa rama en el repositorio remoto. Realiza en bitbucket las siguientes comprobaciones •
En resumen verás que tienes una sola rama, la rama principal o master 11
• • •
En fuente verás que sólo tienes el archivo participantes.txt. Como es un archivo de texto puedes además ver su contenido, simplemente pinchando en él. En confirmaciones verás que sólo tienes una confirmación, anotada con el mensaje “Confirmación inicial con participantes.txt” En ramas verás que no hay nada todavía, pues sólo tienes la rama master.
3.3 MODIFICAR CONTENIDO Si en vez de añadir un nuevo archivo, modificamos un archivo existente, el proceso es muy similar, pero en esta ocasión git nos informará de que ha detectado modificaciones en un archivo. Prueba a editar el archivo participantes.txt, añadiendo algún nombre más. A continuación comprueba el estado y obtendrás lo siguiente:
Mario@HAL ~/repos/gpr (master) $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: participantes.txt
Veamos también el uso de la opción –a en un commit, la cual nos evita tener que añadir los cambios al índice para que sean confirmados.
Mario@HAL ~/repos/gpr (master) $ git commit -a -m "Añade nombres al archivo participantes.txt" warning: LF will be replaced by CRLF in participantes.txt. The file will have its original line endings in your working directory. Y por último, subimos la confirmación al repositorio remoto.
Mario@HAL ~/repos/gpr (master) $ git push origin master Password for 'https://[email protected]': Counting objects: 5, done. … Ahora podríamos revisar el repositorio en bitbucket para comprobar cómo ha quedado. Como sugerencia, consulta los siguientes apartados •
Confirmaciones: verás que hay 2 confirmaciones, cada una con su propio HASH code, identificador único de una confirmación.
12
•
Fuente: verás que sólo aparece el archivo participantes.txt como un enlace. Si pinchas en él podrás visualizar su contenido (esto sólo es posible para archivos de texto, para binarios sólo podremos descargarlos).
•
Además de ver y editar contenido, puedes consultar diferencias (incluso en modo ladoa-lado) entre varias versiones de un mismo archivo.
4 EDICIÓN DE CONTENIDOS EN BITBUCKET A continuación vamos a ver cómo se edita contenido directamente en Bitbucket, pero antes vamos a añadir contenido más interesante a nuestro repositorio. Descarga y descomprime el archivo caso_estudio.zip, el cual contiene una descripción del caso de estudio en formato mark_down, así (caso_estudio.md) como una serie de imágenes en una carpeta denominada media. Sigue los siguientes pasos: • • • •
Copia o mueve ese contenido a la carpeta raíz de tu proyecto. Añádelo al índice usando el comando git add *. Confírmalo con el mensaje “descripcion del caso de estudio” Actualiza el repositorio remoto para que contenga los últimos cambios confirmados.
En la web de Bitbucket, dentro de nuestro proyecto, seguimos los pasos siguientes: (1) Entrar en la sección “fuente” (2) Elegir rama, master, y entrar en la carpeta caso_Estudio (3) Opción para crear nuevo contenido (4) Vamos a editar un archivo ya existente, caso_estudio.md Pinchamos para abrirlo
13
(1) Además de ver el contenido del archivo abierto, podemos mostrar también las diferencias con respecto a la versión anterior, o (2) ver un resumen del historial (3) Nos muestra el código SHA (identificador único) de la última confirmación, y (4) “Ver todas las confirmaciones” permite acceder a todo el historial (log) de confirmaciones previas. (5) Le damos al botón de Editar (la flecha nos permite cambiar el nombre o borrar este archivo), y pasaremos al modo de edición Añadimos el contenido del archivo “casos_uso.md” al contenido del archivo, y a continuación vamos a confirmar
14
(1) Vemos que el editor detecta el archivo como de tipo Markdown (2) Tenemos varias opciones relativas al alineamiento y espaciado. (3) Podemos ver las diferencias, y finalmente (4) Podemos elegir entre cancelar todos los cambios o guardarlos mediante su confirmación (botón azul). Nosotros lo vamos a confirmar, con el mensaje “Añade casos de uso al caso de estudio”
Al pulsar “Ver confirmaciones” vemos detalles de cada confirmación y el registro de cambios
15
introducidos en cada confirmación
(1) Autor, SHA y mensaje asociado a la confirmación (2) Información relativa al autor, la confirmación previa, y opciones para: ver la confirmación en bruto (texto plano), observar/dejar de observar, y aprobar/desaprobar confirmación. (3) Sección de comentarios y campo para añadir comentario (4) Lista resumen de cambios producidos en la confirmación actual (5) Detalle de todos los cambios producidos en cada uno de los archivos. Se pueden también ver las diferencias o el fichero original. Por último, sólo nos quedaría, si así lo deseamos, actualizar nuestro repositorio local con los cambios introducidos en el repositorio remoto a través de la interfaz web. Si ha cambiado algo en el repositorio remoto y queremos actualizar el repo local para estar en sincronía, debemos ejecutar un comando pull.
Mario@HAL ~/repos/gpr (master) $ git status On branch master Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch) nothing to commit, working directory clean $ git pull --all Fetching origin Password for 'https://[email protected]': Updating 81e0398..d8ab597 Fast-forward caso_estudio/caso_estudio.md | 158 ++++++++++++++++++++++++++++++++++++++++++1 file changed, 157 insertions(+), 1 deletion(-)
Con fetch también podríamos descargar los cambios sin modificar el espacio de trabajo actual. De hecho, si hacemos un pull directo veremos que en realidad también se ejecuta un fetch (fetching origin)
16
