Control de Versiones

download Control de Versiones

of 15

  • date post

    13-Feb-2016
  • Category

    Documents

  • view

    10
  • download

    0

Embed Size (px)

description

Control de Versiones Git

Transcript of Control de Versiones

  • Entornos de Desarrollo 1 DAM

    1

    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 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 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 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 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

  • Entornos de Desarrollo 1 DAM

    4

    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 1 DAM

    5

    2.3. 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

    6

    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

    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

    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

    8

    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

    9

    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 1 DAM

    10

    2.4. 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 par