CICLO: DESARROLLO DE

APLICACIONES WEB
MODALIDAD: DISTANCIA
MÓDULO: ENTORNOS DE
DESARROLLO

UNIDAD DE TRABAJO 4:
OPTIMIZACIÓ Y
DOCUMENTACIÓN
 Índice

1.- Refactorización
2.- Control de Versiones
3.- Documentación
2. CONTROL DE
VERSIONES
Control de Versiones
 Capacidad de recordar todos los cambios que se realizan tanto en
la estructura de directorios como en el contenido de los archivos.
 Esto es de mucha utilidad cuando se desea recuperar un
documento, o una carpeta o un proyecto en un momento concreto
de su desarrollo.
 También es muy útil cuando se necesita mantener un cierto
control de los cambios que se realizan sobre documentos,
archivos o proyectos que comparten varias personas o un equipo
de trabajo; se hace necesario saber qué cambios se hacen,
quién los hace y cuándo se realizan.
 Sistemas de Control de Versiones
 Facilita al equipo de desarrollo poder trabajar en un mismo proyecto
de forma simultánea, permitiendo gestionar los conflictos que se
puedan producir por cambios simultáneos en el mismo código.
 Proveen de un sitio central donde almacenar el código fuente de la
aplicación así como el historial de cambios realizados a lo largo de la
vida del proyecto.
 Permite volver a versiones estables previas del código fuente.
 Versión: forma particular de un objeto en un instante o contexto dado.
Se denomina revisión cuando se refiere a la evolución en el tiempo.
 Pueden coexistir varias versiones alternativas en un instante dado y
mediante control de versiones disponemos de un método, para
designar las diferentes versiones de manera organizada.
 Tipos: Control de Versiones Local
 La información se guarda en
diferentes directorios en
función de sus versiones.
 Toda la gestión recae sobre
el responsable del proyecto y
no se dispone de
herramientas que
automaticen el proceso.
 Es viable para pequeños
proyectos donde el trabajo es
desarrollado por un único
programador.
 Tipos: Control de Versiones Centralizado
 Usan una arquitectura
cliente-servidor: Un único
equipo tiene todos los
archivos en sus diferentes
versiones, y los clientes
replican esta información en
sus entornos de trabajo
locales.
 El principal inconveniente es
que el servidor es un
dispositivo crítico para el
sistema ante posibles fallos.
 Tipos: Control de Versiones Distribuidos
 Cada sistema hace con una copia completa
de los ficheros de trabajo y de todas sus
versiones.
 El rol de todos los equipos es de igual a
igual y los cambios se pueden sincronizar
entre cada par de copias disponibles.
 Aunque técnicamente todos los repositorios
tienen la posibilidad de actuar como punto
de referencia, habitualmente funcionan
siendo uno el repositorio principal y el resto
asumiendo un papel de clientes
sincronizando sus cambios con éste.
Control de Versiones. Funcionalidades
 Comparar cambios en los diferentes archivos a lo largo del tiempo
 Reducción de problemas de coordinación que puede haber entre los
diferentes programadores
 Posibilidad de acceder a versiones anteriores de los documentos o
código fuente
 Ver quién ha sido el último en modificar un determinado trozo de
código
 Acceso al historial de cambios sobre todos los archivos a medida
que avanza el proyecto
 Volver un archivo o todo el proyecto a uno o varios estados
anteriores
Control de Versiones. Funcionalidades
 Control histórico detallado de cada archivo, almacenar toda la
información de lo que ha sucedido en un archivo
 Control de usuarios con permisos para acceder a los archivos.
Gestión de todos los usuarios posibles y los permisos que tienen
asignados
 Creación de ramas de un mismo proyecto, hay momentos en que
hay que ramificar y poder seguir desarrollando por separado
 Fusionar dos versiones de un mismo archivo, cogiendo el código
que más interese
Estructura de herramientas de Control de
Versiones.
 Es un sistema de mantenimiento de código fuente (grupos de archivos en
general) extraordinariamente útil para grupos de desarrolladores que trabajan
cooperativamente usando alguna clase de red.
 Permite a un grupo de desarrolladores trabajar y modificar concurrentemente
