chore: bump version and update CHANGELOG.md [skip ci]

Reviewed-on: #17

CHANGELOG.md

@@ -1,3 +1,18 @@
+## v1.20.2 - 2026-09-15
+
+- **bugfix**:  include group path in repo for gitlab support [[jteran](mailto:jteran@renatre.org.ar)] (3e44854)
+
+---
+
+
+## v1.20.1 - 2026-09-14
+
+- **refactor**:  cambiar incremento de commits refactor y perf [[jonathan.nerat](mailto:jonathan.nerat@gmail.com)] (c035a88)
+- **refactor**:  eliminar preguntas innecesarias de release y merge [[jonathan.nerat](mailto:jonathan.nerat@gmail.com)] (0c31c74)
+
+---
+
+
 ## v1.20.0 - 2026-09-13
 
 - **feature**:  add gitlab remote support [[jonathan.nerat](mailto:jonathan.nerat@gmail.com)] (748d420)

README.md

@@ -15,7 +15,7 @@ carpeta local, y lo instalamos:
 
 ```sh
 cd ~/Downloads
-git clone git@bitbucket.org:sushi2717/git-flow.git
+git clone ssh://git@git.jonathanteran.dev:59169/jt/git-flow.git
 cd git-flow
 pipx install .
 ```
@@ -51,23 +51,25 @@ El comando solicitará 2 opciones:
     - [x] Gitea
     - [x] Gitlab
 
