Differences

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

--- start [2023/06/06 00:18] – [Descargar un repositorio y actualizarlo] 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 139: / Line 202: @@
 \\
+===== Revisión de código y Pull Requests =====
 ----
@@ Line 153: / 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 160: / 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 170: / 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 247: / Line 308: @@
 santi@zenbook:$ git merge develop
 </code>
+===== Fusionar ramas via Pull Request =====
 ===== Eliminar un fichero del repositorio remoto =====