ficheros organizados en proyectos (dos o más personas pueden modificar un
mismo fichero sin que se pierdan los trabajos de ninguna)
 Las operaciones más habituales suelen ser muy sencillas de usar.
 Estructura de herramientas de Control de
Versiones. CVS.
CVS utiliza una arquitectura cliente-servidor
 El servidor guarda la versión actual del proyecto y su historia
 Los clientes conectan al servidor para sacar una copia completa del proyecto, trabajar en esa copia y
entonces ingresar sus cambios.
 Típicamente, cliente y servidor conectan utilizando Internet, pero cliente y servidor pueden estar en la
misma máquina.
 El servidor normalmente utiliza un sistema operativo similar a Unix, mientras que los
clientes CVS pueden funcionar en cualquier de los sistemas operativos más difundidos
 Los clientes pueden también comparar diferentes versiones de ficheros, solicitar una historia completa
de los cambios, o sacar una "foto" histórica del proyecto tal como se encontraba en una fecha
determinada o en un número de revisión determinado.
 Muchos proyectos de código abierto permiten el "acceso de lectura anónimo", significando que los
clientes pueden sacar y comparar versiones sin necesidad de teclear una contraseña; solamente el
ingreso de cambios requiere una contraseña en estos escenarios.
 Los clientes también pueden utilizar el comando de actualización con el fin de tener sus copias al día
con la última versión que se encuentra en el servidor. Esto elimina la necesidad de repetir las descargas
del proyecto completo.
Estructura de herramientas de Control de
Versiones. Componentes
 Repositorio. Lugar dónde se almacenan todos los datos y los cambios. Sistema de
archivos en disco duro, un banco de datos, un servidor…
 Módulo. Carpeta o directorio específico del repositorio. Podrá hacer referencia a todo el
proyecto entero o sólo a una parte del proyecto
 Revisión o versión. Estado del proyecto o de una de sus ramas en un momento
determinado. Se crea una versión cada vez que se añaden cambios a un repositorio
 Etiqueta: información textual que se añade a un conjunto de archivos o a un módulo
completo para indicar alguna información importante. Identifican las revisiones o
versiones importantes en el proyecto, para localizarlas y recuperarlas. A menudo indica
alguna característica específica que lo hace especial
 Tronco (trunk o master). Es la línea principal del desarrollo del proyecto.
 Rama (branch). Bifurcación del tronco o rama maestra de la aplicación, contiene una
versión independiente de la aplicación y a la que pueden aplicarse cambios sin que
afecten ni el tronco ni otras ramas. Estos cambios, en un futuro, pueden incorporarse al
tronco. (nuevas funcionalidades o corrección de errores)
 Estructura de herramientas de Control de
Versiones. Servicios
 Creación de repositorios. Creación del esqueleto de un repositorio sin información inicial del
proyecto.
 Clonación de repositorios. La clonación crea un nuevo repositorio y vuelca la información
de algún otro repositorio ya existente. Crea una réplica.
 Descarga de la información del repositorio principal al local. Sincroniza la copia local con
la información disponible en el repositorio principal.
 Carga de información al repositorio principal desde el local. Actualiza los cambios
realizados en la copia local en el repositorio principal.
 Gestión de conflictos. En ocasiones, los cambios que se desean consolidar en el repositorio
principal entran en conflicto con otros cambios que hayan sido subidos por algún otro
desarrollador. Cuando se da esta situación, las herramientas de control de versiones tratan
de combinar automáticamente todos los cambios. Si no es posible sin pérdida de información,
muestra al programador los conflictos acontecidos para que sea éste el que tome la decisión
de como combinarlos.
 Estructura de herramientas de Control de
Versiones. Servicios
 Gestión de ramas. Creación, eliminación , integración de diferencias entre ramas, selección
de la rama de trabajo.
 Información sobre registro de actualizaciones.
 Comparativa de versiones. Genera información sobre las diferencias entre versiones del
proyecto.

Las órdenes que se pueden ejecutar son:

 Checkout: obtiene un copia del trabajo para poder trabajar con ella.
 Update: actualiza la copia con cambios recientes en el repositorio.
 Commit: almacena la copia modificada en el repositorio.
 Abort: abandona los cambios en la copia de trabajo.
 Estructura de herramientas de Control de
Versiones. Repositorio
 Es la parte fundamental de un sistema de control de versiones. Almacena toda la información
y datos de un proyecto.
 Es un almacén general de versiones. Suele ser un directorio.
 Centraliza todos los componentes de un mismo sistema, incluyendo las distintas versiones de
cada componente. Se consigue así, un ahorro de espacio de almacenamiento, ya que
estamos evitando guardar por duplicado, los elementos que son comunes a varias versiones.
 Facilita el almacenaje de la información de la evolución del sistema, ya que, aparte de los
datos en sí mismo, también almacena información sobre las versiones, temporización, etc.
 Estructura de herramientas de Control de
Versiones. Gestión de versiones y entregas.
 Las versiones Las versiones hacen referencia a la evolución de un único elemento, dentro de
un sistema software.
 La evolución puede representarse en forma de grafo, donde los nodos son las versiones y los
arcos corresponden a la creación de una versión a partir de otra ya existente.
 Grafo de evolución simple: las revisiones sucesivas de un componente dan lugar a una
simple secuencia lineal. Esta evolución no presenta problemas en la organización del
repositorio y las versiones se designan mediante números correlativos.
 Variantes: en este caso, existen varias versiones del componente. El grafo ya no es una
secuencia lineal, si no que adopta la forma de un árbol. La numeración de las versiones
requerirá dos niveles. El primer número designa la variante (línea de evolución) y el segundo
la versión particular (revisión) a lo largo de dicha variante.
La terminología que se usa para referirse a los elementos del grafo son:
 Tronco (trunk): es la variante principal.
 Cabeza (head): es la última versión del tronco.
 Ramas (branches): son la variantes secundarias.
 Delta: es el cambio de una revisión respecto a la anterior
 Estructura de herramientas de Control de
Versiones. Gestión de versiones y entregas.
 Propagación de cambios: cuando se tienen variantes que se desarrollan en paralelo, suele
ser necesario aplicar un mismo cambio a varias variantes.
 Fusión de variantes: en determinados momentos puede dejar de ser necesario mantener
una rama independiente. En este caso se puede fundir con otra (MERGE).
 Técnicas de almacenamiento: como en la mayoría de los casos, las distintas versiones
tienen en común gran parte de su contenido, se organiza el almacenamiento para que no se
desaproveche espacio repitiendo los datos en común de varias versiones.
 Deltas directos: se almacena la primera versión completa, y luego los cambios mínimos
necesarios para reconstruir cada nueva versión a partir de la anterior.
 Deltas inversos: se almacena completa la última versión del tronco y los cambios
necesarios para reconstruir cada versión anterior a partir de la siguiente. En las ramas
se mantiene el uso de los deltas directos.
 Marcado selectivo: se almacena el texto refundido de todas las versiones como una
secuencia lineal, marcando cada sección del conjunto con los números de versiones que
corresponde.
 Estructura de herramientas de Control de
Versiones. Gestión de versiones y entregas.
 En cuanto a la gestión de entregas, en primer lugar definimos el concepto de entrega como
una instancia de un sistema que se distribuye a los usuarios externos al equipo de desarrollo.
 La planificación de la entrega se ocupa de cuándo emitir una versión del sistema como una
entrega.
 La entrega está compuesta por el conjunto de programas ejecutables, los archivos de
configuración que definan como se configura la entrega para una instalación particular, los
archivos de datos que se necesitan para el funcionamiento del sistema, un programa de
instalación para instalar el sistema en el hardware de destino, documentación electrónica y en
papel, y, el embalaje y publicidad asociados, diseñados para esta entrega
 Actualmente los sistemas se entregan en discos ópticos (CD o DVD) o como archivos de
instalación descargables desde la red.
Herramientas de control de versiones
 Azure DevOps Server (anteriormente Team Foundation Server (TFS)): producto