-  La configuración del remoto requiere tener un Access Token para poder crear los PRs automáticamente.
-  El mismo se puede crear desde el repositorio al que se quiere dar acceso: *"Repository settings" >
-  "Access Tokens" > "Create access token"*. El token necesita permiso para *Write* en *Pull Requests*.
+  La configuración del remoto requiere tener un Access Token para poder crear los PRs y tags
+  automáticamente. Ver la sección [Remotos soportados](#remotos-soportados) para las instrucciones
+  de cómo generar el token en cada proveedor.
 
-  Luego se debe guardar el token dentro del repositorio a configurar, en el archivo
+  Una vez generado, el token se debe guardar dentro del repositorio a configurar, en el archivo
   `.repository-token`. De no especificarse, los merges y tags se harán de forma local.
 
 ## Utilización
 
-Git Flow cuenta con 5 comandos principales para guiar el workflow (ver `git-flow <command> -h` para
+Git Flow cuenta con los siguientes comandos para guiar el workflow (ver `git-flow <command> -h` para
 más información):
 
+- `init`: Inicializa el repositorio para utilizar git-flow (ramas principales y remoto).
 - `new`: Crea una nueva rama siguiendo CB.
 - `commit`: Crea un commit siguiendo CC.
 - `merge`: Mergea la rama actual a una de las ramas principales.
 - `tag`: Crea un tag sobre el ultimo merge siguiendo SemVer.
-- `release`: Prepara la rama actual para pasarse al siguiente entorno configurado
+- `release`: Prepara la rama actual para pasarse al siguiente entorno configurado.
+- `branch`: Lista las ramas del repositorio, agrupadas por entorno objetivo.
 
 El workflow para el cual se penso la herramienta es el siguiente:
 
@@ -86,9 +88,147 @@ El workflow para el cual se penso la herramienta es el siguiente:
    `feature/my-new-feature`, se crea la rama `release/test/feature/my-new-feature` sobre `test` que
    tiene los cambios de la rama original.
 
+En cualquier momento se puede usar `git-flow branch` para ver en qué entorno está cada rama, y cuáles
+están todavía en progreso (`wip/`) o descartadas (`trash/`).
+
+## Remotos soportados
+
+Cada remoto necesita un Access Token con permisos para crear Pull/Merge Requests y tags. El token se
+guarda en el archivo `.repository-token` en la raíz del repositorio (una única línea con el valor del
+token), o se pasa por parámetro con `--token=<TOKEN>` al comando `git-flow tag` (útil para no
+commitear el token y usarlo solo desde un pipeline mediante una variable secreta).
+
+### Github
+
+1. Ir a *Settings* del repositorio (o de la organización) > *Developer settings* > *Personal access
+   tokens* > *Fine-grained tokens* > *Generate new token*.
+2. Seleccionar el repositorio sobre el que se va a usar `git-flow`.
+3. En *Repository permissions*, otorgar:
+   - **Contents**: Read and write (necesario para crear tags).
+   - **Pull requests**: Read and write (necesario para crear PRs).
+4. Generar el token y guardarlo en `.repository-token`.
+
+Ejemplo de pipeline (GitHub Actions) para taggear automáticamente en cada push a una rama principal:
+
+```yaml
+# .github/workflows/tag.yml
+name: Tag and publish
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  tag:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: astral-sh/setup-uv@v3
+
+      - run: uv run git-flow tag --token=${{ secrets.GIT_FLOW_TOKEN }}
+
+      - run: uv build
+      - run: uv publish --token=${{ secrets.PYPI_TOKEN }}
+```
+
+### Gitlab
+
+1. Ir a *Settings* > *Access Tokens* del proyecto (o *Group access tokens* si se quiere usar a nivel
+   grupo).
+2. Crear un token con rol **Developer** o superior, y los scopes:
+   - **api** (o al menos `write_repository` para tags y `api` para Merge Requests).
+3. Generar el token y guardarlo en `.repository-token`.
+
+Ejemplo de pipeline (GitLab CI) para taggear automáticamente en cada push a una rama principal:
+
+```yaml
+# .gitlab-ci.yml
+tag:
+  image: python:3.14
+  rules:
+    - if: $CI_COMMIT_BRANCH == "main"
+  script:
+    - pip install uv
+    - uv run git-flow tag --token=$GIT_FLOW_TOKEN
+    - uv build
+    - uv publish --token=$PYPI_TOKEN
+```
+
+El token debe guardarse como variable protegida y enmascarada (`GIT_FLOW_TOKEN`) en *Settings* >
+*CI/CD* > *Variables*.
+
+### Bitbucket
+
+1. Ir a *Repository settings* > *Access Tokens* > *Create access token* (o *Workspace settings* >
+   *Access Tokens* para un token a nivel workspace).
+2. Otorgar permiso de **Write** en *Pull requests* y *Repositories* (necesario para crear tags).
+3. Generar el token y guardarlo en `.repository-token`.
+
+Este mismo repositorio usa Git Flow para el taggeo automático usando Bitbucket Pipelines, se puede
+ver el archivo `bitbucket-pipelines.yml` como ejemplo:
+
+```yaml
+# bitbucket-pipelines.yml
+image: python:3.14
+
+pipelines:
+  branches:
+    'main':
+      - step:
+          name: "Tag and publish package"
+          caches:
+            - pip
+          script:
+            - pip install uv
+            - uv run git-flow tag --token=$BEARER
+            - uv build
+            - uv publish --token=$PYPI_TOKEN
+```
+
+El token se configura como variable segura del repositorio (`BEARER`) en *Repository settings* >
+*Repository variables*.
+
+### Gitea
+
+1. Ir a *Settings* del usuario (o de la organización) > *Applications* > *Manage Access Tokens* >
+   *Generate New Token*.
+2. Otorgar permiso de escritura sobre:
+   - **repository** (necesario para crear tags).
+   - **issue** (necesario para crear PRs, ya que Gitea expone los PRs bajo el mismo scope).
+3. Generar el token y guardarlo en `.repository-token`.
+
+Ejemplo de pipeline (Gitea Actions) para taggear automáticamente en cada push a una rama principal:
+
+```yaml
+# .gitea/workflows/tag.yml
+name: Tag and publish
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  tag:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: astral-sh/setup-uv@v3
+
+      - run: uv run git-flow tag --token=${{ secrets.GIT_FLOW_TOKEN }}
+
+      - run: uv build
+      - run: uv publish --token=${{ secrets.PYPI_TOKEN }}
+```
+
 ## Taggeo automático por pipeline
 
-Éste repositorio utiliza Git Flow para el taggeo automático usando pipelines, se puede ver el
-archivo `bitbucket-pipelines.yml` como ejemplo. El comando `git-flow tag` soporta el pasaje del
-token mediante la opción `--token=<TOKEN>`. Ver la sección [Configuración](#configuracion) para las
-instrucciones de como generar este token. El mismo necesita scope `write:repository:bitbucket`.
+En todos los casos, `git-flow tag` detecta que se está ejecutando desde un pipeline (no encuentra
+`.repository-token` en el repositorio) y usa el token pasado por `--token=<TOKEN>` tanto para crear
+el tag en el remoto como para pushear el commit del `CHANGELOG.md` generado, en vez de crear el tag
+únicamente en forma local como sucede al ejecutarlo manualmente sin remoto configurado.

src/git_flow/__init__.py

@@ -36,8 +36,8 @@ COMMIT_TYPE_INCREMENT = {
     "feature": SEMVER_MINOR,
     "bugfix": SEMVER_PATCH,
     "hotfix": SEMVER_PATCH,
-    "refactor": SEMVER_SKIP,
-    "perf": SEMVER_SKIP,
+    "refactor": SEMVER_PATCH,
+    "perf": SEMVER_PATCH,
     "docs": SEMVER_SKIP,
     "style": SEMVER_SKIP,
     "test": SEMVER_SKIP,

src/git_flow/command/merge.py

@@ -119,10 +119,6 @@ def create_pull_request(token: str, branch: str, target: str):
 
     base.io_success(message, "Rama creada")
 
-    if base.io_confirm("¿Desea cambiar a la rama objetivo y bajar los cambios?"):
-        Git("switch", target).exec(print="Cambiando a rama objetivo")
-        Git("pull").exec(print="Obteniendo cambios")
-
 
 def _get_pr_title_from_branch(branch: str) -> str:
     if branch in base.environments:

src/git_flow/command/release.py

@@ -1,16 +1,14 @@
-from typing import Optional
-
 import typer
 
 import git_flow.command.base as base
-from git_flow import COMMIT_TYPES, GitFlowError
+from git_flow import GitFlowError
 from git_flow.git import Git
 
 app = typer.Typer()
 
 
 @app.command()
-def release(group: Optional[str] = None):
+def release():
     """Realiza el merge de la rama, o crea el PR para hacerlo si tiene un remoto configurado"""
     base.ensure_initialized()
 
@@ -44,45 +42,17 @@ def release(group: Optional[str] = None):
     for commit in commits:
         print("- " + commit)
 
-    grouping = group is not None
-
-    if not group:
-        if base.io_confirm("¿Desea agrupar este release con otra rama?", False):
-            grouping = True
-            group = base.io_choice(
-                "Grupo release: ", Git.get_branches("release/" + next_env + "/")
-            )
-        else:
-            group = next_env
-
-    if has_remote and Git.get_tracking_branch(group):
-        Git("switch", group).exec(print="Cambiando a la rama objetivo")
+    if has_remote and Git.get_tracking_branch(next_env):
+        Git("switch", next_env).exec(print="Cambiando a la rama objetivo")
         Git("pull").exec(print="Sincronizando cambios la rama objetivo")
         Git("switch", "-").exec(print="Volviendo a la rama original")
 
-    if len(commits) > 1 and base.io_confirm(
-        f"¿Desea reemplazar los {len(commits)} commits de la rama por uno solo?", False
-    ):
-        base.io_info("Debe ingresar el mensaje del commit a crear.")
-        message = base.get_commit_message(COMMIT_TYPES[:-1])
+    Git("switch", next_branch, create=True).exec(print="Creando rama release")
 
-        Git("switch", next_branch, fork_point, create=True).exec(
-            print="Creando rama release en base"
-        )
-        Git("merge", branch, squash=True).exec(print="Squasheando commits en uno solo")
-        Git("commit", m=message).exec(print="Creando commit único")
-    else:
-        Git("switch", next_branch, create=True).exec(print="Creando rama release")
-
-    status = Git("rebase", fork_point, next_branch, onto=group).code(
+    status = Git("rebase", fork_point, next_branch, onto=next_env).code(
         print="Moviendo cambios hacia el siguiente ambiente"
     )
 
     if status:
         Git("rebase", abort=True).exec(print="Deshaciendo cambios por conflictos")
         raise GitFlowError("Error al realizar pasaje de cambios a rama objetivo")
-    elif grouping:
-        Git("switch", group).exec(print="Cambiando a rama objetivo")
-        Git("merge", next_branch, ff_only=True).exec(
-            print="Mergeando cambios de la nueva rama"
-        )

src/git_flow/remote/base.py

@@ -35,8 +35,15 @@ class RemoteAPI(ABC):
 
         # Cuando el host es seteado por pipeline puede ser "http://gitea/OWNER/REPO", en ese caso
         # la libreria parsea OWNER="" y REPO="OWNER/REPO"
+        # En GitLab, los proyectos pueden estar dentro de grupos y subgrupos (ej:
+        # owner/grupo/subgrupo/repo), que la libreria expone por separado en groups_path
         repository = (
-            "/".join(filter(None, [parsed_url.owner, parsed_url.repo]))
+            "/".join(
+                filter(
+                    None,
+                    [parsed_url.owner, parsed_url.groups_path, parsed_url.repo],
+                )
+            )
             .removeprefix("/")
             .removesuffix(".git")
         )