La presente guía tiene por objeto explicar la metodología y configuración, a emplear por la Cátedra, para la utilización del sistema de control de versiones GIT. De manera muy sintética y simplista se puede definir un sistema de control de versiones como aquel software que permite identificar de manera unívoca el conjunto de ficheros de código, y sus correspondientes modificaciones, que componen un determinado programa. Todo sistema de control de versiones dispone de un servidor, en donde se ubica el código, y un cliente, siendo este último la herramienta utilizada por el desarrollador para acceder a las funcionalidades brindadas por el sistema. Existen en la actualidad una gran cantidad de sistemas con diferentes metodologías de trabajo y métodos de identificación de cambios, entre los cuales se pueden citar los open source SVN, GIT, Mercurial o los comerciales IBM Rational Synergy o Microsfot Source Safe. Sin embargo el objetivo de todos ellos es el mismo, y se puede resumir mediante el siguiente ejemplo:
En un grupo de desarrollo conformado por dos personas, se están realizando cambios en un fragmento de código que se encuentra en el fichero funcion.c, el cual se ubica en un servidor compartido.
Inicialmente el desarrollador A abre el fichero, generando una copia local, y comienza a realizar las modificaciones bajo su responsabilidad, a su vez el desarrollador B también abre el fichero generando su propia copia local y comienza a trabajar realizando las modificaciones que le fueron asignadas.
Como se puede apreciar existen dos copias de un mismo fichero original en ubicaciones diferentes, cada una de ellas con distintos cambios según el trabajo que se esté realizando.
En este escenario el desarrollador A puede guardar el fichero en el servidor, preservando los cambios realizados sin inconvenientes, sin embargo si el desarrollador B guardara sus cambios en el servidor, estaría sobrescribiendo lo realizado por A y por ende los cambios de este último se perderían.
En este punto es donde entra en acción el sistema de control de versiones; al momento en que B intenta guardar los cambios realizados, el sistema le indicará que existe una nueva versión (posterior a la original que copio localmente) y que debe tomar una decisión:
Como se mencionó anteriormente, dependiendo del sistema que se utilice las opciones indicadas en el párrafo precedente pueden realizarse en forma automática, asistida o totalmente manual.
El sistema de control de versiones a utilizar por la Cátedra, es el GIT. Si bien este sistema dispone de una gran cantidad de funcionalidades, diseñadas especialmente para el desarrollo de código en forma cooperativa, solo se utilizará un conjunto muy reducido de las funcionalidades disponibles. Esto se debe a que la mayoría de los trabajos prácticos se debe realizar en forma individual, por lo tanto el sistema de control de versiones se está utilizando tan solo como un servidor centralizado, para alojar el código y poder compartirlo unicamente entre el docente y el alumno.
Las funcionalidades a utilizar por la herramienta recomendada por la Cátedra y se tratará en el apartado Herramientas
Antes de proceder a la configuración y operación del cliente de control de versiones, en nuestro escenario, se debe generar la estructura de carpetas a utilizar para la entrega de trabajos prácticos. Esta estructura es de caracter obligatorio y debe ser respetada para optimizar la interacción entre el docente y el alumno. En primera instancia se debe proceder a crear en la carpeta /home/su_usuario, del SO recomendado por la Cátedra, la siguiente estructura teniendo en cuenta que en todos los casos se deben utilizar minúsculas para los nombres
/home/su_usuario/repolocal/r505x-td3-pellido-nombre/01_cuat/tp_01_01 /tp_01_02 ... /tp_01_m /02_cuat/tp_02_01 /tp_02_02 ... /tp_02_n
Cada carpeta correspondiente mencionada anteriormente, debe disponer de la siguiente estructura interna
/tp_01_xx/bin /doc /inc /lib /src /sup
El contenido a incluir en cada carpeta se detalla a continuación
Adicionalmente la carpeta raíz de cada trabajo práctico (ej.: tp_01_xx) debe disponer de un fichero tipo script o makefile con todas la sentencias necesarias para la generación del binario final. En la carpeta raíz de todos los trabajos prácticos /home/su_usuario/repolocal/r505x-td3-apellido-nombre/ se debe incluir un fichero de texto con el resumen del estado de cada trabajo práctico, con el siguiente formato:
*********************************************************************************************************************************** * Planilla de avance de Trabajos Prácticos del Alumno * * * * Instrucciones: Colocar en el directorio raíz del repositorio local, para que sea de fácil acceso. Completar los datos (Usuario * * SGE, Legajo) * Indicar el estado del ejercicio: Funciona: SI / NO * * Agregar comentarios en caso que consideren oportuno, (por ejemplo si se compila con un makefile). * *********************************************************************************************************************************** ->Usuario SIGA: ->Legajo: ******************************************** * TP 1 * ******************************************** TP01.01: Funciona -> SI/NO Comentarios: TP01.02: Funciona -> SI/NO Comentarios: ... TP01.09: Funciona -> SI/NO Comentarios: ... TP01.14: Funciona -> SI/NO Comentarios: TP01.15: Funciona -> SI/NO Comentarios:(Entrega Obligatoria) ******************************************** * TP Integrador * ******************************************** Servidor: Funciona -> SI/NO Comentarios: Cliente: Funciona -> SI/NO Comentarios: Driver: Funciona -> SI/NO Comentarios:
Independientemente de lo expresado en el párrafo anterior es de suma importancia que cada vez que se realice una actualización de los ficheros en el repositorio se indique el estado operativo (funciona/no funciona), detallando el problema actual y la resolución según corresponda. Esta metodología le permitirá al alumno analizar y recordar los diferentes inconvenientes con los que se topó al momento de realizar el ejercicio y como fueron resueltos, utilizando la herramienta de visualización del histórico de cada fichero/proyecto.
Al igual que los sistemas de control de versiones, existen una gran cantidad de herramientas (clientes) que permiten operar sobre el GIT. En la Cátedra se utilizará por defecto el Cliente GIT por consola, pero a fin de proveer mayor flexibilidad a los alumnos, se presenta la citan algunas alternaticas:
El uso extensivo de GIT y sus respectivos clientes está fuera del alcance de esta guía, pero puede ser consultado en los manuales de los respectivos sistemas/herramientas.
De todo el conjunto de operaciones disponibles en GIT, vale la pena detallar las siguientes:
Independientemente de la herramienta que se utilice los pasos para la configuración del repositorio local son los siguientes:
En GitLab
usuario SInAP: mail: recursante: Si/No experiencia ASM: Alta/Media/Baja experiencia C: Alta/Media/Baja PC con Linux: Si/No Año Cursada Informatica II: YYYY Año Cursada Tecnicas Digitales II: YYYY
En su PC
git clone https://gitlab.frba.utn.edu.ar/td3/repo/r505x-td3-apellido-nombre/r505x-td3-apellido-nombre
# Ignore all * # Unignore all with extensions *.c *.h *.txt y con Makefile !*.c !*.h !Makefile !*.txt !*.cpp !*.hpp !*README* !*make* !*suite* !*.asm !*.s !*.inc !*.ld # Unignore all dirs !*/
./bin/* ./inc/*.o ./inc/*.bin ./inc/*.elf ./lib/*.o ./lib/*.bin ./lib/*.elf ./lib/*.o ./lib/*.bin ./lib/*.elf ./src/*.o ./src/*.bin ./src/*.elf ./sup/*.o ./sup/*.bin ./sup/*.elf ./doc/*.o ./doc/*.bin ./doc/*.elf ./doc/*.html
git add fichero.ext
git commit -m "Mensaje indicando los cambios realizados"
git push origin master
— ChristiaN 2023/03/25 18:00
Mediante un navegador WEB, ingresar la dirección https://gitlab.frba.utn.edu.ar/, y verificar que puede ingresar a su carpeta. De no ser posible, verifique que el usuario y clave sean correctos, ingresando al SIGA. En caso que el navegador WEB le permita ingresar, verifique que la dirección configurada en el cliente sea correcta. Si luego de verificar todo lo indicado aún no puede ingresar, consulte al docente a cargo.