de Microsoft que proporciona control de versiones, informes, gestión de
requisitos , gestión de proyectos, compilaciones automatizadas, gestión de
laboratorio y pruebas. Cubre todo el ciclo de vida de la aplicación. Diseñado
para Microsoft Visual Studio y Eclipse
 CVS - Concurrent Versions System. Sistema de control de versiones
centralizado
 Subversion(SVN). Herramienta de código abierto, gratuito, independiente del
sistema operativo de la máquina en que se utilice. Es un sistema centralizado.
En el 2000 con el objetivo de sustituir CVS. Añade nuevas funcionalidades y
mejora algunas otras que no acababan de funcionar adecuadamente con la
herramienta CVS
Herramientas de control de versiones
 Mercurial. Herramienta funciona en Linux, Windows y Mac OS X. Permite que
el desarrollo se haga distribuido, gestionando de forma robusta archivos de
texto y binarios. Tiene capacidades avanzadas de ramificación e integración.
 Git. Diseñada por Linus Torvalds. A partir de evoluciones de la herramienta
CVS, ya que Subversion no cubría las necesidades de los desarrolladores del
núcleo de Linux. Es un sistema distribuido y gratuito. Actualmente es el
software más popular de control de versión con diferencia.
SUBVERSION
 SUBVERSION es una herramienta multiplataforma (Windos, Linux, Max, etc.)
de código abierto para el control de versiones.
 Usa una base de datos central, el repositorio, que contiene los archivos cuyas
versiones y respectivas historias se controlan.
 El repositorio actúa como un servidor de ficheros, con la capacidad de recordar
todos los cambios que se hacen tanto en sus directorios como en sus ficheros.
 Un proyecto en SUBVERSION debe verse como un árbol que tiene su tronco
(trunk) donde está la línea principal de su desarrollo; que tiene sus ramas
(branches) en las que se añadirán nuevas funciones o se corregirán errores; y
que además tiene sus etiquetas (tags) para marcar situaciones importantes, o
versiones finalizadas.
SUBVERSION
 Así, la estructura de carpetas recomendada en la creación de proyectos
utilizando estas herramientas, y la funcionalidad que se le debe dar a cada
carpeta dentro del repositorio son las siguientes:
 Trunk (tronco). Base común para guardar las carpetas del proyecto o
trabajo a controlar. Es donde está la versión básica, es decir, la rama de
desarrollo principal.
 Tags (etiquetas). Una etiqueta es una copia del proyecto, de una carpeta
o del archivo que se hace con el objetivo de obtener una versión que no se
va a modificar. Debe ser copias del tronco (trunk). Útil para crear versiones
ya finalizadas, aquí se guardarán las versiones cerradas de los proyectos.
 Branches (ramas). En las ramas se desarrollan versiones que luego se
van a publicar. Es una copia del tronco, de un proyecto, de una carpeta o
de un archivo con la intención de modificar sobre ella, para conseguir un
producto final diferente y alternativo al original.
SUBVERSION
 Vamos a ver un posible ciclo de vida de SUBVERSION:

 A. Partimos del desarrollo inicial en el trunk

 B. Se crea una rama porque hay que añadir una nueva funcionalidad.
SUBVERSION
 C. Mientras tanto se ha corregido un bug en el tronco principal (C). Una vez que está lista
la rama se fusiona con el trunk. Cuando esté lista esta versión libre de bugs y con nueva
funcionalidad se crea la primera versión disponible para el público (Tag 1.0)
 D. Después de salir la primera versión se han detectado nuevos bugs, y se necesita
añadir nuevas funcionalidades. Entonces se crea una rama para desarrollar una nueva
funcionalidad.
 E. Se ha creado otra rama porque se necesitan otras funcionalidades.
 F. Se realiza la fusión de las dos ramas, primero se realiza una copia de ellas y luego se
fusiona con la otra.
 G. Se incorporan las nuevas funcionalidades al tronco principal. Una vez que está lista
