3. ¿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”
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
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
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
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
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 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):
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: 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
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
24. ¿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
– ...
25. 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
27. ¿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
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
30. ¿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?
31. 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)
32. 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:
33. 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:
