diff --git a/.gitea/workflows/merge-dev.yaml b/.gitea/workflows/merge-dev.yaml
new file mode 100644
index 0000000..98f5d4f
--- /dev/null
+++ b/.gitea/workflows/merge-dev.yaml
@@ -0,0 +1,30 @@
+name: Auto-Merge Dev
+run-name: Merging changes from dev
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened]
+    branches: ["feature/*"]
+  push:
+    branches: ["feature/*"]
+  workflow_dispatch:
+    inputs:
+      branch:
+        description: "Branch to merge from dev"
+        required: true
+        default: "feature/example"
+
+jobs:
+  auto-merge-dev:
+    runs-on: windows # Ejecutar directamente en el host Windows
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v2
+
+      - name: Merge changes from dev
+        run: |
+          git switch dev
+          git pull origin dev
+          git switch -
+          git merge dev
+          git push origin
diff --git a/docs/gitflow.md b/docs/gitflow.md
new file mode 100644
index 0000000..e5072b7
--- /dev/null
+++ b/docs/gitflow.md
@@ -0,0 +1,51 @@
+# Galerias Fotograficas -- Git flow
+
+Para poder aportar al desarrollo de nuevas funcionalidades en las galerías fotográficas, todos los cambios pasan un flujo de tests al hacer push sobre cualqueir rama.
+
+Cuando se hace push sobre una rama, se hará un merge de `dev` automaticamente. Tras este merge, se comprobará que no hayan conflictos.
+Justo después, se compilará el back, el front, los tests y los documentos. En caso de que alguno de estos pasos falle, se notificará al desarrollador responsable para que pueda solucionarlo.
+Una vez al dia, se realizará una revisión de las ramas en `dev` para generar una rama `staging/{date}` que se publicará con los cambios del día anterior, siempre y cuando hayan conseguido pasar todos los tests.
+
+Para poder aportar sobre nuevas funcionalidades, se deben seguir los siguientes pasos:
+
+1. Crear una nueva rama a partir de `dev` que se llame `feature/[nombre-de-la-funcionalidad]`.
+2. Realizar los cambios necesarios en la nueva rama.
+3. Hacer push de la rama al repositorio remoto.
+4. Crear un Pull Request (PR) para que los cambios sean revisados e integrados en `dev`.
+
+Una vez que el PR sea aprobado, los cambios se fusionarán en `dev`.
+
+Se seguirá el siguiente flujo:
+
+gitGraph
+    commit
+    branch develop
+    checkout develop
+    commit
+    commit
+    checkout develop
+    branch "feature/one"
+    checkout develop
+    commit
+    checkout "feature/one"
+    commit
+    checkout develop
+    branch "feature/two"
+    checkout develop
+    commit
+    commit
+    commit
+    checkout "feature/two"
+    commit
+    commit
+    merge develop
+    checkout develop
+    merge "feature/two"
+    checkout "feature/one"
+    commit
+    merge develop
+    checkout develop
+    merge "feature/one"
+    commit
+    checkout main
+    merge develop id: "release" tag: "release/{date}"