esta revisión se crea una nueva versión para el público (Tag 1.1).
 H. Se han detectado nuevos bugs y se necesita añadir nuevas funcionalidades. Se crea
una nueva rama para desarrollar una nueva funcionalidad.
 I. Se incorporan las nuevas funcionalidades al tronco principal. Se crea una nueva
versión para el publico (Tag 1.2).
EJEMPLO SUBVERSION EN NETBEANS
 Para no tener que montar un servidor SUBVERSION en local (que podríamos
hacerlo sin ningún tipo de problema) vamos a utilizar uno gratuito en la nube. Al
ser un servicio gratuito tiene algunas limitaciones pero para nuestro proyecto será
suficiente. Para nuestro caso vamos a utilizar: https://riouxsvn.com/
 Nos tenemos que crear una cuenta (Sign up) y nos llegará un código de activación.
 Una vez que hemos creado la cuenta y nos hemos logeado, lo primero que
haremos será crear un repositorio que es lugar donde iremos almacenando todos
los datos y los cambios que se vayan realizando.
 Para ello nos iremos a la pestaña de Repositories y pulsaremos sobre crear nuevo
repositorio
EJEMPLO SUBVERSION EN NETBEANS

 Podemos indicar como título PrimerProyectoSubversion y como nombre

proyectosvn1 y pulsaremos en Next Step. (si da problemas el nombre del
repositorio, probad personalizándolo).
EJEMPLO SUBVERSION EN NETBEANS
 En el segundo paso podemos indicarle que nos cree que ya el tronco, las ramas
y las etiquetas de directorio pero vamos a dejarlo desmarcado como está.
EJEMPLO SUBVERSION EN NETBEANS
 En el último paso podemos indicar si queremos que nos notifiquen cualquier
cambio que se haga en el repositorio vía e-mail. Lo dejamos tal y como está y tras
pulsar en Confirm Creation ya tendríamos el repositorio creado.
EJEMPLO SUBVERSION EN NETBEANS
 Si pulsamos en el menú de la izquierda sobre el repositorio nos lleva a un
formulario de actividad en el que podemos comprobar que aún no hemos
realizado ningún cambio

 En este formulario tenemos un dato MUY IMPORTANTE que es la URL del

repositorio de SUBVERSION
EJEMPLO SUBVERSION EN NETBEANS
 Esta es la dirección que utilizaremos en NetBeans, es decir, será el repositorio
que sincronizaremos con NetBeans.
 Copiaremos esta dirección y la utilizaremos en un proyecto que tengamos ya
creado en NetBeans y que queramos subir a nuestro repositorio (para nuestro
ejemplo utilizaremos el proyecto EntornosUT4).
 Una vez copiada la dirección de la URL de nuestro repositorio y antes de hacer
nada haremos un Import hacia el repositorio (que en la actualidad no tiene nada).
Entre otras formas esto se puede hacer, pulsando botón derecho sobre el
proyecto y elegimos la opción Versioning --> Import into Subversion Repository
EJEMPLO SUBVERSION EN NETBEANS
 Deberemos indicar los datos de Subversion
EJEMPLO SUBVERSION EN NETBEANS
 Indicaremos el proyecto
y tendremos que
indicarle una carpeta
(podemos seleccionar
EntornosUT4) y
especificar un mensaje
(yo he puesto Subida
Inicial, aunque
deberíamos ser más
específicos).
EJEMPLO SUBVERSION EN NETBEANS
 Le indicaremos todos los
ficheros que deseamos
que incorpore a
Subversión. Por defecto
vienen marcados todos y
así lo dejaremos.
 Podemos ver que
tenemos el directorio
(EntornosUT4) y el resto
de ficheros
 Pulsamos Finish
EJEMPLO SUBVERSION EN NETBEANS
 Si actualizamos ahora nuestro repositorio subversión podemos ver que tenemos ya dos
actividades en el mismo.

 En el primero ha creado la carpeta

EJEMPLO SUBVERSION EN NETBEANS
 En el segundo
podemos ver las
subidas de los
diferentes ficheros
 EJEMPLO SUBVERSION EN NETBEANS
 Si volvemos a Netbeans y con el
