Entornos de Desarrollo

1 DAM

1. ACERCA DEL CONTROL DE VERSIONES

Qu es el control de versiones, y por qu debera importarte? El control de
versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto
de archivos a lo largo del tiempo, de modo que puedas recuperar versiones especficas
ms adelante.
Si eres diseador grfico o web, y quieres mantener cada versin de una imagen
o diseo (algo que sin duda quieres), un sistema de control de versiones (Version Control
System o VCS en ingls) es una eleccin muy sabia. Te permite revertir archivos a un
estado anterior, revertir el proyecto entero a un estado anterior, 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 VCS tambin
significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos
fcilmente. Adems, obtienes todos estos beneficios a un coste muy bajo.
1.1.

Sistemas de control de versiones locales

Un mtodo de control de versiones usado por mucha gente es copiar los archivos
a otro directorio (quizs indicando la fecha y hora en que lo hicieron, si son avispados).
Este enfoque es muy comn porque es muy simple, pero tambin tremendamente
propenso a errores. Es fcil olvidar en qu directorio te encuentras, y guardar
accidentalmente en el archivo equivocado o sobrescribir archivos que no queras.
Para hacer frente a este problema, los programadores desarrollaron hace tiempo
VCSs locales que contenan una simple base de datos en la que se llevaba registro de
todos los cambios realizados sobre los archivos (vase Figura 1-1).

Figura 1-1. Diagrama de control de versiones local.

Entornos de Desarrollo

1.2.

1 DAM

Sistemas de control de versiones centralizados

El siguiente gran problema que se encuentra la gente es que necesitan colaborar

con desarrolladores en otros sistemas. Para solventar este problema, se desarrollaron
los sistemas de control de versiones centralizados (Centralized Version Control Systems
o CVCSs en ingls). Estos sistemas, como CVS, Subversion, y Perforce, tienen un nico
servidor que contiene todos los archivos versionados, y varios clientes que descargan
los archivos desde ese lugar central. Durante muchos aos ste ha sido el estndar para
el control de versiones (vase Figura 1-2).

Figura 1-2. Diagrama de control de versiones centralizado.

Esta configuracin ofrece muchas ventajas, especialmente frente a VCSs locales.
Por ejemplo, todo el mundo puede saber (hasta cierto punto) en qu estn trabajando
los otros colaboradores del proyecto. Los administradores tienen control detallado de
qu puede hacer cada uno; y es mucho ms fcil administrar un CVCS que tener que
lidiar con bases de datos locales en cada cliente.
Sin embargo, esta configuracin tambin tiene serias desventajas. La ms obvia
es el punto nico de fallo que representa el servidor centralizado. Si ese servidor se cae
durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios
versionados de aquello en que estn trabajando. Si el disco duro en el que se encuentra
la base de datos central se corrompe, y no se han llevado copias de seguridad
adecuadamente, pierdes absolutamente todo (toda la historia del proyecto salvo
aquellas instantneas que la gente pueda tener en sus mquinas locales. Los VCSs
locales sufren de este mismo problema) cuando tienes toda la historia del proyecto en
un nico lugar, te arriesgas a perderlo todo.

Entornos de Desarrollo

1.3.

1 DAM

Sistemas de control de versiones distribuidos

Es aqu donde entran los sistemas de control de versiones distribuidos

(Distributed Version Control Systems o DVCSs en ingls). En un DVCS (como Git,
Mercurial, Bazaar o Darcs), los clientes no slo descargan la ltima instantnea de los
archivos: replican completamente el repositorio. As, si un servidor muere, y estos
sistemas estaban colaborando a travs de l, cualquiera de los repositorios de los
clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una
instantnea, en realidad se hace una copia de seguridad completa de todos los datos
(vase Figura 1-3).

Figura 1-3. Diagrama de control de versiones distribuido.

2. GIT
Git es un software de control de versiones, no importa si tenemos un pequeo
proyecto o un enorme sistema de software, GIT nos permite administrar y controlar el
cdigo fuente de una manera muy eficiente, de esta manera la administracin y
organizacin del cdigo al momento de trabajar en equipo se vuelve algo muy sencillo,
permitindonos as centrarnos ms en el diseo y desarrollo del proyecto.
2.1.

