GIT
Control de versiones
1. ¿Qué es el control de
      versiones?
¿Qué es el control de versiones?
●   Cuando escribimos un programa, nuestro código va
    evolucionando desde la nada hacia la solución final
●   En el camino pueden transcurrir días, semanas, meses,...
●   Es habitual que, durante ese proceso, queramos deshacer
    pasos ya realizados
●   Podría suceder que hay un error en el código generado en
    Febrero, y queramos volver a la versión de Enero
●   También es útil cuando el equipo de desarrollo lo integran
    más de una persona
●   Sin control de versiones, es muy difícil “fundir” el código
    escrito por dos o más programadores
●   Esta tarea, un software de control de versiones la realiza
    “sin pestañear”
Herramientas profesionales de
         control de versiones
●   En el mercado existen muchísimas herramientas de
    control de versiones:
        –   GIT
        –   Subversion (SVN)
        –   CVS
        –   ClearCase
        –   SourceSafe/SourceGear
        –   Team Foundation Server
        –   Mercurial
2. GIT: características
GIT: características
●   Distribuido
●   Gratuito
●   Opensource
●   Multiplataforma: linux, windows, mac,...
●   Se integra con eclipse: egit
●   EGit es la versión gráfica de git, que es de consola
3. Instalación de Git en
         eclipse
Instalación de EGit en eclipse
●   Desde eclipse/help/install new software:
Comprobar instalación OK
●   Para comprobar que todo ha ido bien, crea un nuevo
    proyecto en eclipse
●   En el explorador de proyectos, pulsa botón derecho sobre
    el nodo del proyecto, y deberá aparecerte una nueva
    entrada llamada Team
4. Ficheros que
queremos ignorar
.gitignore
●   En un proyecto de desarrollo de software es habitual
    descartar ciertos ficheros del control de versiones
●   Lo importante es nuestro código
●   Todo aquello que no pertenezca al código, podemos y
    debemos eliminarlo del control de versiones
        –   Los ficheros compilados
        –   ...
●   Para ello, generamos un fichero que llamamos .gitignore
    dentro de nuestro proyecto y lo completamos con los
    ficheros y directorios a ignorar
Ejemplo de .gitignore
●   Éste es el aspecto de mi fichero .gitignore:
5. Poner proyecto bajo
 control de versiones
Creamos nuestro proyecto
●   Creamos nuestro proyecto Java como lo hemos hecho
    siempre
●   Y le añadimos un primer fichero, por ejemplo Main.java
    con un simple Hola Mundo:
Poner proyecto en GIT
●   El primer paso es poner nuestro proyecto bajo control de
    versiones
●   Lo ideal es hacer esto al principio, justo en el momento de
    nacer nuestro proyecto
●   Aún así, podemos poner un proyecto ya avanzado bajo
    control de versiones
●   En la siguiente secuencia de imágenes se muestra cómo
    incorporar nuestro proyecto al control de versiones (pág.
    siguiente):
Poner proyecto en GIT: pasos
Nuestro proyecto está en GIT
●   Fíjate que en el explorador de proyectos, aparece un
    icono ? junto a cada componente
Primer commit
●   En Window/Show Víew/Other, seleccionamos
    Git/Git Staging
●   Seleccionamos todos los ficheros que figuran
    en Unstaged Changes y los arrastramos a
    Staged Changes
●   Escribimos un mensaje con el que
    recordaremos el paso que hemos dado, por
    ejemplo, “Primer commit”
Project explorer: cambian los
                iconos
●   Como vemos, ahora que ya hemos hecho un commit, los
    iconos cambian, pasan de un “?” a el clásico símbolo de
    base de datos
●   Así indica que estos ficheros y todos sus cambios están
    registrados por GIT




    Antes del commit                 Después del commit
6. Hacer cambios y
   subirlos a GIT
Cambiamos “Hola mundo” por
          “Adios mundo”
●   En nuestro fichero Main.java, cambiamos el saludo “Hola
    mundo por “Adios mundo”
●   Graba los cambios
●   En el explorador de proyectos, aparece un icono “>” junto
    a los elementos que se han modificado:
Cambiamos “Hola mundo” por
          “Adios mundo”
●   En la ventana Git Staging aparece el fichero Main.java
    como que tiene cambios
●   Lo arrastramos a Staged Changes
●   Añadimos un mensaje alusivo
●   Commit
7. Mostrar los cambios
¿Por qué es importante?
●   En ocasiones puede ser importante mostrar los cambios
    que han tenido lugar en un fichero
        –   qué líneas se han añadido
        –   qué líneas se han eliminado
        –   qué cambios se han introducido en una línea
        –   qué ficheros se han añadido
        –   qué ficheros se han eliminado
        –   quién hizo esos cambios
        –   ...