botón derecho sobre el proyecto
pulsamos sobre Subversión ->
Mostrar Cambios (Show
Changes), podemos revisar que
no se ha encontrado ningún
cambio entre el proyecto que
tenemos ahora mismo en local y
el que está en el repositorio. Lo
tenemos actualizado respecto al
repositorio
 También si tratamos hacer un
commit (Confirmar) de nuestro
proyecto, Subversión, podemos
ver que Subversión no nos
muestra nada que podamos
confirmar ya que no hemos
hecho ningún cambio
EJEMPLO SUBVERSION EN NETBEANS
 Probamos a añadir un nuevo cambio en nuestro proyecto. En este caso vamos a
cambiar la clase Calculo.java añadiendo un nuevo método que muestre un mensaje por
pantalla.
 Netbeans directamente nos va a mostrar en verde los cambios nuevos que hemos
añadido.
 En la estructura del proyecto, podemos ver también un icono azul avisándonos de que
tiene cambios el proyecto
EJEMPLO SUBVERSION EN NETBEANS
 También vamos a crear una nueva clase que va a ser copia de Calculo y que se va a
llamar CalculoNueva.
 Podemos ver que la clase modificada (Calculo) nos aparece ahora en color azul de que
esta modificada localmente y la nueva clase en Verde ya que es una nueva clase local
EJEMPLO SUBVERSION EN NETBEANS
 Si comprobamos ahora los cambios que se han realizado nos aparece ahora los
cambios que hemos ido realizando.

 Podemos ahora hacer un commit y confirmar estos cambios, pero es posible que no
queramos hacer commit de todo porque por ejemplo no hemos aún hecho todos los
cambios en Calculo y solo queremos subir la clase nueva (CalculoNueva). Podemos
pulsar sobre el botón derecho seleccionando la clase y no sobre el proyecto.
EJEMPLO SUBVERSION EN NETBEANS
EJEMPLO SUBVERSION EN NETBEANS
 Si comprobamos ahora la estructura del
proyecto, vemos que CalculoNueva ya se
encuentra en color “normal” y no en
estado verde.

 A continuación hacemos también commit

(confirmar) con la clase que hemos
modificado (Calculo). Podemos poner
como mensaje que se ha añadido un
nuevo método que hemos llamado
mensaje.
EJEMPLO SUBVERSION EN NETBEANS
 Si actualizamos ahora nuestro repositorio
podemos comprobar que tenemos ya 4
versiones del proyecto:
1. Carpeta del proyecto
2. Subida Inicial
3. Nueva clase copia de cálculo (aunque
en mi ejemplo pone Subida Inicial)
4. Se añade un nuevo método a cálculo
 Podemos pulsar en cualquier versión para
ver los cambios realizados en la misma y
tenemos más información sobre ella
EJEMPLO SUBVERSION EN NETBEANS
 Vamos a añadir otro nuevo método a nuestra clase Calculo, en este caso lo vamos a
llamar mensaje2 y también va a mostrar por pantalla un texto.
 Imagínate que ha pasado un tiempo o que no te acuerdas de los cambios que has
hecho. Para ello cuando le das a mostrar cambios (siguiente diapositiva) o a confirmar
puedes pulsar sobre el nombre del archivo en la ventana de subversión y te indica los
cambios de la copia local versus repositorio
EJEMPLO SUBVERSION EN NETBEANS
EJEMPLO SUBVERSION EN NETBEANS

 Pero claro, esto que estamos describiendo con un solo usuario tiene utilidad por
tener un respaldo de los cambios realizados. No obstante, un control de versiones
tiene más potencia o es más interesante su uso cuando tenemos varios usuarios
trabajando (o pueden trabajar) sobre el mismo proyecto.
 Para poder añadir nuevos usuarios pulsamos en el menú superior en Dashboard y
a continuación en Users. Estos usuarios deben haberse registrados, es decir, ser
usuarios de https://riouxsvn.com/
 En mi caso dispongo ya de otra cuenta por lo que para añadir ese usuario solo
tendría que indicar su nick.
 Existen muchas maneras de añadir al usuario a tu proyecto. En nuestro vamos a
añadir al usuario paquielena2.
 Para ello editamos el equipo de nuestro proyecto
EJEMPLO SUBVERSION EN NETBEANS

 Añadiremos un nuevo usuario

 Indicaremos el nick del usuario que queremos añadir

EJEMPLO SUBVERSION EN NETBEANS

 Una vez encontrado lo único que debemos hacer es seleccionarlo. Una vez
hecho le indicamos para qué proyectos (en nuestro solamente tenemos uno) y
qué permisos le otorgamos (se los damos todos para que pueda trabajar
plenamente en el proyecto). Pulsamos Add User
EJEMPLO SUBVERSION EN NETBEANS

 En nuestro proyecto ya se verían los dos usuarios (con el mismo nombre por
las circunstancias ya indicadas, pero lo usual es que fueran usuarios de
procedencia distinta).
EJEMPLO SUBVERSION EN NETBEANS

 Desde otra máquina y teniendo la

dirección del repositorio, nos
vamos a conectar al mismo con el
nuevo usuario para descargar
dicho proyecto y poder trabajar
con él.

 Para ello realizaré un checkout

del mismo.
EJEMPLO SUBVERSION EN NETBEANS

 Pulsaremos en Examinar(Browse…) para indicar el proyecto que queremos.

EJEMPLO SUBVERSION EN NETBEANS

 Tras seleccionar el proyecto, dejo el resto de parámetros tal y como están

para descargar la revisión del proyecto (versión) que se encuentra en la
cabecera (HEAD). Podría haber señalado alguna más antigua, pero se deja
así para descargar la versión más actual y pulsamos en Terminar.
 Me indica que se ha incorporado bien el proyecto y si deseo abrir el mismo, le
indico que sí y ya puedo ver dicho proyecto en el menú de proyectos
correspondiente.
EJEMPLO SUBVERSION EN NETBEANS

 Desde el segundo usuario hemos añadido cambios en Calculo y hemos

añadido una nueva clase CalculoNueva2
EJEMPLO SUBVERSION EN NETBEANS

 Si actualizo el repositorio (en la página de RiouxSVN con el

PrimerProyectoSubversion) podemos ver que no ha habido cambios en las
versiones que tenemos allí.
 Esto es debido a que el segundo usuario no ha realizado el commit
correspondiente.
 El segundo usuario realiza ahora el commit de todos los cambios, por lo que
subo una nueva revisión que tiene los cambios en Calculo y la nueva clase
CalculoNueva2.
EJEMPLO SUBVERSION EN NETBEANS

 Si, con el primer usuario, le doy ahora desde mi proyecto a Mostrar Cambios
estos cambios que se han realizado.
 OJO: En ocasiones no es tan inmediato que se actualice en el subversión los
cambios del repositorio.
 Se puede obligar a que haga la búsqueda de cambios pulsando en el botón
“mostrar archivos modificados remotamente” o “Mostrar archivos modificados
local y remotamente” (tercer y primer botón respectivamente de la captura de
pantalla)
EJEMPLO SUBVERSION EN NETBEANS

 Para que estos cambios que ha provocado el segundo usuario se confirmen

en el primer usuario será necesario hacer un update de estas clases que nos
han aparecido(desde el primer usuario).
 Para ello puedo pulsar de manera individual en cada clase o elegir todas las
que quiero actualizar (update) y pulsar botón derecho del ratón y dar sobre
actualizar (aparece también una carpeta src ya que el otro usuario ha
organizado las clases con una nueva estructura, es posible que no aparezca).
 Una vez pulsado en Actualizar, estos cambios se reflejan automáticamente en
nuestro proyecto.
 Posteriormente, cada vez que uno de los usuarios vaya realizando cambios
en el proyecto, debe ir confirmando cambio, para intentar que cada usuario
pueda trabajar con la versión que le interese o más actualizada.
GIT. Estados
GitHub. Crear una cuenta
GitHub. Crear una cuenta
GitHub. Crear una cuenta
GitHub. Crear una cuenta

