En este repositorio se encuentran todos los laboratorios utilizados en la asignatura Tecnologías de Desarrollo de Software IDE, materia electiva de la UTN FRRo.

Nota: La versión gratuita de GitKraken posee todo lo necesario a utilizar, pero existe para el que le guste la herramienta una versión premium con otras features como: Tener Boards estilo trello y calendarios, entre otras cosas. Se puede conseguir gratuitamente como alumno universitario, teniendo un correo @frro dado de alta en la universidad (Secretaría de Asuntos Universitarios).

La parte complicada del proceso consiste en seleccionar que componentes de VS instalar, seleccionar: Recordar destilar la opción de Azure Data Lake ya que esa herramienta no sera de utilidad en este curso

Documentacion oficial

1. Buscar Visual Studio Installer en la barra de búsqueda de aplicaciones sistema operativo utilizado
2. En la versión de VS utilizada, clickear en modificar
3. Si se desea instalar alguna carga de trabajo de las mencionadas anteriormente clickear en la tab Cargas de Trabajo las correspondientes
4. [Recomendado] Si, en cambio se prefiere buscar por característica individual, ir a la tab Componentes Individuales (arriba al medio) y seleccionar las correspondientes. Ej. NET 5.0 Runtime

La forma de trabajo que se va a utilizar este año consiste en los siguientes pasos:

Esta se encuentra inspirada por la forma de trabajo que fue implementada por otros adscriptos en otra materia electiva de la UTN llamada "Soporte a la Gestión de Datos con Programación Visual"

1. Forkear el repositorio oficial de practica seleccionando su usuario de GitHub

2. Clonar el repo forkeado

2.1. Primero copiar al portapapeles la dirección url de este

2.2. Luego acceder a GitKraken y copiar la url anterior en el formulario de clonacion

2.2b. En Visual Studio ir a Git/Clonar Repositorio y proceder de la misma forma

3. Abrir la carpeta con Visual Studio desde el menú contextual (click derecho)

4. Cambiar la ubicación predeterminada de los proyectos en Visual Studio

• Ingresar "ubic" en la Barra de Búsqueda

• Cambiar la ubicación predeterminada a la dirección donde esta el repositorio clonado previamente

5. Ir a al menú desplegable en Archivo/Nuevo/Proyecto

Al seleccionar el tipo de proyecto revisar que en el titulo este no contenga (Net Framework), ya que estos no permiten seleccionar a NET 5 o NET Core como motor de ejecución

6. Llenar el nombre del laboratorio en el campo Nombre del Proyecto, el campo Nombre de la Solución se ingresara automáticamente con el mismo valor.

• Luego clickear en el selector de archivos correspondiente al campo Ubicación

• Ingresar la subcarpeta correspondiente a la unidad y el laboratorio en el que se quiera trabajar

7. Seleccionar NET 5 en el menú de opciones. NOTA: Tener instalado el runtime

8. Notar como los nuevos archivos se incluyen en el Staging Area (sección donde están los archivos marcados) al clickear en stage all changes

8.b. En VS ir a Ver/Cambios de GIT

9. [Recomendado/Opcional] Crear una nueva branch con el siguiente formato: UnidadNLabZ con N y Z igual al numero de unidad y de laboratorio respectivamente

9.b. En VS ir a Git/Nueva Rama

Es posible commitear los cambios directamente en main, sin embargo esta forma es utilizada si se esta trabajando en solitario, lo cual es bastante poco común

10. [Este paso se repite] Commitear los cambios escribiendo un mensaje que represente lo realizado, como por ejemplo la inicializacion del proyecto con Visual Studio

10.b. En VS ir a Ver/Cambios de GIT (una vez desplegado se mantiene a la izquierda como opción)

11. Observar como los commits en la branch "main" están tanto en local (símbolo notebook) como en remoto (icono del usuario de GitHub). Para cambiar esto pushear los cambios a remoto con el siguiente botón

11.b. No hay equivalente en la UI de VS para GIT

12. [Recomendado/Opcional] Una vez que se termino de trabajar con el laboratorio como se observa en la siguiente imagen:

mergear la branch actual del ejercicio con la branch main del repositorio local, arrastrando la primera hacia la segunda

12.b. En VS ir a Ver/Repositorio de GIT y hacer click derecho en la rama del ejercicio para que aparezca el menú desplegable, allí seleccionar la opción resaltada

13. Agregar el repositorio de la asignatura a remote, de manera de que pueda tener los ultimas actualizaciones a los ejercicios y sea capaz de realizar pull requests a este

13.b. En VS esto ya esta presente por default

14. Pullear los últimos cambios presentes en la branch Main del repositorio remoto de la catedra y mergear esta con la branch Main del repositorio forkeado local.

14.b. En VS ir a Ver/Repositorio de GIT y hacer click derecho en la rama main remota para que aparezca el menú desplegable, allí seleccionar la opción resaltada

Muchas gracias al alumno Bruno Cocitto por sus significativos aportes y solicitudes de cambios

Aquel que desee soliticitar agregar o cambiar algo, tenga dudas respecto a algun ejercicio o simplemente quiera probar como hacer una Pull Request puede hacer sus cambios en su fork y luego realizar una pr al repo de la catedra

15. De forma inversa a como se hace merge en GitKraken arrastrar la branch donde se esta trabajando hacia Remote/NetUtnRosario/Main y seleccionar en el menu contextual: Push and start a pull request to NetUtnRosario/main

15.b. En VS se debe pushear los cambios realizados en la branch donde se este trabajando y luego es necesario ir al sitio del repositorio en GitHub. Ya que el complemento de GIT de VS no puede manejar estas acciones que no son propias de Git en si, sino de la plataforma GitHub

La carpeta real de archivos físicos se denomina Working Directory (también denominado Workspace). Al clonar de Internet un repositorio (ejemplo de GitHub u otra plataforma) o realizar la tarea manual de descargarlo, descomprimirlo e inicializarlo (que es equivalente) estamos generando un Repositorio Local que representa de forma logica nuestro Working Directory. Si escribimos nuevo código, git trackea (nota) las diferencias en los archivos con respecto al último cambio almacenado en local. Para que nuestros cambios físicos (crear, modificar o eliminar algun archivo) se almacenen efectivamente en el repositorio local, se debe realizar un commit (que es un contenedor con los cambios que realizamos, junto a un ID, el autor de los cambios y una fecha). El repositorio local se maneja 100% con commits.

Cuando hay cambios en algunos archivos, pero estos aún no han sido incluidos en un commit, estos estan en el Staging Area (que representa a todos los archivos que git detectó una diferencia con respecto al último commit que posee en nuestro repositorio local). Con lo que está allí podemos realizar un commit para que sea agregado oficialmente a nuestro repo local o remover estos cambios de este area y dejar los archivos como estaban antes.

El repositorio que se encuentra almacenado en GitHub (u otra plataforma) para todos los miembros del equipo se denomina Repositorio Remoto, referenciado como Origin. Git también rastrea la diferencia entre nuestro repositorio local y el remoto. Es posible traer (pull) al repositorio local los commits que hayan subido al remoto otros compañeros, así como subir (push) commits en el sentido inverso al anterior y mantenernos sincronizados.

Almacenamiento virtual de tu proyecto. Permite guardar versiones del código a las que es posible acceder cuando se necesite.

Gestión de los cambios que se le realizan al código, puede ser manual (utilizando prefijos vN.M y guardando los archivos iterativamente en el equipo o en Google Drive por ejemplo) o utilizando alguna herramienta que lo facilite (Git en este caso).

Sistema de control de versiones distribuido, esto significa que sirve para gestionar los cambios en el código de forma local y en un repositorio remoto que es ejecutado en un servidor central. Es gratis y de codigo abierto. Web para descargar: https://git-scm.com/.

Generar un repositorio bifurcado que está asociado tanto al repositorio original como al propio. Permite probar cambios que no son deseables de hacer en el original y a la vez mantenerse al día con los cambios que puedan surgir allí.

Equivalente a descargar los binarios del repositorio. Se debe copiar la dirección URI del repositorio que se quiere clonar. Al usar esta herramienta se optimiza la descarga de código y a la vez se reduce el numero de pasos requeridos típicamente. Un ejemplo sería: encontrar un repositorio interesante en GitHub y para tenerlo localmente en el equipo, en vez de descargarlo manualmente, se clona a través de su dirección URI y se genera el repositorio local directamente.

Área donde se congelan los cambios realizados en los archivos que se agregaron a está. Son cambios locales que aún no han sido incluidos en un commit y por lo tanto no podemos enviarlos aún a nuestro repositorio remoto.

Tarea que realiza Git, que consiste en rastrear los cambios nuevos que se realizaron al escribir nuevo código con respecto a los archivos locales y a su vez que con respecto al repositorio remoto. El tracking será de archivos nuevos, modificaciones o eliminaciones.

Se puede crear un archivo llamado ".gitignore" e incluir alli archivos o carpetas a forma de "blacklist", es decir, lo que esté ahí dentro será ignorado por Git y no almacenará información de esos archivos (no habrá tracking).

Cuando se cuenta con un archivo nuevo o algun tipo de cambio que no esta contenido en el Staging Area, es posible agregarlo a esta ultima mediante git add nombreArchivo. Si se quiere agregar todos los cambios, se utiliza git add .. Si se requiere agregar todos los cambios excepto archivos nuevos a la staging area, se usa git add -u.

Cuando se necesite realizar cambios es recomendable que esto se realize en una “sección propia” o rama bifurcada desde algún punto de partida (commit específico) a donde subir los cambios, de modo de que estos ser visibles para los demás en el repositorio remoto. Estos cambios no se ven reflejados en Master/Main del repositorio hasta que se realice un merge de la Branch hacia Main. (Ejemplo: codificar una feature llamada “Login”, se crea una rama “login_user” y se suben/pushean los cambios alli. Cuando se termina de trabajar con la feature, se hace un merge de la Branch login_user a Master y de esta forma todos nuestros cambios serán enviados al Main del proyecto). Es posible cambiar de rama con el comando git checkout nombreBranch.

Información que contiene los nuevos cambios que se realizaron en el código, quien lo realizó, un ID y la fecha. Al realizar commits, se les puede subir al repositorio remoto compartido, mediante git push origin -u nombreBranch. También es posible traer los Commits que realizaron otros miembros del equipo y subieron al remoto, mediante git pull. Tener en cuenta que Push y Pull funcionan por Branch, por lo que si se quiere es traer o enviar Commits a otras Branches, se debe cambiar de Branch haciendo git checkout nombreBranch.

Descargar los cambios presentes en repositorio [remote] a local. Todos los commit subidos al remoto por los demás integrantes del grupo serán descargados en el repositorio local para mantenerlo sincronizado. Solo trae los cambios que detecta en la rama actual.

Subir los cambios realizados en local al repositorio remote. Solo sube todos los cambios que se encuentren dentro de Commits. Solo sube al remoto los que detecte en la rama actual.

Agregar los cambios presentes en una branch determinada a otra branch. Ejemplo: 3 commits en una branch llamada "register_user" se desea que estén en master porque se finalizo la tarea, entonces se "mergean" los commits de register_user en Master.

Se podría llamar “Merge Request” que es más exacto (En GitLab, la competencia de GitHub, posee ese nombre). Es una solicitud que realiza un integrante del equipo hacia los demás, pidiendo agregar los cambios realizados en una determinada branch a otra. Esto se gestiona por determinados usuarios revisores que pueden optar por aprobar lo realizado, hacer comentarios para requerir cambios o preguntas para aclarar porqué se procedió de determinada manera. Los comentarios se realizan online en Github y pueden ser comentarios generales, por archivo o por linea. Una vez que los reviewers aprueban los cambios, se acepta la Pull Request y los commits nuevos se mergean (por default) a la branch correspondiente.

Refiere al repositorio central que es ejecutado en un servidor con determinado nivel acceso para cada uno de los desarrolladores. Es el repositorio que almacena GitHub en sus servidores y al cual se le realiza push para enviar commits y Pull para traer commits de los demás integrantes del equipo.

Es el repositorio local manejado por cada desarrollador en sus equipos personales. Se comunica con el repositorio remoto alojado en GitHub mediante un área intermediaria a la cual denominaremos Staging Area, en donde se envían commits con Push y reciben de los demas integrantes del equipo que hayan subido sus commits con Pull.

Branch principal del repositorio, en esta generalmente se cuenta con la versión más estable del código. Una forma recomendada de trabajar es hacer una branch por cada nuevo requerimiento o caso de uso que se este trabajando y subir los commits allí, para una vez terminado pasarlos a "Master" (mediante un merge directo o una Pull Request en donde otros contribuidores deben aprobar los cambios antes). Nota: desde 2020 en Git se reemplazó la branch Master por “Main”. Solamente los repositorios creados posteriormente a 2020 poseen este cambio.

Suele tomarse como sinónimo de repositorio local, lo cual es incorrecto. El Working Directory representa los archivos físicos reales en del equipo, mientras que el repositorio local es una representación virtual del mismo. Cuando haya cambios nuevos locales mientras se escribe nuevo código, Git trackea estos cambios comparando el Working Directory con el repositorio local.

Historial de commits. Cada repositorio tiene uno. Muestra el historial de los commits con autores, cambios y fechas. Todos los cambios que se hagan en el repositorio son guardados automáticamente en el log. Puede accederse a él mediante git log o git log --oneline para una versión simpliicada.

