feat: upgrade tutorial

.github/workflows/build.yaml

@@ -6,7 +6,8 @@ on:
 
 # Environment
 env:
-  PYTHON_VERSION: 3.x
+  PYTHON_VERSION: 3.9
+  POETRY_VERSION: 1.1.13
 
 jobs:
   # Build and deploy documentation site
@@ -21,12 +22,15 @@ jobs:
         with:
           python-version: ${{ env.PYTHON_VERSION }}
 
+      - name: Run image
+        uses: abatilo/[email protected]
+        with:
+          poetry-version: ${{ env.POETRY_VERSION }}
+
       - name: Install dependencies
         run: |
-          python -m pip install --upgrade pip
-          pip install -r requirements.txt
+          poetry install
 
       - name: Deploy
         run: |
-          mkdocs gh-deploy --force
-          mkdocs --version
+          poetry run mkdocs gh-deploy --force

.gitignore

@@ -1 +1,3 @@
+.cache
+poetry.toml
 site/

.vscode/settings.json

@@ -0,0 +1,13 @@
+{
+  "yaml.schemas": {
+    "https://squidfunk.github.io/mkdocs-material/schema.json": "mkdocs.yml"
+  },
+  "yaml.customTags": [
+    "!ENV scalar",
+    "!ENV sequence",
+    "tag:yaml.org,2002:awesome-pages",
+    "tag:yaml.org,2002:python/name:material.extensions.emoji.to_svg",
+    "tag:yaml.org,2002:python/name:material.extensions.emoji.twemoji",
+    "tag:yaml.org,2002:python/name:pymdownx.superfences.fence_code_format"
+  ]
+}

docs/commands.md

@@ -22,8 +22,8 @@ El parámetro `-u` permite que se almacen también los ficheros sin seguimiento
 Permite mostrar la pila del stash.
 
     $ git stash list
-    stash@{0}: On master: Stash con mensaje
-    stash@{1}: WIP on master: 4ab21df First commit
+    stash@{0}: On main: Stash con mensaje
+    stash@{1}: WIP on main: 4ab21df First commit
 
 ### git stash apply
 
@@ -80,17 +80,17 @@ Con `git worktree` podemos crear un directorio de trabajo que contenga otra rama
 
 Esta función es la que crea el espacio de trabajo temporal. Imaginemos que estamos en una rama llamada `develop`:
 
-    $ git worktree add ../project-master master
-    $ git worktree add -b fix ../project-fix master
+    $ git worktree add ../project-main main
+    $ git worktree add -b fix ../project-fix main
 
-La primera orden crea un directorio llamado project-master que contiene el estado de master. La segunda, que contiene el parámetro `-b` equivale a crear una nueva rama llamada fix, que se crea desde master (suponemos que no existe fix).
+La primera orden crea un directorio llamado project-main que contiene el estado de main. La segunda, que contiene el parámetro `-b` equivale a crear una nueva rama llamada fix, que se crea desde main (suponemos que no existe fix).
 
 ### git worktree list
 
 Muestra el listado de directorios y espacios de trabajo.
 
     $git worktree list
-    /home/sergio/taller-de-git  3b63b4b [master]
+    /home/sergio/taller-de-git  3b63b4b [main]
     /home/sergio/fix           3b63b4b [fix]
 
 ### git worktree remove
@@ -103,7 +103,7 @@ Borrar un espacio de trabajo. Hay que indicar el nombre entre corchetes que apar
 
 Una cuestión importante, es que las ramas que estén desplegadas en otro espacio de trabajo, se encuentran bloqueadas y no se pueden desbloquear en otro distinto.
 
-Esto significa que si estamos trabajando en la rama developer, creamos otro worktree en otro directorio de la rama master, no podemos hacer pasar a master. No es posible tener la misma rama en varios espacios de trabajo.
+Esto significa que si estamos trabajando en la rama developer, creamos otro worktree en otro directorio de la rama main, no podemos hacer pasar a main. No es posible tener la misma rama en varios espacios de trabajo.
 
 Si se ha borrado el directorio a mano (en vez de usando remove), eso no implica que el bloqueo desparezca. Con esta orden podemos hacer que git compruebe que los espacios de trabajo secundario se comprueben de nuevo para ver si siguen existiendo y se elimine el bloqueo.
 

docs/gitflow.md

@@ -1,5 +1,11 @@
 # Flujo de trabajo con Git (git flow)
 
+!!! warning
+
+    Esta sección se mantiene por motivos históricos y de documentación. En general, ya se considera
+    una mala práctica seguir este flujo de trabajo. Aunque hay muchos equipos que aun lo utilizan,
+    por lo que viene bien conocerla, no deberías aplicarla en proyectos nuevos.
+
 ## La importancia de la organización del flujo de trabajo
 
 En la introducción vimos los diferentes esquemas de organización externa de los repositorios (es decir, en lo relativo a los usuarios que componen el equipo de trabajo). 
@@ -14,10 +20,10 @@ En los ejemplos hemos visto que usabamos una rama máster y creábamos ramas par
 
 En este esquema hay dos ramas principales con un tiempo de vida indefinido:
 
-- master (_origin/master_): el código apuntado por _HEAD_ siempre contiene un estado listo para producción.
+- main (_origin/main_): el código apuntado por _HEAD_ siempre contiene un estado listo para producción.
 - develop (_origin/develop_): el código apuntado por _HEAD_ siempre contiene los últimos cambios desarrollados para la próxima versión del software. También se le puede llamar _rama de integración_. No es necesariamente estable.
 
-Cuando el código de la rama de desarrollo es lo suficientemente estable, se integra con la rama master y una nueva versión es lanzada.
+Cuando el código de la rama de desarrollo es lo suficientemente estable, se integra con la rama main y una nueva versión es lanzada.
 
 ### Las ramas auxiliares
 
@@ -36,13 +42,13 @@ Para labores concretas, pueden usarse otro tipo de ramas, las cuales tienen un t
 #### Release branches
 
 - Pueden partir de: develop
-- Deben fusionarse con: develop y master
+- Deben fusionarse con: develop y main
 - Convenición de nombres: release-\*
 
 #### Hotfix branches
 
-- Pueden partir de: master
-- Deben fusionarse con: develop y master
+- Pueden partir de: main
+- Deben fusionarse con: develop y main
 - Convenición de nombres: hotfix-\*
 
 ## La extensión flow de Git
@@ -55,7 +61,7 @@ Aunque la fuente original de la extensión es del mismo autor del artículo, el
 
 ### Uso
 
-Para cambiar a las ramas master y develop, seguiremos usando `git checkout`, pero para trabajar con las ramas antes indicadas gitflow nos facilita las siguientes órdenes:
+Para cambiar a las ramas main y develop, seguiremos usando `git checkout`, pero para trabajar con las ramas antes indicadas gitflow nos facilita las siguientes órdenes:
 
 
 #### - git flow init: 
@@ -65,7 +71,7 @@ Inicializa el espacio de trabajo. De forma automática, crea las ramas que neces
 $ git flow init
 Initialized empty Git repository in ~/project/.git/
 No branches exist yet. Base branches must be created now.
-Branch name for production releases: [master]
+Branch name for production releases: [main]
 Branch name for "next release" development: [develop]
 
 How to name your supporting branch prefixes?
@@ -77,7 +83,7 @@ Version tag prefix? []
 
 $ git branch
 * develop
- master
+ main
 ```
 
 Podemos ver que por defecto (usando intro en vez de escribir nada) pone nombres por defecto a cada rama. Con `git branch` comprobamos que ramas existen y en cual nos encontramos.
@@ -122,7 +128,7 @@ Ahora podemos hacer los cambios que estimemos oportuno para integrar todas las f
 $git flow release finish '0.1.0'
 ```
 
-Esto la integrará de forma automática con master (con esto finalizamos el proceso de 'subir a producción' nuestro codigo) y con la rama develop, para que las futuras features estén al día.
+Esto la integrará de forma automática con main (con esto finalizamos el proceso de 'subir a producción' nuestro codigo) y con la rama develop, para que las futuras features estén al día.
 
 
 
@@ -134,7 +140,7 @@ Permite crear y trabajar con ramas de parches. Esto lo usaremos para hacer cambi
 $ git flow hotfix start hotfix_branch
 ```
 
-Tras hacer commit finalizamos la rama hotfix. Esta se fusionará con nuestra rama master y con nuestra rama develop para que esta también esté al día de los últimos cambios.
+Tras hacer commit finalizamos la rama hotfix. Esta se fusionará con nuestra rama main y con nuestra rama develop para que esta también esté al día de los últimos cambios.
 
 ```
 $ git flow hotfix finish hotfix_branch

docs/github-avanzado.md

@@ -50,14 +50,14 @@ Cuando clonamos un repositorio de otro usuario hacemos una copia del original. P
       Push  URL: [email protected]:miusuario/miniblog.git
       HEAD branch (remote HEAD is ambiguous, may be one of the following):
         develop
-        master
+        main
       Remote branches:
         develop tracked
-        master  tracked
+        main  tracked
       Local branch configured for 'git pull':
-        master merges with remote master
+        main merges with remote main
       Local ref configured for 'git push':
-        master pushes to master (up to date)
+        main pushes to main (up to date)
 
 También por convenio, la rama remota que hace referencia al repositorio original se llama _upstream_ y se crea de la siguiente manera:
 
@@ -66,19 +66,19 @@ También por convenio, la rama remota que hace referencia al repositorio origina
     * remote upstream
       Fetch URL: [email protected]:sgomez/miniblog.git
       Push  URL: [email protected]:sgomez/miniblog.git
-      HEAD branch: master
+      HEAD branch: main
       Remote branches:
         develop new (next fetch will store in remotes/upstream)
-        master  new (next fetch will store in remotes/upstream)
+        main  new (next fetch will store in remotes/upstream)
       Local ref configured for 'git push':
-        master pushes to master (local out of date)
+        main pushes to main (local out of date)
 
 En este caso, la URI debe ser siempre la del proyecto original. Y ahora para incorporar actualizaciones, usaremos el merge en dos pasos:
 
     $ git fetch upstream
-    $ git merge upstream/master
+    $ git merge upstream/main
 
-Recordemos que _fetch_ solo trae los cambios que existan en el repositorio remoto sin hacer ningún cambio en nuestro repositorio. Es la orden _merge_ la que se encarga de que todo esté sincronizado. En este caso decimos que queremos fusionar con la rama _master_ que está en el repositorio _upstream_.
+Recordemos que _fetch_ solo trae los cambios que existan en el repositorio remoto sin hacer ningún cambio en nuestro repositorio. Es la orden _merge_ la que se encarga de que todo esté sincronizado. En este caso decimos que queremos fusionar con la rama _main_ que está en el repositorio _upstream_.
 
 ### Creando nuevas funcionalidades
 
@@ -90,9 +90,9 @@ Vamos a crear una nueva funcionalidad: vamos a añadir una licencia de uso. Para
     $ git add LICESE
     $ git commit -m "Archivo de licencia de uso"
 
-En principio habría que probar que todo funciona bien y entonces integraremos en la rama _master_ de nuestro repositorio y enviamos los cambios a Github:
+En principio habría que probar que todo funciona bien y entonces integraremos en la rama _main_ de nuestro repositorio y enviamos los cambios a Github:
 
-    $ git checkout master
+    $ git checkout main
     $ git merge add-license --no-ff
     $ git branch -d add-license
     # Borramos la rama que ya no nos sirve para nada
@@ -123,7 +123,7 @@ Ahora sí, el administrador puede aprobar la fusión y borrar la rama del reposi
 
 Una vez que se han aceptado los cambios, podemos borrar la rama y actualizar nuestro repositorio con los datos del remoto como hicimos antes. ¿Por qué actualizar desde el remoto y no desde nuetra rama _add-license_? Pues porque usualmente el administrador puede haber modificado los cambios que le hemos propuesto, o incluso una tercera persona. Recordemos el cariz colaborativo que tiene Github.
 
-    $ git checkout master
+    $ git checkout main
     $ git branch -d add-license
     # Esto borra la rama local
     $ git push origin --delete add-license

docs/github-flow.md

@@ -124,19 +124,19 @@ GitHub permite que entre los desarrolladores se pueda abrir una discusión sobre
 
 ## Paso 4. Desplegar
 
-Una vez que hemos terminado de crear la función de la rama ya podemos incorporar los cambios a _master_. Este trabajo ya no es necesario hacerlo en local y GitHub nos proporciona 3 maneras de hacerlo:
+Una vez que hemos terminado de crear la función de la rama ya podemos incorporar los cambios a _main_. Este trabajo ya no es necesario hacerlo en local y GitHub nos proporciona 3 maneras de hacerlo:
 
 ![Cómo cerrar un Pull Request](images/github-flow-merge.png)
 
 ### Crear un merge commit
 
 Esta opción es el equivalente a hacer lo siguiente en nuestro repositorio:
 
-    $ git checkout master
+    $ git checkout main
     $ git merge --no-ff sgomez/feature-1/create-changelog
     $ git push
 
-Es decir, el equivalente a hacer un merge entre nuestra rama y master.
+Es decir, el equivalente a hacer un merge entre nuestra rama y main.
 
 !!! info
 GitHub siempre desactiva el _fast forward_.
@@ -145,22 +145,22 @@ GitHub siempre desactiva el _fast forward_.
 
 Esta opción es el equivalente a hacer lo siguiente en nuestro repositorio
 
-    $ git rebase master
-    $ git checkout master
+    $ git rebase main
+    $ git checkout main
     $ git merge --no-ff sgomez/feature-1/create-changelog
     $ git push
 
-Es decir, nos aseguramos de que nuestra rama está al final de _master_ haciendo _rebase_, como vimos en el capítulo de ramas, y posteriormente se hace el merge.
+Es decir, nos aseguramos de que nuestra rama está al final de _main_ haciendo _rebase_, como vimos en el capítulo de ramas, y posteriormente se hace el merge.
 
 ### Crear un squash commit y un merge
 
 Esta opción es el equivalente a hacer lo siguiente en nuestro repositorio:
 
-    $ git checkout master
+    $ git checkout main
     $ git merge --squash sgomez/feature-1/create-changelog
     $ git push
 
-Esta opción es algo especial. En vez de aplicar cada uno de los commits en la rama master, ya sea directamente (_fast forward_) o no, lo que hace es crear un solo commit con los cambios de todos los commits de la rama. El efecto final es como si en la rama solo hubiera producido un solo commit.
+Esta opción es algo especial. En vez de aplicar cada uno de los commits en la rama main, ya sea directamente (_fast forward_) o no, lo que hace es crear un solo commit con los cambios de todos los commits de la rama. El efecto final es como si en la rama solo hubiera producido un solo commit.
 
 Vamos a seleccionar este último (squash and merge) y le damos al botón para activarlo. Nos saldrá una caja para que podamos crear una descripción del commit y le damos a confirmar.
 
@@ -176,16 +176,16 @@ Las consecuencias de esta acción son las siguientes:
 
 ## Paso 5. Sincronizar
 
-Hemos cambiado el repositorio en GitHub, pero nuestra rama master no contiene los mismos cambios que el de origin. Así que nos toca sincronizar y borrar la rama obsoleta:
+Hemos cambiado el repositorio en GitHub, pero nuestra rama main no contiene los mismos cambios que el de origin. Así que nos toca sincronizar y borrar la rama obsoleta:
 
-    $ git checkout master
+    $ git checkout main
     $ git pull --rebase --autostash
     $ git branch -D sgomez/feature-1/create-changelog
 
 !!! info
 
     ¿Por qué _squash and merge_ y no un _merge_ o _rebase_? De nuevo
-    depende de los gustos de cada equipo de desarrollo. Las cracterísticas de _squash_ es que elimina (relativamente) rastros de errores intermedios mientras se implementaba la rama, deja menos commits en la rama _master_ y nos enlace al PR donde se implementaron los cambios.
+    depende de los gustos de cada equipo de desarrollo. Las cracterísticas de _squash_ es que elimina (relativamente) rastros de errores intermedios mientras se implementaba la rama, deja menos commits en la rama _main_ y nos enlace al PR donde se implementaron los cambios.
 
     Para algunas personas estas características son unas ventajas, para otras no. Lo mejor es experimentar cada opción y cada uno decida
     como quiere trabajar.