Crear un repositorio.
Escribir el nombre,
público.
GitHub. Crear una cuenta

Incluye en el
repositorio README.
GitHub. Crear una cuenta
GitHub. Características

 Mecanismo de almacenamiento de los elementos que deba gestionar (ej.

archivos de texto, imágenes, documentación...).
 Posibilidad de realizar cambios sobre los elementos almacenados (ej.
modificaciones parciales, añadir, borrar, renombrar o mover elementos).
 Registro histórico de las acciones realizadas con cada elemento o conjunto de
elementos (normalmente pudiendo volver o extraer un estado anterior del
producto).
GitHub con Netbeans

 Crear un repositorio nuevo

GitHub con Netbeans
GitHub con Netbeans

 Clonamos el proyecto vacío en NetBeans (solo tiene el archivo Readme),

usando la dirección que encontramos en github:
GitHub con Netbeans
GitHub con Netbeans
GitHub con Netbeans

 Seleccionar la carpeta
dónde se almacenará el
proyecto NetBeans y el
nombre del proyecto
GitHub con Netbeans
GitHub con Netbeans

 Proyecto creado
GitHub con Netbeans

 El proyecto está copiado en el equipo y funcionando en GitHub

 Se trabaja en el proyecto de NetBeans

 Subimos los archivos a GitHub. Con la opción Add, después con Commit y…
GitHub con Netbeans
GitHub con Netbeans

 Finalizamos con la opción Push

GitHub con Netbeans
GitHub con Netbeans

Usuario y en contraseña ponemos token

generado previamente en GitHub,
desde:

Settings:

Developer settings:
GitHub con Netbeans

Personal access
tokens y Generate
new token

Indicamos en Note el uso,

elegimos lo que durará el
token, seleccionamos todas
las opciones y pulsamos
sobre el botón verde
Generate token
GitHub con Netbeans

Copiamos el token generado y lo copiaremos en

Netbeans (donde nos pedía el password)

Y seleccionaremos Save Password

para no tener que volver a ponerlo,
ya que no podemos volver a ver el
mismo token.
GitHub con Netbeans

Y comprobamos que ya está

subido el commit (en este caso el
commit lo realicé hace 4 días)
GitHub con Netbeans

 Cambios…
 Comprobar si se subieron correctamente a GitHub
 Modificar en Netbeans y comprobar los cambios en GitHub:
 Modificar
 Git>>Add
 Git>>Commit
 Modificar el mensaje del commit>>confirmar
 Git>>Remote>>Push>>Master
 Comprobar las modificaciones
 Modificar en GitHub y comprobar cambios en NetBeans
 Editar archivo en GitHub
 Describir el cambio
 En NetBeans: Pull
Comandos básicos de git
 git init inicializa un repositorio en un directorio concreto
 git add añade elementos de la copia de trabajo en el control de
versiones en el “staging área”
 git rm -cache elimina elementos del control de versiones
 git status muestra el estado actual de la rama en la copia de
trabajo
 git commit sube los cambios de la copia de trabajo bajo el control
de versiones en el repositorio local
 git log muestra la lista de versiones subidas en el repositorio local
 git clone copia un repositorio remoto, no es necesario inicializarlo
Comandos avanzados de git
 git branch crea nuevas ramas a partir de la rama en la que estamos o lista las ramas
 git checkout cambia la copia de trabajo en la rama o versión indicada
 git diff muestra los cambios que se han añadido en una versión
 git log muestra la lista de versiones para la rama activa
 git merge fusiona los cambios entre dos ramas
 git tag añade una etiqueta a una versión
 git show muestra información sobre la versión indicada
 git reset -hard revierte los cambios en la copia de trabajo
 git push sube los cambios del repositorio local a un repositorio remoto
 git pull baja los cambios de un repositorio remoto al repositorio local
 git remote añade un repositorio remoto o lista los repositorios remotos enlazados con el
repositorio local
 archivo .gitignore permite añadir una lista de archivos y directorios para excluir del sistema
de control de versiones