Download - Control de Versiones
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