Mostrar historial de versiones
   ●   Sobre el nodo del proyecto/Team/Show in History:
Aquí están las 2 versiones
que tenemos de momento,
   una por cada commit

                                                     Ficheros modificados,
                                                     añadidos, eliminados,...
                                                         en esa versión




                          Mensaje que pusimos
                       a la hora de subir (commit)
                            nuestros cambios
8. Deshacer cambios
¿Por qué es importante?
●   Supón que has estado modificando tu proyecto durante
    varias horas, pero llegas a la conclusión de que estos
    cambios no te interesan
●   Has modificado varios ficheros
●   Has añadido nuevos
●   Has eliminado otros
●   Es muy difícil recordar exactamente qué cambios has
    hecho para poder revertir la situación manualmente
●   La opción de CTRL-Z se queda corta, porque son muchos
    los cambios
●   En Git podemos hacer un Hard reset, que vuelca sobre
    nuestra copia local lo que hay en GIT, es decir, la última
    versión del código anterior a nuestros cambios
Hard reset
●   Botón derecho sobre el nodo del proyecto/ Team/ Reset:
●   Listo, nos hemos descargado a nuestra copia local lo que
    tiene GIT
●   De esta manera descartamos
    nuestros cambios
9. Mostrar diferencias
¿Por qué es importante?
●   Supongamos que llevas varias horas (días, semanas,...)
    trabajando en el proyecto
●   Has incorporado nuevas funcionalidades que van bien
●   Sin embargo, hay un fichero que da problemas en esta
    nueva versión
●   ¿Qué he tocado aquí para que ahora falle?
Mostrar diferencias con copia
                 local
●   En la ventana del historial de versiones, seleccionamos el
    fichero que queremos comparar, botón derecho, comparar
    con copia de trabajo (o local)
Mostrar diferencias con copia
                 local
●   Nos abre una nueva ventana con las líneas que se han
    modificado, y dentro de ésta, exactamente qué
    modificaciones ha sufrido:
Mostrar diferencias con versión
                anterior
●   Igual manera podría interesarnos qué cambios han habido
    en un fichero en la última versión con respecto de la
    anterior
●   En el historial de versiones, en lugar de comparar con
    copia de trabajo, comparar con Ancestor:

Git: control de versiones

  • 1.
  • 2.
    1. ¿Qué esel control de versiones?
  • 3.
    ¿Qué es elcontrol de versiones? ● Cuando escribimos un programa, nuestro código va evolucionando desde la nada hacia la solución final ● En el camino pueden transcurrir días, semanas, meses,... ● Es habitual que, durante ese proceso, queramos deshacer pasos ya realizados ● Podría suceder que hay un error en el código generado en Febrero, y queramos volver a la versión de Enero ● También es útil cuando el equipo de desarrollo lo integran más de una persona ● Sin control de versiones, es muy difícil “fundir” el código escrito por dos o más programadores ● Esta tarea, un software de control de versiones la realiza “sin pestañear”
  • 4.
    Herramientas profesionales de control de versiones ● En el mercado existen muchísimas herramientas de control de versiones: – GIT – Subversion (SVN) – CVS – ClearCase – SourceSafe/SourceGear – Team Foundation Server – Mercurial
  • 5.
  • 6.
    GIT: características ● Distribuido ● Gratuito ● Opensource ● Multiplataforma: linux, windows, mac,... ● Se integra con eclipse: egit ● EGit es la versión gráfica de git, que es de consola
  • 7.
    3. Instalación deGit en eclipse
  • 8.
    Instalación de EGiten eclipse ● Desde eclipse/help/install new software:
  • 9.
    Comprobar instalación OK ● Para comprobar que todo ha ido bien, crea un nuevo proyecto en eclipse ● En el explorador de proyectos, pulsa botón derecho sobre el nodo del proyecto, y deberá aparecerte una nueva entrada llamada Team
  • 10.
  • 11.
    .gitignore ● En un proyecto de desarrollo de software es habitual descartar ciertos ficheros del control de versiones ● Lo importante es nuestro código ● Todo aquello que no pertenezca al código, podemos y debemos eliminarlo del control de versiones – Los ficheros compilados – ... ● Para ello, generamos un fichero que llamamos .gitignore dentro de nuestro proyecto y lo completamos con los ficheros y directorios a ignorar
  • 12.
    Ejemplo de .gitignore ● Éste es el aspecto de mi fichero .gitignore:
  • 13.
    5. Poner proyectobajo control de versiones
  • 14.
    Creamos nuestro proyecto ● Creamos nuestro proyecto Java como lo hemos hecho siempre ● Y le añadimos un primer fichero, por ejemplo Main.java con un simple Hola Mundo:
  • 15.
    Poner proyecto enGIT ● El primer paso es poner nuestro proyecto bajo control de versiones ● Lo ideal es hacer esto al principio, justo en el momento de nacer nuestro proyecto ● Aún así, podemos poner un proyecto ya avanzado bajo control de versiones ● En la siguiente secuencia de imágenes se muestra cómo incorporar nuestro proyecto al control de versiones (pág. siguiente):
  • 16.
  • 17.
    Nuestro proyecto estáen GIT ● Fíjate que en el explorador de proyectos, aparece un icono ? junto a cada componente
  • 18.
    Primer commit ● En Window/Show Víew/Other, seleccionamos Git/Git Staging ● Seleccionamos todos los ficheros que figuran en Unstaged Changes y los arrastramos a Staged Changes ● Escribimos un mensaje con el que recordaremos el paso que hemos dado, por ejemplo, “Primer commit”
  • 19.
    Project explorer: cambianlos iconos ● Como vemos, ahora que ya hemos hecho un commit, los iconos cambian, pasan de un “?” a el clásico símbolo de base de datos ● Así indica que estos ficheros y todos sus cambios están registrados por GIT Antes del commit Después del commit
  • 20.
    6. Hacer cambiosy subirlos a GIT
  • 21.
    Cambiamos “Hola mundo”por “Adios mundo” ● En nuestro fichero Main.java, cambiamos el saludo “Hola mundo por “Adios mundo” ● Graba los cambios ● En el explorador de proyectos, aparece un icono “>” junto a los elementos que se han modificado:
  • 22.
    Cambiamos “Hola mundo”por “Adios mundo” ● En la ventana Git Staging aparece el fichero Main.java como que tiene cambios ● Lo arrastramos a Staged Changes ● Añadimos un mensaje alusivo ● Commit
  • 23.
  • 24.
    ¿Por qué esimportante? ● En ocasiones puede ser importante mostrar los cambios que han tenido lugar en un fichero – qué líneas se han añadido – qué líneas se han eliminado – qué cambios se han introducido en una línea – qué ficheros se han añadido – qué ficheros se han eliminado – quién hizo esos cambios – ...
  • 25.
    Mostrar historial deversiones ● Sobre el nodo del proyecto/Team/Show in History: Aquí están las 2 versiones que tenemos de momento, una por cada commit Ficheros modificados, añadidos, eliminados,... en esa versión Mensaje que pusimos a la hora de subir (commit) nuestros cambios
  • 26.
  • 27.
    ¿Por qué esimportante? ● Supón que has estado modificando tu proyecto durante varias horas, pero llegas a la conclusión de que estos cambios no te interesan ● Has modificado varios ficheros ● Has añadido nuevos ● Has eliminado otros ● Es muy difícil recordar exactamente qué cambios has hecho para poder revertir la situación manualmente ● La opción de CTRL-Z se queda corta, porque son muchos los cambios ● En Git podemos hacer un Hard reset, que vuelca sobre nuestra copia local lo que hay en GIT, es decir, la última versión del código anterior a nuestros cambios
  • 28.
    Hard reset ● Botón derecho sobre el nodo del proyecto/ Team/ Reset: ● Listo, nos hemos descargado a nuestra copia local lo que tiene GIT ● De esta manera descartamos nuestros cambios
  • 29.
  • 30.
    ¿Por qué esimportante? ● Supongamos que llevas varias horas (días, semanas,...) trabajando en el proyecto ● Has incorporado nuevas funcionalidades que van bien ● Sin embargo, hay un fichero que da problemas en esta nueva versión ● ¿Qué he tocado aquí para que ahora falle?
  • 31.
    Mostrar diferencias concopia local ● En la ventana del historial de versiones, seleccionamos el fichero que queremos comparar, botón derecho, comparar con copia de trabajo (o local)
  • 32.
    Mostrar diferencias concopia local ● Nos abre una nueva ventana con las líneas que se han modificado, y dentro de ésta, exactamente qué modificaciones ha sufrido:
  • 33.
    Mostrar diferencias conversión anterior ● Igual manera podría interesarnos qué cambios han habido en un fichero en la última versión con respecto de la anterior ● En el historial de versiones, en lugar de comparar con copia de trabajo, comparar con Ancestor: