LABORATORIO 1- INTRODUCCIÓN GIT

ESCUELA COLOMBIANA DE INGENIERÍA - CICLOS DE VIDA DE DESARROLLO DE SOFTWARE

INTEGRANTES

ANDERSSON DAVID SÁNCHEZ MÉNDEZ

CRISTIAN SANTIAGO PEDRAZA RODRÍGUEZ

RESPUESTAS

PARTE I (Trabajo Individual).

1. Crea un repositorio localmente.

   

2. Agrega un archivo de ejemplo al repositorio, el README.md puede ser una gran opción.

   

3. Averigua para qué sirve y como se usan estos comandos git add y git commit -m “mensaje”

   git add = Mueve los cambios del directorio de trabajo al área del entorno de ensayo.

   git commit -m "mensaje" = captura una instantánea de los cambios preparados en ese momento del proyecto.

4. Abre una cuenta de github, si ya la tienes, enlazala con el correo institucional.

5. Crea un repositorio en blanco (vacío) e GitHub.

6. Configura el repositorio local con el repositorio remoto.

   Como subir un proyecto local a github.

   

7. Sube los cambios, teniendo en cuenta lo que averiguaste en el punto 3 Utiliza los siguientes comando en el directorio donde tienes tu proyecto, en este orden:

     git add .

   

     git commit -m "mensaje, lo que hiciste con el archivo"

   

    git config user.name "Nombre del usuario"

   

     git push "url repositorio"

   

8. Configura el correo en git local de manera correcta Configurar correo electrónico en GitHub

   

9. Vuelve a subir los cambios y observa que todo esté bien en el repositorio remoto (en GitHub).

   

PARTE II (Trabajo en parejas)

1. Se escogen los roles para trabajar en equipo, una persona debe escoger ser "Owner" o Propietario del repositorio y la otra "Collaborator" o Colaborador en el repositorio.

Owner = Cristian Pedraza

Collaborator = Andersson Sánchez

2. El owner agrega al colaborador con permisos de escritura en el repositorio que creó en la parte 1

   Invitar colaboradores a un repositorio personal

   Cristian me agrega como colaborador al repositorio que él creó.

3. El owner le comparte la url via Teams al colaborador

   

4. El colaborador acepta la invitación al repositorio.

Ahora ya tengo acceso al repositorio de Cristian

Hago git clone para bajar el repositorio central de Cristian de manera local en el computador.

5. Owner y Colaborador editan el archivo README.md al mismo tiempo e intentan subir los cambios al mismo tiempo. 6. ¿Que sucedió?

7. La persona que perdió la competencia de subir los cambios, tiene que resolver los conflictos, cúando haces pull de los cambios, los archivos tienen los símbolos <<< === y >>> (son normales en la resolución de conflictos), estos conflictos debes resolverlos manualmente. Como resolver Conflictos GitHub

Se resolvieron los conflictos dándole en resolve merge 8. Volver a repetir un cambio sobre el README.md ambas personas al tiempo para volver a tener conflictos.

Ahora yo hago push y luego mi compañero el pull para ver el error que sucede para solucionarlo en IntellijIDEA

9. Resuelvan el conflicto con IntelliJ si es posible, Resolver conflictos en IntelliJ

De esta forma ya sabes resolver conflictos directamente sobre los archivos y usando un IDE como IntelliJ, esto te será muy útil en los futuros trabajos en equipo con Git.

PARTE III (Trabajo de a parejas)

1. ¿Hay una mejor forma de trabajar con git para no tener conflictos?

Si, esa forma consiste en no trabajar todo sobre la main, sino crear una rama nueva, y sobre esa hacer cambios, luego cuando esté seguro que el proyecto está bien, entonces se hace el PR, para subir y dejar todo en la rama principal (main); usando git flow.

2. ¿Qué es y como funciona el Pull Request?

Permite a tu equipo solicitar la revisión y aprobación de sus cambios antes de fusionarlos en la rama principal (main).

3. Creen una rama cada uno y suban sus cambios

4. Tanto owner como colaborador hacen un cambio en el README.md y hacen un Pull Request (PR) a la rama main/master

 [Pull Request - GitHub](https://docs.github.com/es/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)

(Recomendación : deben trabajar en equipo y distribuirse de mejor manera quien va a modificar qué, para evitar modificar los mismos archivos al mismo tiempo, si no se editan los mismos archivos la resolución de conflictos es automática)

5. Teniendo en cuenta la recomendación, mezclen los cambios a la rama main a través de PR con el check/review/approval del otro compañero (Cuando se hace merge se deberían borrar las ramas en github)

Como Borrar Ramas después de un Pull Request

Se dirigen a la configuración de su repositorio:

Y en general

Se dirigen al final en el área del pull requests y seleccionan “Automatically delete head branches”

Aprobación Pull Request

Nos dirigimos (todavía en configuraciones) a Branches, en esta visualizarán donde daremos protección de nuestras ramas, seleccionamos Add rule

Aquí damos el nombre de nuestra rama (Verificar el nombre tal cual lo tenemos en nuestro repositorio) y seleccionamos la primera opción como se muestra, así estamos requiriendo que cuando se haga ese pull request en nuestra rama se necesita aprobación de otro compañero

Vamos al final y damos clic en Create

Y así protegimos nuestra rama principal, esto se vuelve muy relevante cuando trabajamos en parejas o en equipos, deberían tener un mensaje final que se vea así

CASO PARA VERIFICAR QUE TODO SALIÓ BIEN AL TENER QUE APROBAR EL PULL REQUEST PARA DESPUÉS HACER EL MERGE DE main y master.

Y ASÍ QUEDA SOLO la main como rama en el repositorio.

ENTREGA

• En un README.md colocar lo siguiente:
• Una sección llamada “INTEGRANTES” y allí colocar el listado de los integrantes del taller (máximo 2).
• Una sección llamada “RESPUESTAS” colocar las respuestas a las preguntas.
• La entrega deberá realizarla en Moodle en el espacio correspondiente a su grupo.