Eclipse - Commit y merge de cambios en el código de un proyecto

COMMIT y MERGE DE LOS CAMBIOS EN EL CÓDIGO DE UN PROYECTO

Lo primero de todo, a primera hora de la mañana de forma diaria, deberíamos hacer un update sobre la rama de desarrollo y refrescar el proyecto en el Spring Tool Suite (Eclipse), para trabajar con los fuentes lo más actualizados posibles, para evitar problemas futuros.

No os preocupéis si tenéis cambios en local que todavía no están subidos, la herramienta los respeta sin ningún problema.

Luego en la rama de desarrollo: antes de realizar  commit de código relacionado con cambios en el modelo de base de datos, como la creación o modificación de tablas,  hay que ejecutar obligatoriamente los scripts que  modifican el modelo de datos en todos los entornos de prueba

Porque dichos entornos tiran de la rama de desarrollo, y si hay algún cambio en el modelo reflejado en el código, si no está actualizado en la BBDD da error.

Muy importante: Al hacer el commit en la rama de desarrollo (antes hay que hacer un update para que tengamos el repositorio actualizado), hay que poner en la descripción de la revisión; #Código de modificación – título de la modificación. EL #Código de modificación, es para que en la herramienta colaborativa se vincule la revisión subida a la tarea asociada y además cuando tengamos que hacer un merge de una tarea a la rama del trunk, saber localizar fácilmente que revisión / revisiones hay que seleccionar.

Por cada fichero que se vaya a realizar un commit, pulsar antes sobre el propio fichero con el botón derecho, y pulsar en la opción “Compare with base”, donde nos muestra las diferencias entre nuestro fichero y el ultimo que esta subido al subversión. Y ahí debe estar todos nuestros cambios y asegurarnos que no haya nada de código para realizar pruebas, etc.. Todo esto también hay que hacerlo al hacer un merge a la rama del trunk, en esta fase, ha ocurrido varias veces que se fusione código de otros compañeros que no debe subir, por lo cual hay que tener especial cuidado a la hora de revisar los cambios que se suben.

Los commit en la rama de desarrollo, solo se deben hacer cuando la tarea está terminada, o está en una versión estable y alguien o nosotros mismos la queremos probar en un entorno diferente al local.

En la lista de ficheros para hacer el commit; nos saldrán siempre o casi siempre los ficheros config.properties y weblogic.xml. Estos ficheros nunca hay que hacer commit, ni en la rama de desarrollo ni en la del trunk, estos se editan en nuestro local para que nos funcione nuestro servidor local de weblogic.       

Para hacer la fusión / merge al trunk del código fuente, hay que hacer lo siguiente;

·         posicionarse en la carpeta trunk, botón derecho TortoiseSVN / update. Para tener actualizado el repositorio y que de los menos conflictos posibles

·         En la carpeta trunk, boton derecho TortoiseSVN / Check for modifications. Para comprobar que no tengamos ningún fichero con cambios previamente, aquí solo deben de aparecer siempre como mucho los ficheros (config.properties y weblogic.xml)

·         En la carpeta trunk,  botón derecho TortoiseSVN / merge. En el campo URL to merge from, hay que seleccionar la carpeta desarrollo, y luego hay que pulsar en el botón show log, para seleccionar las revisiones que tenemos que mezclar (puede que no aparezcan todas, hay que pulsar en el botón show all, que esta abajo a la izquierda). Se seleccionan si hay varias, pinchando en la primera, y con el control pulsado seleccionar la última, y le damos al ok. Y luego next para que empiece a hacer el merge. Si hay algún conflicto de código la herramienta nos avisa y hay que resolverlo en ese mismo momento.

·         En la carpeta trunk,  botón derecho TortoiseSVN / commit. Pero antes de pulsar OK, hay pulsar por cada fichero que subamos, con el botón derecho sobre la opción “Compare with base”, y aquí comprobar que solo suben nuestros cambios y se han mezclado correctamente (mucho cuidado, algunas veces nos ha pasado que no lo ha hecho bien la herramienta, aunque no haya dado conflictos previamente).

·         Ahora vamos a buscar algunos posibles conflictos que no se han resuelto correctamente ó que el cliente del subversión no nos haya avisado del conflicto. Este caso que se ha producido en alguna ocasión, donde es más problemático en los jsp´s. Porque en los java, da error de compilación y nos enteraríamos al construir el war (con mvn clean package). Por este motivo, para que podamos revisarlo, debemos hacer el siguiente procedimiento;

o   abrir herramienta notepad++

o   en buscar / buscar en archivos, escribimos los siguiente:

§  <<<<<<< .mine

§  D:\NOMBRE_PROYECTO\trunk\fuentes\src\main\webapp\WEB-INF\views\app (donde vosotros tengáis los jsp´s del proyecto)

§  *.jsp, para que busque solo en los jsp´s

o   Si aparece el texto en algún jsp´s hay que corregirlo, si el error es nuestro, y si es de otro compañero, pues le avisamos.

·         Ahora hay que asegurarse que compila el proyecto, para ello se puede hacer la siguiente operativa;

o   Ir al explorador de Windows a la carpeta “D:\NOMBRE_PROYECTO\trunk\fuentes”, y escribir en la barra de dirección, la palabra cmd. Con esto, nos abre una consola de MS-Dos

o   Escribir  “mvn clean package -Dmaven.test.skip=true” y pulsar enter. Con esto intenta construir el proyecto, y al final si da resultado success, es que compila todo y podemos continuar con el siguiente paso.

·         A la hora de subir los ficheros, hay que desmarcar siempre los ficheros (config.properties y weblogic.xml), porque estos ficheros nunca deben de subir, puesto que tienen cambios para que nos funcione nuestro servidor de local.

·         Cuando tengamos todos los ficheros revisados y sabemos que compila el proyecto, hay que poner como descripción de la revisión lo siguiente:

·         en su lugar hay que pinchar en el botón “Recent messages” y pinchar en la primera descripción. Dicha descripción es la que pone subversión por defecto, cuando se realiza el merge. Y ahí se detalla mucho más la descripción; estableciendo las revisiones que estamos mergeando, junto con el código de tarea y su descripción. Por favor, revisad que la descripción es la correcta.

·         Por último, pulsar el botón ok, para que realice el commit definitivamente.

También puede ocurrir el siguiente escenario; hay que añadir un campo obligatorio a una tabla ya existente, el desarrollador para hacer pruebas tiene que crear el campo que permita nulos, para que no de ningún problema a ningún otro desarrollador. Y cuando tenga el código terminado y realice un commit, ya se podría cambiar en BBDD el campo a obligatorio. Porque el resto de desarrolladores con hacer un update sobre el subversión ya tendría los nuevos cambios en el código.