Introduccin a Git y Bitbucket

1 INTRODUCCIN A GIT Y BITBUCKET

Un Sistema de Control de Versiones (SVC) es un sistema informtico 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 tambin facilidades para comparar cambios a lo largo del
tiempo, ver quin modific por ltima vez algo que puede estar causando un problema, quin
introdujo un error y cundo, y mucho ms.

Usar un SVC tambin permite recuperar archivos o parte de archivos perdidos con mucha
facilidad.

1.1 CLASIFICACIN DE LOS SISTEMAS DE CONTROL DE VERSIONES

Tpicamente los SVC se clasifican en tres grandes categoras:

SVC Locales: Llevan registro de todos los

cambios realizados sobre los archivos a
nivel local, en una computadora. No
facilitan el trabajo colaborativo, estn
orientados al trabajo individual

Ejemplos: RCS (Revision Control System),

el cual se encuentra todava 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
instantnea 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 ramificacin.

2
 Son necesarias polticas de nomenclaturas y ser cuidadosos con las polticas de
escritura.
No se favorece la confirmacin 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 dems. Esto favorece la
experimentacin y fomenta la ramificacin de los proyectos, a la que vez que elimina
la necesidad e incomodidad de las polticas de control de acceso
Al poder trabajar en local aumenta mucho la eficiencia. Las operaciones de
modificacin de un repositorio son mucho menos costosas que en un SVC centralizado.

1.3 INTRODUCCIN A GIT

Git es un sistema de control de versiones distribuido, creado por Linus Torvalds, el creador del
ncleo 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

Caractersticas principales de Git

Super rpido

Muy eficiente en el uso del espacio. Slo se guardan las diferencias entre los archivos.

Mecanismo de branching y merging sofisticado, con muchas opciones

Muy robusto frente a la corrupcin 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 bsicos de Git

Todos los datos utilizados para el control de versiones mediante git se almacenan en una
carpeta denominada .git, la cual tpicamente se crea dentro de la carpeta raz del proyecto que
queremos mantener bajo control.

Git funciona mediante el uso de instantneas, 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 coleccin de
instantneas agrupadas secuencialmente en ramas.

Rama: una rama es una entidad que permite trabajar simultneamente con diferentes
instantneas o versiones de un proyecto.

Las ramas diferentes a la rama principal, o master, se crean como bifurcaciones de una rama
raz, cuyo historial de confirmaciones copian.

A partir de su creacin, una rama puede seguir su propio camino, divergiendo ms o menos de
su rama de origen

Es posible mezclar ramas entre s, e incluso reordenar las diferentes confirmaciones (rebase)

Instantnea: una instantnea se refiere al estado concreto del proyecto en un momento

determinado, correspondiente a una confirmacin en particular. Cada instantnea (y la
confirmacin que la produce) recibe un cdigo SHA-1 (variante de cdigo Hash) que la
identifica inequvocamente. Una misma instantnea puede estar presente en varias ramas.

La figura siguiente ilustra los principales conceptos necesarios para entender cmo funciona
Git y algunos de los comandos ms utilizados.

1. Espacio de trabajo (workspace). En el espacio de trabajo se encuentran los archivos

actuales de la carpeta raz de nuestro proyecto, es lo que se ve desde el sistema de
archivos nativo, el contenido con el cual podemos trabajar directamente (aadir,
borrar o editar archivos). Contiene cualquier cambio no aadido al repositorio.
2. ndice (index o stage area): contiene una instantnea del espacio de trabajo con
aquellos cambios que se van a aadir a la prxima confirmacin. Es posible aadir
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
versin de un archivo en el repositorio es necesario confirmarlo con el comando
commit. En principio slo los archivos aadidos previamente al ndice se pueden
confirmar, pero hay una opcin que permite incluir en una confirmacin aquellos
archivos modificados todava no aadidos al ndice: commit a.
4. Repositorio remoto (origin/upstream): se trata de un repositorio Git almacenando en
algn 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 adems de
bajarse los cambios actualiza nuestro espacio de trabajo con la ltima instantnea
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 Instalacin de Git

Se pueden obtener archivos para su instalacin desde la pgina: http://git-scm.com/

Hay versiones para los principales S.O.: Windows, Mac OS y Linux.

1.4 INTRODUCCIN 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 caractersticas son

Almacenamiento de repositorios Git y Mercurial para equipos de desarrollo de

software, aunque permite cualquier contenido.
Permite repositorios privados sin lmite de cantidad
Permite gestin de equipos de trabajo (gratuito hasta 5 miembros)
Permite navegar por el cdigo con total libertad, explorando diferentes ramas y
momentos temporales (confirmaciones)
Gestin de incidencias
Permite mantener una wiki
Soporte para compartir archivos adicionales (no versionados)
Soporte para divisiones y peticiones de integracin (forks y pull requests)
Integracin 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 pgina principal de bitbucket: https://bitbucket.org/