Copias instantneas, no diferencias

La principal diferencia entre Git y cualquier otro VCS (incluyendo Subversion y

sus amigos) es la forma en la que manejan sus datos. Conceptualmente, la mayora de
3

Entornos de Desarrollo

1 DAM

los otros sistemas almacenan la informacin como una lista de cambios en los archivos.
Estos sistemas (CVS, Subversion, Perforce, Bazaar, etc.) manejan la informacin que
almacenan como un conjunto de archivos y las modificaciones hechas a cada uno de
ellos a travs del tiempo.
Git no maneja ni almacena sus datos de esta forma. Git maneja sus datos como
un conjunto de copias instantneas de un sistema de archivos miniatura. Cada vez que
confirmas un cambio, o guardas el estado de tu proyecto en Git, l bsicamente toma
una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a
esa copia instantnea. Para ser eficiente, si los archivos no se han modificado Git no
almacena el archivo de nuevo, sino un enlace al archivo anterior idntico que ya tiene
almacenado. Git maneja sus datos como una secuencia de copias instantneas.

2.2.

Qu es Github?

Github es una plataforma online basada en git, que nos permite

almacenar nuestros repositorios git en sus servidores, en otras
palabras, nos permite administrar, revisar, corregir y versionar
nuestro cdigo fuente e incluso nos facilita el trabajo en equipo ya
que varios usuarios pueden acceder al mismo cdigo fuente y
trabajar de manera colaborativa desde cualquier maquina con acceso a internet, incluso
podemos editar algunos archivos de cdigo fuente directamente desde el sitio.
Cabe tambin destacar que hay varias empresas y organizaciones de clase mundial
que estn utilizando github activamente, lo que deja claro que es una herramienta
plenamente funcional y confiable, por mencionar algunas tenemos a: Rackspace,
Facebook, Google, Microsoft, entre otros.

Muy bien, ahora que sabemos que es github, veamos como comenzar a utilizarlo.

Entornos de Desarrollo

2.3.

1 DAM

Utilizacin de Github

Lo primero que tenemos que hacer es registrarnos en Github (https://github.com ).

Una vez registrados nos crearemos un repositorio vaco, ser pblico (que es gratuito).
Nos hemos creado un repositorio llamado DAM1 y hemos incluido el archivo
README.md
Netbeans, cuenta con soporte nativo para Git en todos los proyectos que manejamos
dentro del IDE, una vez que comenzamos a versionar un proyecto, Netbeans nos
mostrar cambios, eliminaciones y archivos o componentes agregados al proyecto.
Una vez creado el repositorio abrimos NetBeans. Y nos vamos a la pestaa TeamClone

En la siguiente ventana introducimos la direccin de nuestro repositorio en Github. En

nuestro caso https://github.com/amarribasa01/DAM1.git
Usuario y password y la carpeta donde queremos que se clone el proyecto

Entornos de Desarrollo

1 DAM

Pulsamos NEXT, seleccionamos la rama principal (master)

Pulsamos NEXT, y dejamos los datos por defecto, y marcamos la opcin Scan for
Netbeans Projects after Clone. Y pulsamos FINISH

Una vez pulsado FINISH, nos aparece la siguiente ventana. Pulsamos Create Project.

Entornos de Desarrollo

1 DAM

Y a partir de ahora nos creamos un proyecto normal en Netbeans. Lo hemos llamado

EjerciciosJava

Creamos en la clase unas sentencias de ejemplo, en nuestro caso, nos

declaramos unas variables, las asignamos un valor y las mostramos por consola.
Una vez guardado y comprobado que nuestro
cdigo NO TIENE ERRORES, es el momento de
actualizar nuestro repositorio local. Vamos a
guardar todo el proyecto, no solamente la clase
Ejercicios.java, para ello nos tenemos que poner
encima del proyecto y pulsamos botn derecho
GitCommit

Entornos de Desarrollo

1 DAM

En la siguiente pantalla, escribimos un

mensaje
significativo
de
la
actualizacin: Prueba Git. Hacemos
clic en el botn Commit y listo,
nuestros cambios se han enviado al
repositorio local.

Ahora para subirlos al repositorio Github, nos ponemos sobre el proyecto y pulsamos
botn derecho: Git Remote Push

Nos aparece la siguiente pantalla, pulsamos Next

En la siguiente pantalla aparece seleccionada la rama local mster que es la que vamos
a subir a GitHub, pulsamos Next

Entornos de Desarrollo

1 DAM

Pulsamos Next y despus Finish:

Una vez hecho esto, nos vamos a nuestro repositorio en GitHub y vemos que se han
subido todos los archivos del proyecto.

Entornos de Desarrollo

2.4.

1 DAM

Git Branching

Hasta ahora hemos visto como crearnos un nuevo proyecto y subirlo al

repositorio, pero cmo modificamos un archivo ya existente? Creando ramas de
desarrollo.
El manejo de ramas o branching es la parte ms atractiva y divertida de trabajar
con Git. Cuando inicializamos o clonamos un repositorio, siempre obtenemos una rama
principal por defecto llamada master a no ser que especifiquemos lo contrario.
Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras.
La rama master es la rama "por defecto" cuando creas un repositorio. Crea nuevas ramas
durante el desarrollo y fusinalas (merge) a la rama principal cuando termines.

Una rama nueva no estar disponible para los dems a menos que subamos (push) la
rama a al repositorio remoto.
Vamos a modificar la anterior clase (EjerciciosJava.java), para ello vamos a hacer un
Checkout (TeamCheckoutCheckout Revisin)

Seleccionamos Checkout as New

Branch y en Branch Name
ponemos testing. Y pulsamos el
botn Checkout

10

Entornos de Desarrollo

1 DAM

En estos momentos tenemos dos ramas, podemos consultarlas

TeamRepositoryRepository Browser. Estamos trabajando en la rama testing.

en

Una vez en nuestro repositorio, en Netbeans hacemos los cambios necesarios y

lo guardamos en nuestro repositorio local (TeamCommit) y despus lo subimos a
GitHub.
Pulsamos TeamRemotePush
Pulsamos Next

11

Entornos de Desarrollo

1 DAM

Seleccionamos la rama testing y

Pulsamos Next, y despus Finish.

Nos aparecer el siguiente mensaje y pulsaremos Yes

Y si consultamos nuestro repositorio vemos que se ha creado la rama de testing

en el servidor GitHub

Ahora, si nos vamos a nuestro repositorio en GitHub, nos avisa que tenemos una
nueva rama (Branch) y la opcin de comparar los archivos de ambas ramas (Compare
& pull Request)

12

Entornos de Desarrollo

1 DAM

En la ventana de comparacin vemos en color verde los cambios realizados:

Y si pulsamos el botn Split, veremos los dos archivos por separado:

13

Entornos de Desarrollo

1 DAM

Si estamos de acuerdo con los cambios, realizamos un Pull Request (una peticin
al propietario del repositorio original para que este ltimo incorpore los commits que
estn en el fork (rama testing )).
Escribimos un comentario y pulsamos el botn Create a pull resquest

El propietario del repositorio principal recibe el aviso, adems se le notifica que

la rama de testing est al da con la rama principal y que puede hacer la mezcla
automticamente, por lo tanto pulsamos Merge pull request

Pulsamos el botn de Confirm merge (confirmar mezcla), podemos escribir el mensaje

que deseemos.

14

Entornos de Desarrollo

1 DAM

Se nos notifica que la mezcla ha sido satisfactoria y pulsamos el botn Delete branch
para eliminar la rama de testing.

Si queremos subir nuevos archivos al repositorio, tan solo tendramos que crear la
clase java que necesitemos, guardar los cambios (Commit) y pulsar TeamAdd y
hacer luego un Push

Para ms informacin:

http://rogerdudler.github.io/git-guide/index.es.html
https://git-scm.com/book/es/v2/
http://www.piradoiv.com/blog/usando-git-con-tus-companeros-de-proyecto

15