Ver el Historial de commits del repositorio (Commits Log) como un árbol con sus ramificaciones (Branches). GitKraken presenta un Tree en la vista principal del repositorio.

Posición en la que se encontra actualmente en el Commit Tree. Por default siempre que se haga pull se estara viendo hasta el último de los commits, pero podemos "volver atrás" versiones del código desplazando el "HEAD" hacia otro punto de la historia (ejemplo: para ver como era el codigo hace una semana (se hicieron 5 commits), entonces se hace checkout a 5 commits atrás. En esa versión antigua del código no se cuenta con los cambios nuevos). Mover el HEAD no borra ni crea commits nuevos, por si mismo no es una operación peligrosa en absoluto.

Ver el estado general del repositorio local en la branch actual, con respecto a remoto. Muestra en que branch se encuentra, cuantos commits hay, cuantos cambios se presentan en la "Staging Area", etc... GitKraken ofrece esta información de forma visual en la vista principal del repositorio, pero por consola se debería escribir git status.

Para una explicación más completa de muchos de estos conceptos y como realizar varios de los casos de uso principales con Git y haciendo uso de Gitkraken, consultar: https://elc.github.io/posts/git-guide-with-visual-interface/es/ de Ezequiel Castaño, alumno avanzando de sistemas UTN FRRo https://github.com/ELC.

Otra guía sencilla (está tanto en español como en inglés) sobre Git pero haciendo uso de la Consola, consultar: https://rogerdudler.github.io/git-guide/index.es.html del usuario de GitHub https://github.com/rogerdudler/.

Si se quiere deshacer cambios locales que aún no se han enviado al remoto, es posible realizar un "reset" de nuestros cambios. El reset puede revertir uno o más commmits locales. En Gitkraken se hace un reset tocando el ícono de la papelera al lado de nuestros cambios. Hay 3 tipos de reset. El git reset --soft que solamente mueve "HEAD" hacia atrás sin borrar los cambios, es solo para ver nuestro codigo en una version anterior antes de los cambios; el git reset --mixed (el default) que borrará la cantidad de commits que le indiquemos, pero los cambios no se pierden sino que se vuelven al "Staging Area" y se dejará hacer nuevos commits; y el git reset --hard que es peligroso pues borra directamente la cantidad de commits solicitados y estos se "pierden para siempre".

Si hay cambios sin commitear y se quiere cambiar de branch, es posible "guardarlos" temporalmente en un "vault" llamado Stash. Más adelante si son necesarios nuevamente en la misma branch u otra, se realiza un Stash Pop que recupera el código y lo coloca devuelta en Staging Area.

Traer los cambios del repositorio remoto al local, pero sin reemplazar los archivos físicos. Esto es para visualizar los cambios pero sin reemplazarlos aún (a diferencia de Pull), pues a lo mejor se quiere hacer otra tarea antes de reemplazarlos. Podría decirse que, en el fondo, un Pull es un Fetch + un Merge a nuestros archivos locales.

Un rebase modifica la historia de commits del repositorio, por lo tanto es peligroso. Tal vez se necesite por ejemplo cuando se crean commits incorrectos y se quiere cambiarlos, pero estos ya estan subidos al remoto con push. Con rebase se puede cambiar el nombre de commits en remoto, unificarlos diferentes en uno o borrarlos, entre otras cosas. Estando en la branch en la que se desea modificar esto (se recomienda antes crear otra branch desde el ultimo commit para tener una "copia de seguridad") se debe escribir git rebase -i HEAD~n, donde n se debe reemplazar por la cantidad de commits que se van a ver afectados por el rebase, y la -i indica que será un rebase interactivo (da instrucciones de que se puede hacer con cada commit, sea unificar, renombrar, borrar, etc... por lo tanto es peligroso. Podemos necesitarlo por ejemplo cuando creamos commits incorrectos y queremos cambiarlos, pero estos ya los subimos al remoto con push y nos arrepentimos. Con rebase se puede cambiar el nombre de commits en remoto, unificarlos diferentes en uno o borrarlos, entre otras cosas. Estando en la branch en la que queremos modificar (se recomienda antes crear otra branch desde el ultimo commit para tener una "copia de seguridad") se debe escribir git rebase -i HEAD~n, donde n se debe reemplazar por la cantidad de commits que se van a ver afectados por el rebase, y la -i nos indica que será un rebase interactivo (te da instrucciones de que se puede hacer con cada commit, sea unificar, renombrar, borrar, etc..