5
Pulsamos sobre el botn Sign up for free y eso nos llevar al formulario de creacin de nueva
cuenta de usuario. Si queremos aadir o modificar contenido en nuestra cuenta de Bitbucket,
necesitamos confirmar la direccin de correo electrnico usada en el registro de usuario.

Una vez completada la creacin 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 prcticas.

En la siguiente imagen puedes ver un ejemplo de cmo quedara el formulario de creacin de

repositorios.

Instrucciones para crear nuestro primer repositorio:

Introduce el nombre (GPR) y la descripcin del repositorio.

Nivel de acceso: privado
Forks: Permitir solo forks privados
Tipo de repositorio: Git
En administracin de proyecto puedes activar la gestin de incidencias y la wiki,
aunque esto lo podis hacer tambin ms tarde.
No marques ningn 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 dems miembros del equipo de prcticas.

Una vez creado el repositorio se nos abrir la interfaz correspondiente a la gestin 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 mens se utilizar para navegar por el repositorio.
2. Los botones de accin principal usados para clonar, crear ramas, crear solicitudes de
integracin, comparar o dividir (forking).
3. El botn de configuracin 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 detrs de cada uno. Tambin
puedes navegar utilizando mtodos abreviados de teclado. La lista de mtodos abreviados se
puede consultar pulsando ? en el teclado.

Si entras en la seccin de confirmaciones en la barra de navegacin, vers que no tienes

ninguna confirmacin registrada todava, ya que no has creado ningn contenido todava. Tu
repositorio es privado, y no has invitado a nadie, por lo que slo t como propietario puedes
crear o editar contenido.

Para invitar a otros usuarios a nuestro proyecto hay que ir al apartado de administracin de
acceso (Access management), y ah introducir el nombre de usuario bitbucket al que queremos
invitar o una direccin de correo electrnico.

7
3 CLONAR UN REPOSITORIO GIT Y AADIR CONTENIDO
Clonar consiste en realizar una copia completa de un repositorio Git. Tpicamente 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 accin clonar, podrs obtener un enlace con el

comando necesario:
git clone https://usuario@bitbucket.org/cuenta/gpr.git

Nota: Git admite varias formas de instalacin en Windows, siendo la ms habitual y la menos
intrusiva la que usa un terminal propio, GitBash, para introducir comandos Git. Otra opcin 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 instalacin
para Windows de Git incluye un terminal especfico, 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 informacin ofrecida por
Git.

Welcome to Git (version 1.9.4-preview20140815)

Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
Mario@HAL ~
$ cd repos
Mario@HAL ~/repos
$ git clone https://magomar@bitbucket.org/magomar/gpr.git
Cloning into 'gpr'...
Password for 'https://magomar@bitbucket.org':
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

Tras introducir la contrasea pertinente, nos informa de que hemos clonado un repositorio
vaco.

8
La siguiente imagen muestra los pasos necesarios para crear un archivo por consola (en el
ejemplo se ha utilizado el comando echo, aunque podra hacerse por cualquier otra va, como
un editor de texto) y cmo queda el repositorio tras su creacin. Para obtener una descripcin
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 <file>..." 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
tambin 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 <file>..." 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 instantnea del proyecto. En Git se promueve la

9
realizacin de frecuentes confirmaciones correspondientes a pequeos cambios, no vale la
pena esperar a tener muchos cambios dado lo poco que cuesta crear una instantnea (tanto
en tiempo como en espacio).

3.1 CONFIGURACIN BSICA DE GIT

Antes de poder modificar el repositorio (mediante una confirmacin) necesitamos configurar
Git para indicarle la autora de los cambios realizados.

Lo primero que hay que configurar es el nombre de usuario y la cuenta de correo, para
establecer la autora de las confirmaciones.

La informacin de configuracin se guarda en el fichero .gitconfig en el directorio home (por

defecto ~/.gitconfig).

Mas o menos contendr esto:

[user]
name = Nombre Apellido1 Apellido2
email = cuenta@dominio.upv.es
[core]
autocrlf = true
excludesfile = \\gitignore_global.txt

Podemos cambiar la configuracin con comandos de consola, como sigue.

$ git config --global user.name Nombre Apellido1 Apellido2"

$ git config --global user.email cuenta@dominio.upv.es"

3.2 GUARDAR UNA INSTANTNEA 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 instantnea (snapshot) en el repositorio
local, lo que nos permitir recuperar el estado del proyecto en el momento de realizar esa
confirmacin (en la rama activa). Al confirmar slo se almacenan en el repositorio los cambios
correspondientes a archivos previamente aadidos al ndice. Sin embargo, es posible saltarse
el paso de aadir al ndice, pasando directamente del espacio de trabajo al repositorio local. Se
hace aadiendo la opcin a al comando commit.

10
A continuacin se muestra un ejemplo de confirmacin, comando commit. Con la opcin m y
una cadena de texto se asocia un mensaje a la confirmacin. Este mensaje se suele utilizar
para describir en que consisten los cambios confirmados en esta instantnea.

Mario@HAL ~/repos/gpr (master)

