Entornos de Desarrollo 1º DAM

1

1. ACERCA DEL CONTROL DE VERSIONES

¿Qué es el control de versiones, y por qué debería 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 específicas más adelante.

Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección 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 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 VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.

1.1. Sistemas de control de versiones locales

Un método de control de versiones usado por mucha gente es copiar los archivos a otro directorio (quizás indicando la fecha y hora en que lo hicieron, si son avispados). Este enfoque es muy común porque es muy simple, pero también tremendamente propenso a errores. Es fácil olvidar en qué directorio te encuentras, y guardar accidentalmente en el archivo equivocado o sobrescribir archivos que no querías.

Para hacer frente a este problema, los programadores desarrollaron hace tiempo VCSs locales que contenían una simple base de datos en la que se llevaba registro de todos los cambios realizados sobre los archivos (véase Figura 1-1).

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

Entornos de Desarrollo 1º DAM

2

1.2. 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 inglés). 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 años éste ha sido el estándar para el control de versiones (véase Figura 1-2).

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

Esta configuración ofrece muchas ventajas, especialmente frente a VCSs locales. Por ejemplo, todo el mundo puede saber (hasta cierto punto) en qué están trabajando los otros colaboradores del proyecto. Los administradores tienen control detallado de qué puede hacer cada uno; y es mucho más fácil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente.

Sin embargo, esta configuración también tiene serias desventajas. La más 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 están 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 instantáneas que la gente pueda tener en sus máquinas 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º DAM

3

1.3. Sistemas de control de versiones distribuidos

Es aquí donde entran los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos (véase 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 pequeño

proyecto o un enorme sistema de software, GIT nos permite administrar y controlar el

código fuente de una manera muy eficiente, de esta manera la administración y

organización del código al momento de trabajar en equipo se vuelve algo muy sencillo,

permitiéndonos así centrarnos más en el diseño y desarrollo del proyecto.

2.1. Copias instantáneas, 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 mayoría de

Entornos de Desarrollo 1º DAM

4

los otros sistemas almacenan la información como una lista de cambios en los archivos. Estos sistemas (CVS, Subversion, Perforce, Bazaar, etc.) manejan la información que almacenan como un conjunto de archivos y las modificaciones hechas a cada uno de ellos a través del tiempo.

Git no maneja ni almacena sus datos de esta forma. Git maneja sus datos como un conjunto de copias instantáneas de un sistema de archivos miniatura. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente toma una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa copia instantánea. Para ser eficiente, si los archivos no se han modificado Git no almacena el archivo de nuevo, sino un enlace al archivo anterior idéntico que ya tiene almacenado. Git maneja sus datos como una secuencia de copias instantáneas.

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 código fuente e incluso nos facilita el trabajo en equipo ya

que varios usuarios pueden acceder al mismo código fuente y

trabajar de manera colaborativa desde cualquier maquina con acceso a internet, incluso

podemos editar algunos archivos de código fuente directamente desde el sitio.

Cabe también destacar que hay varias empresas y organizaciones de clase mundial

que están 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 1º DAM

5

2.3. Utilización de Github

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

Una vez registrados nos crearemos un repositorio vacío, será público (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 pestaña TeamClone

En la siguiente ventana introducimos la dirección 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

6

Pulsamos NEXT, seleccionamos la rama principal (master)

Pulsamos NEXT, y dejamos los datos por defecto, y marcamos la opción 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

7

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

código 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 botón derecho

GitCommit

Entornos de Desarrollo 1º DAM

8

En la siguiente pantalla, escribimos un

mensaje significativo de la

actualización: “Prueba Git”. Hacemos

clic en el botón Commit y listo,

nuestros cambios se han enviado al

repositorio local.

Ahora para subirlos al repositorio Github, nos ponemos sobre el proyecto y pulsamos

botón derecho: Git Remote Push …

Nos aparece la siguiente pantalla, pulsamos Next

En la siguiente pantalla aparece seleccionada la rama local máster que es la que vamos

a subir a GitHub, pulsamos Next

Entornos de Desarrollo 1º DAM

9

Pulsamos Next y después 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 1º DAM

10

2.4. Git Branching

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

repositorio, pero ¿cómo modificamos un archivo ya existente? Creando ramas de

desarrollo.

El manejo de ramas o branching es la parte más 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 fusiónalas (merge) a la rama principal cuando termines.

Una rama nueva no estará disponible para los demás 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 Revisión…)

Seleccionamos Checkout as New

Branch y en Branch Name

ponemos testing. Y pulsamos el

botón Checkout

Entornos de Desarrollo 1º DAM

11

En estos momentos tenemos dos ramas, podemos consultarlas en

TeamRepositoryRepository Browser. Estamos trabajando en la rama testing.

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

lo guardamos en nuestro repositorio local (TeamCommit) y después lo subimos a

GitHub.

Pulsamos TeamRemotePush

Pulsamos Next

Entornos de Desarrollo 1º DAM

12

Seleccionamos la rama testing y

Pulsamos Next, y después 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 opción de comparar los archivos de ambas ramas (Compare

& pull Request)

Entornos de Desarrollo 1º DAM

13

En la ventana de comparación vemos en color verde los cambios realizados:

Y si pulsamos el botón Split, veremos los dos archivos por separado:

Entornos de Desarrollo 1º DAM

14

Si estamos de acuerdo con los cambios, realizamos un Pull Request (una petición

al propietario del repositorio original para que este último incorpore los commits que

están en el fork (rama testing )).

Escribimos un comentario y pulsamos el botón Create a pull resquest

El propietario del repositorio principal recibe el aviso, además se le notifica que

la rama de testing está al día con la rama principal y que puede hacer la mezcla

automáticamente, por lo tanto pulsamos Merge pull request

Pulsamos el botón de Confirm merge (confirmar mezcla), podemos escribir el mensaje

que deseemos.

Entornos de Desarrollo 1º DAM

15

Se nos notifica que la mezcla ha sido satisfactoria y pulsamos el botón Delete branch

para eliminar la rama de testing.

Si queremos subir nuevos archivos al repositorio, tan solo tendríamos que crear la

clase java que necesitemos, guardar los cambios (Commit) y pulsar TeamAdd y

hacer luego un Push

Para más información:

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