Differences

This shows you the differences between two versions of the page.

--- start [2023/06/06 00:18] – [Arreglar conflictos] Santiago Faci
+++ start [2024/11/01 19:25] (current) – [Pull Requests] Santiago Faci
@@ Line 18: / Line 18: @@
 <code bash>
 santi@zenbook:$ sudo apt-get install git
+</code>
+En el caso de que uséis macOS, lo más sencillo es instalarlo usando brew (https://git-scm.com/downloads/mac):
+<code bash>
+# Instalar primero brew si no se ha hecho antes
+santi@zenboo:$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+# Instalar git usando brew
+santi@zenbook:$ brew install git
 </code>
@@ Line 116: / Line 125: @@
 {{ youtube>A_FdoQJ0knY }}
 \\
+===== El fichero README =====
+Es un fichero, que podemos escribir en síntaxis //Markdown//, donde podemos realizar una breve descripción de nuestro proyecto y que GitHub se encargará de renderizar en la portada de la web de nuestro repositorio. Así, es bastante habitual incluir las siguientes secciones:
+  * Título del proyecto
+  * Descripción del proyecto
+  * Requisitos para la instalación
+  * Guía rápida de instalación (y si hay más documentación se enlaza aqui, por ejemplo a la Wiki del proyecto)
+  * Enlace a la web (si la hay)
+  * Información sobre los autores del proyecto
+Hay que tener en cuenta la importancia de este fichero ya que es la primera descripción que un usuario encontrará cuando acceda a nuestro repositorio
+===== El gestor de incidencias =====
+El gestor de incidencias (//issues//) de GitHub permite registrar cualquier tipo de incidencia (//bug, enhancement, proposa o task//) en la plataforma para que pueda ser gestionada y tratada por el equipo de desarrollo. Las incidencias deberán ser asignadas a un usuario que será el encargado de resolverla. Conviene tener en cuenta que hay que marcarlo en el momento de crear el repositorio si queremos poder utilizarlo.
+Lo más importante a la hora de registrar una incidencia es asignarle un título y descripción para que sea fácil de encontrar y reproducir por quién tenga que resolverla (incluso aunque sea uno mismo, no siempre se pueden resolver las incidencias en el momento de encontrarlas y más tarde quizás olvidemos algún detalle). Menos importante pero interesante será definir la inmportancia de la //issue// (ayudará a priorizar) y el tipo de incidencia:
+  * **bug**: Un fallo que se ha localizado en el código
+  * **enhancement**: Una mejora sobre el código ya escrito
+  * **proposal**: Una propuesta sobre el código que ya funciona
+  * **task**: Una tarea que debe realizarse. No tiene porque ir asociada a ningún problema o bug de código
+También podemos adjuntar algún fichero, como por ejemplo capturas que ayuden a detectar o comprender mejor el problema.
+Por último, la incidencia puede ser directamente asignada a un usuario (incluso a uno mismo). En caso de que no se sepa quién debe realizarla se puede dejar en blanco esperando que el responsable decida quién la tiene que corregir.
+La vista de incidencias tiene filtros automáticos que permiten localizar las incidencias rapidamente por su estado.
+Además, el gestor de incidencias de GitHub permite realizar ciertas gestiones sobre las mismas utilizando una serie de comandos que directamente pueden ser aplicados cuando se realizan los //commit// sobre el código con el comando //git//. Una lista de los comandos y opciones disponibles se puede encontrar [[https://docs.github.com/es/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue|aqui]].
+Por ejemplo, si tenemos una incidencia abierta con el número #13 que hace referencia a un //bug// en cierta parte del código, cuando resolvamos el error y nos dispongamos a hacer el //commit// que soluciona dicho problema, podemos ejecutar ese comando de la siguiente forma:
+<code bash>
+santi@zenbook:$ git commit -m 'Corregido el fallo que impedía conectar con la Base de Datos fix #13'
+</code>
+De esta forma, la incidencia con el número #13 será automáticamente marcada como resuelta sin que tengamos que acceder con el navegador al gestor de incidencias y resolverla manualmente a través de la web. Además, el mensaje del //commit// quedará asociado como mensaje de resolución de dicha incidencia.
+===== La Wiki =====
+Siempe que creemos por primera vez un repositorio en GitHub tendremos la oportunidad de decidir si queremos que se integre una Wiki con él.
+A través de la Wiki podremos crear documentación asociada a nuestro proyecto/repositorio utilizando como síntaxis //Markdown// para su edición. En la página de GitHub puedes encontrar una [[https://docs.github.com/en/github/building-a-strong-community/about-wikis|Guía para la Wiki de GitHub]] que puedes usar con la plataforma para saber cómo trabajar con la Wiki y para conocer la sintaxis que debes usar para editarla.
 ===== Descargar un repositorio y actualizarlo =====
@@ Line 122: / Line 176: @@
 <code bash>
-santi@zenbook:$ git clone https://github.com/usuario/el-proyecto
+santi@zenbook:$ git clone https://github.com/usuario/miproyecto
+</code>
+Ahora podemos trabajar en el proyecto y, cuando queramos subir los cambios realizados, podemos proceder como antes hemos visto y actualizar el repositorio remoto:
+<code bash>
+santi@zenbook:/miproyecto$ git add ficheros-o-carpetas
+santi@zenbook:/miproyecto$ git commit . . .
+. . .
+. . .
 </code>
@@ Line 128: / Line 191: @@
 \\
+===== Arreglar conflictos =====
+Cuando dos programadores trabajan sobre el mismo fichero de código, se puede llegar a producir un conflicto.
+Supongamos un fichero sobre el que un programador ha hecho algún cambio que ha subido al repositorio remoto. Cuando un segundo programador intente subir un cambio sobre ese mismo fichero, se producirá un conflicto en el momento en que éste intente poner al día su repositorio (''pull'') antes de subir sus cambios.
+El segundo programador tendrá que arreglar el conflicto antes de poder subir definitivamente su cambio (tras la decisión que haya tomado acerca de cómo fusionar su parte con la de su compañero).
+{{ youtube>jp2xun4IQXU }}
+\\
+===== Revisión de código y Pull Requests =====
 ----
@@ Line 141: / Line 216: @@
 <caption>Ramas main develop</caption>
 </figure>
+{{ youtube>uDbQpK_t0uA }}
+\\
 Asi, a medida que se necesiten desarrollar nuevas funcionalidades (//features//), éstas se harán en nuevas ramas creadas expresamente para dicha funcionalidad. Se trabajará en ella y, cuando esté terminada, se fusionará con //develop// para incorporar el código a la rama de desarrollo.
@@ Line 148: / Line 226: @@
 <caption>Features</caption>
 </figure>
+{{ youtube>IXoLrLXTkR8 }}
+\\
 Cuando llega el momento de liberar una nueva versión, se crea una nueva rama con el objetivo de comenzar el ciclo de liberación. Ya no es posible incorporar nuevas funcionalidades a esta nueva rama (nueva //release//) sino que solamente se corrigen fallos y cualquier otra tarea relacionada con la liberación de la nueva versión. Finalmente, cuando está lista, se fusiona con la rama principal (//main//).
@@ Line 158: / Line 239: @@
 Si nos fijamos en el flujo de trabajo, veremos que es posible que, mientras una parte del equipo trabaja en liberar y preparar la nueva versión, otra parte del mismo puede seguir trabajando, al mismo tiempo, en las nuevas funcionalidades de la siguiente versión.
-===== Preparar el repositorio para trabajar con GitFlow =====
-{{ youtube>uDbQpK_t0uA }}
-\\
-===== Crear una nueva feature y fusionarla con develop usando Pull Request =====
-{{ youtube>IXoLrLXTkR8 }}
-\\
@@ Line 235: / Line 308: @@
 santi@zenbook:$ git merge develop
 </code>
+===== Fusionar ramas via Pull Request =====
 ===== Eliminar un fichero del repositorio remoto =====
@@ Line 371: / Line 446: @@
 </code>
-===== Arreglar conflictos =====
-Cuando dos programadores trabajan sobre el mismo fichero de código, se puede llegar a producir un conflicto.
-Supongamos un fichero sobre el que un programador ha hecho algún cambio que ha subido al repositorio remoto. Cuando un segundo programador intente subir un cambio sobre ese mismo fichero, se producirá un conflicto en el momento en que éste intente poner al día su repositorio (''pull'') antes de subir sus cambios.
-El segundo programador tendrá que arreglar el conflicto antes de poder subir definitivamente su cambio (tras la decisión que haya tomado acerca de cómo fusionar su parte con la de su compañero).
-{{ youtube>jp2xun4IQXU }}
-\\
 ----
 (c) 2020-{{date>%Y}} Santiago Faci