$ git commit -m 'Confirmacin inicial con participantes.txt'
[master (root-commit) 5f7ca45] Confirmacin 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 instantnea 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://magomar@bitbucket.org':
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://magomar@bitbucket.org/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 instantnea, 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 vers que tienes una sola rama, la rama principal o master

11
 En fuente vers que slo tienes el archivo participantes.txt. Como es un archivo de
texto puedes adems ver su contenido, simplemente pinchando en l.
En confirmaciones vers que slo tienes una confirmacin, anotada con el mensaje
Confirmacin inicial con participantes.txt
En ramas vers que no hay nada todava, pues slo tienes la rama master.

3.3 MODIFICAR CONTENIDO

Si en vez de aadir un nuevo archivo, modificamos un archivo existente, el proceso es muy
similar, pero en esta ocasin git nos informar de que ha detectado modificaciones en un
archivo. Prueba a editar el archivo participantes.txt, aadiendo algn nombre ms. A
continuacin comprueba el estado y obtendrs 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 <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: participantes.txt

Veamos tambin el uso de la opcin a en un commit, la cual nos evita tener que aadir los
cambios al ndice para que sean confirmados.

Mario@HAL ~/repos/gpr (master)

$ git commit -a -m "Aade 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 confirmacin al repositorio remoto.

Mario@HAL ~/repos/gpr (master)

$ git push origin master
Password for 'https://magomar@bitbucket.org':
Counting objects: 5, done.

Ahora podramos revisar el repositorio en bitbucket para comprobar cmo ha quedado. Como
sugerencia, consulta los siguientes apartados

Confirmaciones: vers que hay 2 confirmaciones, cada una con su propio HASH code,
identificador nico de una confirmacin.

12
 Fuente: vers que slo aparece el archivo participantes.txt como un enlace. Si pinchas
en l podrs visualizar su contenido (esto slo es posible para archivos de texto, para
binarios slo podremos descargarlos).

Adems de ver y editar contenido, puedes consultar diferencias (incluso en modo lado-
a-lado) entre varias versiones de un mismo archivo.

4 EDICIN DE CONTENIDOS EN BITBUCKET

A continuacin vamos a ver cmo se edita contenido directamente en Bitbucket, pero antes
vamos a aadir contenido ms interesante a nuestro repositorio.

Descarga y descomprime el archivo caso_estudio.zip, el cual contiene una descripcin del caso
de estudio en formato mark_down, as (caso_estudio.md) como una serie de imgenes en una
carpeta denominada media.

Sigue los siguientes pasos:

Copia o mueve ese contenido a la carpeta raz de tu proyecto.

Adelo al ndice usando el comando git add *.
Confrmalo 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 seccin fuente

(2) Elegir rama, master, y entrar en la carpeta caso_Estudio

(3) Opcin para crear nuevo contenido

(4) Vamos a editar un archivo ya existente, caso_estudio.md Pinchamos para abrirlo

13
 (1) Adems de ver el contenido del archivo abierto, podemos mostrar tambin las
diferencias con respecto a la versin anterior, o

(2) ver un resumen del historial

(3) Nos muestra el cdigo SHA (identificador nico) de la ltima confirmacin, y

(4) Ver todas las confirmaciones permite acceder a todo el historial (log) de
confirmaciones previas.

(5) Le damos al botn de Editar (la flecha nos permite cambiar el nombre o borrar este
archivo), y pasaremos al modo de edicin

Aadimos el contenido del archivo casos_uso.md al contenido del archivo, y a continuacin

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
confirmacin (botn azul). Nosotros lo vamos a confirmar, con el mensaje Aade
casos de uso al caso de estudio

Al pulsar Ver confirmaciones vemos detalles de cada confirmacin y el registro de cambios

15
introducidos en cada confirmacin

(1) Autor, SHA y mensaje asociado a la confirmacin

(2) Informacin relativa al autor, la confirmacin previa, y opciones para: ver la

confirmacin en bruto (texto plano), observar/dejar de observar, y
aprobar/desaprobar confirmacin.

(3) Seccin de comentarios y campo para aadir comentario

(4) Lista resumen de cambios producidos en la confirmacin actual

(5) Detalle de todos los cambios producidos en cada uno de los archivos. Se pueden
tambin ver las diferencias o el fichero original.

Por ltimo, slo nos quedara, si as lo deseamos, actualizar nuestro repositorio local con los
cambios introducidos en el repositorio remoto a travs de la interfaz web.

Si ha cambiado algo en el repositorio remoto y queremos actualizar el repo local para estar en
sincrona, 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://magomar@bitbucket.org':
Updating 81e0398..d8ab597
Fast-forward
caso_estudio/caso_estudio.md | 158
++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 157 insertions(+), 1 deletion(-)

Con fetch tambin podramos descargar los cambios sin modificar el espacio de trabajo actual.
De hecho, si hacemos un pull directo veremos que en realidad tambin se ejecuta un fetch
(fetching origin)

16