diff --git a/README.md b/README.md
index 9405cb8..8b5471a 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-# Versioning Workflow
+# Versioning Workflow <!-- omit from toc -->
 
 ![GitHub Release](https://img.shields.io/github/v/release/davidsonbrsilva/versioning-workflow)
 ![License](https://img.shields.io/github/license/davidsonbrsilva/versioning-workflow.svg)
@@ -9,30 +9,31 @@
 
 _Versioning Workflow_ is a tool that allows automatic versioning of your code. It is based on [_conventional commits_](https://www.conventionalcommits.org/en/v1.0.0/) and branch patterns to determine versions. The generated versions follow [semantic versioning](https://semver.org/).
 
-## Summary
+## Summary <!-- omit from toc -->
 
-- [Versioning Workflow](#versioning-workflow)
-  - [Summary](#summary)
-  - [Installation](#installation)
-  - [Usage](#usage)
-    - [Release creation workflow](#release-creation-workflow)
-      - [Using a different name for the main branch](#using-a-different-name-for-the-main-branch)
-      - [The `upsert_major_version` job](#the-upsert_major_version-job)
-    - [Pre-release creation workflow](#pre-release-creation-workflow)
-      - [Customizing branch names to generate versions](#customizing-branch-names-to-generate-versions)
-      - [Using more than one branch name to generate versions](#using-more-than-one-branch-name-to-generate-versions)
-  - [Contact](#contact)
-  - [License](#license)
+- [1. Installation](#1-installation)
+- [2. Usage](#2-usage)
+  - [2.1. Release creation workflow](#21-release-creation-workflow)
+    - [2.1.1. Using a different name for the main branch](#211-using-a-different-name-for-the-main-branch)
+    - [2.1.2. The `upsert_major_version` job](#212-the-upsert_major_version-job)
+  - [2.2. Pre-release creation workflow](#22-pre-release-creation-workflow)
+    - [2.2.1. Customizing branch names to generate versions](#221-customizing-branch-names-to-generate-versions)
+    - [2.2.2. Using more than one branch name to generate versions](#222-using-more-than-one-branch-name-to-generate-versions)
+  - [2.3. Using the `v` prefix for versions](#23-using-the-v-prefix-for-versions)
+  - [2.4. Customizing the release name](#24-customizing-the-release-name)
+  - [2.5. Adding a prefix to the release name](#25-adding-a-prefix-to-the-release-name)
+- [3. Contact](#3-contact)
+- [4. License](#4-license)
 
-## Installation
+## 1. Installation
 
 Copy the `create-pre-release.yml` and `create-release.yml` files from the `.github/workflows` directory to a directory with the same name at the root of your project. That's it!
 
-## Usage
+## 2. Usage
 
 There are two workflows available for you to use: the **release creation** and the **pre-release creation**. You can choose to use only the release creation workflow or combine it with the pre-release creation workflow.
 
-### Release creation workflow
+### 2.1. Release creation workflow
 
 ```yml
 name: Release
@@ -56,60 +57,45 @@ This is the most basic way to use this workflow. It will be triggered whenever c
 3. Commits that start with `fix:` generate new patch versions of the code (for example, from `0.1.0` to `0.1.1`).
 4. Commits in any other pattern generate minor versions of the code (for example, from `0.1.0` to `0.2.0`).
 
-#### Using a different name for the main branch
+#### 2.1.1. Using a different name for the main branch
 
 By default, `main` is considered the main branch, but you can modify this through the `main_branch` parameter:
 
 ```yml
-name: Release
-
-on:
-  push:
-    branches: ["master"]
-
-jobs:
-  create_release:
-    name: Create release
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
-    permissions:
-      contents: write
-    with:
-      main_branch: "master"
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    main_branch: "master"
 ```
 
-#### The `upsert_major_version` job
+#### 2.1.2. The `upsert_major_version` job
 
 In the `create-release.yml` file template, you will notice that there is a job called `upsert_major_version`:
 
 ```yml
 upsert_major_version: # Optional
-    name: Upsert major version
-    needs: create_release
-    permissions:
-      contents: write
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1
-    with:
-      version: ${{ needs.create_release.outputs.version }}
+  name: Upsert major version
+  needs: create_release
+  permissions:
+    contents: write
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1
+  with:
+    version: ${{ needs.create_release.outputs.version }}
 ```
 
 This job is optional and can be removed if you want. With each release version, it generates a `v[major_version]` tag (for example, `v1`) and keeps it updated, always referencing the latest version, until a new major version is released.
 
-### Pre-release creation workflow
+### 2.2. Pre-release creation workflow
 
 ```yml
-name: Pre-release
-
-on:
-  pull_request:
-    branches: ["main"]
-    types: ["opened", "synchronize", "reopened"]
-
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    permissions:
-      contents: write
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
 ```
 
 This is the most basic way to use the pre-release workflow. It will be triggered on pull request events: on opening, during new commits, and on reopening. Each new change in a pull request will generate a release candidate version (`-rc-<number>`).
@@ -124,7 +110,7 @@ Release candidate versions are incremented with each new change (for example, fr
 
 > If the branch does not match any of the previous patterns, the automatic pre-release version will not be generated.
 
-#### Customizing branch names to generate versions
+#### 2.2.1. Customizing branch names to generate versions
 
 Just like in the release creation workflow, you can also inform a different name for the main branch through `main_branch`. The same goes for feature, release, and hotfix branches:
 
@@ -132,45 +118,118 @@ Just like in the release creation workflow, you can also inform a different name
 2. To generate patch versions, the workflow will look for branches that match the pattern of the `hotfix_branches` parameter. If the parameter is not informed, the value `hotfix` will be considered as the default name.
 
 ```yml
-name: Pre-release
-
-on:
-  pull_request:
-    branches: ["main"]
-    types: ["opened", "synchronize", "reopened"]
-
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    permissions:
-      contents: write
-    with:
-      main_branch: "main"
-      feature_branches: "feature"
-      release_branches: "release"
-      hotfix_branches: "hotfix"
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    main_branch: "main"
+    feature_branches: "feature"
+    release_branches: "release"
+    hotfix_branches: "hotfix"
 ```
 
-#### Using more than one branch name to generate versions
+#### 2.2.2. Using more than one branch name to generate versions
 
 Finally, you can also use more than one branch name for the `feature_branches`, `release_branches`, and `hotfix_branches` parameters, if you want. For example:
 
 ```yml
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    with:
-      feature_branches: "feat feature" # will accept source branch match for both 'feat' and 'feature'
-      release_branches: "rel release" # will accept source branch match for both 'rel' and 'release'
-      hotfix_branches: "fix hotfix" # will accept source branch match for both 'fix' and 'hotfix'
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  with:
+    feature_branches: "feat feature" # will accept source branch match for both 'feat' and 'feature'
+    release_branches: "rel release" # will accept source branch match for both 'rel' and 'release'
+    hotfix_branches: "fix hotfix" # will accept source branch match for both 'fix' and 'hotfix'
+```
+
+### 2.3. Using the `v` prefix for versions
+
+Some tools, like Github, suggest using versions that start with `v`, such as `v1.0.0`. You can enable this behavior using the `use_v_prefix` flag:
+
+**Release creation workflow**
+```yaml
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    use_v_prefix: true
+```
+
+**Pre-release creation workflow**
+```yaml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    use_v_prefix: true
+```
+
+### 2.4. Customizing the release name
+
+By default, generated release names receive the name used to generate the version. You can override this behavior using the `release_name` property:
+
+**Release creation workflow**
+```yaml
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name: "My Amazing Release"
+```
+
+**Pre-release creation workflow**
+```yaml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name: "My Amazing Release"
+```
+
+With this property, all created releases will receive the name "My Amazing Release" instead of the version name.
+
+### 2.5. Adding a prefix to the release name
+
+You can also define a prefix to be adopted in the release name. This is useful in cases where you still want to keep the generated version in the release name but want to add a prefix of your choice. This can be achieved through the `release_name_prefix` property:
+
+**Release creation workflow**
+```yaml
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name_prefix: "Github"
 ```
 
-## Contact
+**Pre-release creation workflow**
+```yaml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name_prefix: "Github"
+```
+
+In this example, the created releases will follow the pattern "Github 1.0.0".
+
+## 3. Contact
 
 For questions or suggestions, send an email to <davidsonbruno@outlook.com>.
 
-## License
+## 4. License
 
 MIT Copyright (c) 2024 Davidson Bruno
diff --git a/README.pt.md b/README.pt.md
index e06250b..adc8c8f 100644
--- a/README.pt.md
+++ b/README.pt.md
@@ -1,4 +1,4 @@
-# Versioning Workflow
+# Versioning Workflow <!-- omit from toc -->
 
 ![GitHub Release](https://img.shields.io/github/v/release/davidsonbrsilva/versioning-workflow)
 ![License](https://img.shields.io/github/license/davidsonbrsilva/versioning-workflow.svg)
@@ -9,30 +9,31 @@
 
 _Versioning Workflow_ é uma ferramenta que permite a geração automática de versões do seu código. Ele se baseia em [_conventional commits_](https://www.conventionalcommits.org/pt-br/v1.0.0/) e padrões de branches para determinar as versões. As versões geradas seguem o [versionamento semântico](https://semver.org/lang/pt-BR/).
 
-## Sumário
+## Índice <!-- omit from toc -->
 
-- [Versioning Workflow](#versioning-workflow)
-  - [Sumário](#sumário)
-  - [Instalação](#instalação)
-  - [Uso](#uso)
-    - [Workflow de criação de release](#workflow-de-criação-de-release)
-      - [Usando um nome diferente para a branch principal](#usando-um-nome-diferente-para-a-branch-principal)
-      - [O job `upsert_major_version`](#o-job-upsert_major_version)
-    - [Workflow de criação de pré-release](#workflow-de-criação-de-pré-release)
-      - [Customizando nomes de branches para gerar as versões](#customizando-nomes-de-branches-para-gerar-as-versões)
-      - [Usando mais de um nome de branch para gerar as versões](#usando-mais-de-um-nome-de-branch-para-gerar-as-versões)
-  - [Contato](#contato)
-  - [License](#license)
+- [1. Instalação](#1-instalação)
+- [2. Uso](#2-uso)
+  - [2.1. Workflow de criação de release](#21-workflow-de-criação-de-release)
+    - [2.1.1. Usando um nome diferente para a branch principal](#211-usando-um-nome-diferente-para-a-branch-principal)
+    - [2.1.2. O job `upsert_major_version`](#212-o-job-upsert_major_version)
+  - [2.2. Workflow de criação de pré-release](#22-workflow-de-criação-de-pré-release)
+    - [2.2.1. Customizando nomes de branches para gerar as versões](#221-customizando-nomes-de-branches-para-gerar-as-versões)
+    - [2.2.2. Usando mais de um nome de branch para gerar as versões](#222-usando-mais-de-um-nome-de-branch-para-gerar-as-versões)
+  - [2.3. Usando o prefixo `v` para as versões](#23-usando-o-prefixo-v-para-as-versões)
+  - [2.4. Customizando o nome da release](#24-customizando-o-nome-da-release)
+  - [2.5. Adicionando um prefixo ao nome da release](#25-adicionando-um-prefixo-ao-nome-da-release)
+- [3. Contato](#3-contato)
+- [4. License](#4-license)
 
-## Instalação
+## 1. Instalação
 
 Copie os arquivos `create-pre-release.yml` e `create-release.yml` do diretório `.github/workflows` para um diretório de mesmo nome na raiz do seu projeto. Isso é tudo!
 
-## Uso
+## 2. Uso
 
 Há dois workflows disponíveis para você usar: o de **criação de release** e o de **criação de pré-release**. Você pode optar por usar apenas o workflow de criação de release ou combiná-lo com o workflow de criação de pré-release.
 
-### Workflow de criação de release
+### 2.1. Workflow de criação de release
 
 ```yml
 name: Release
@@ -56,60 +57,45 @@ Essa é a forma mais básica de uso desse workflow. Ele será disparado sempre q
 3. _Commits_ que iniciam com `fix:` geram novas versões _patch_ do código (por exemplo, de `0.1.0` para `0.1.1`).
 4. _Commits_ em qualquer outro padrão geram versões _minor_ do cóldigo (por exemplo, de `0.1.0` para `0.2.0`).
 
-#### Usando um nome diferente para a branch principal
+#### 2.1.1. Usando um nome diferente para a branch principal
 
 Por padrão, `main` é considerada como a branch principal, mas, você pode modificar isso por meio do parâmetro `main_branch`:
 
 ```yml
-name: Release
-
-on:
-  push:
-    branches: ["master"]
-
-jobs:
-  create_release:
-    name: Create release
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
-    permissions:
-      contents: write
-    with:
-      main_branch: "master"
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    main_branch: "master"
 ```
 
-#### O job `upsert_major_version`
+#### 2.1.2. O job `upsert_major_version`
 
 No template do arquivo `create-release.yml`, você notará que há um job chamado `upsert_major_version`:
 
 ```yml
 upsert_major_version: # Optional
-    name: Upsert major version
-    needs: create_release
-    permissions:
-      contents: write
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1
-    with:
-      version: ${{ needs.create_release.outputs.version }}
+  name: Upsert major version
+  needs: create_release
+  permissions:
+    contents: write
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/upsert-major-version-template.yml@v1
+  with:
+    version: ${{ needs.create_release.outputs.version }}
 ```
 
 Esse job é opcional e pode ser removido se você quiser. A cada versão de lançamento, ele gera uma tag `v[major_version]` (por exemplo, `v1`) e a mantém atualizada, sempre referenciando a última versão, até que uma nova versão _major_ seja lançada.
 
-### Workflow de criação de pré-release
+### 2.2. Workflow de criação de pré-release
 
 ```yml
-name: Pre-release
-
-on:
-  pull_request:
-    branches: ["main"]
-    types: ["opened", "synchronize", "reopened"]
-
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    permissions:
-      contents: write
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
 ```
 
 Essa é a forma mais básica de uso do workflow de pré-release. Ele será disparado em eventos de _pull request_: na abertura, durante novos commits e na sua reabertura. Cada nova mudança em uma _pull request_ gerará uma versão _release candidate_ (`-rc-<number>`).
@@ -124,7 +110,7 @@ As versões de _release candidate_ são incrementadas a cada nova alteração (p
 
 > Se a branch não corresponder a nenhum dos padrões anteriores, a versão automática de _pré-release_ não será gerada.
 
-#### Customizando nomes de branches para gerar as versões
+#### 2.2.1. Customizando nomes de branches para gerar as versões
 
 Assim como no workflow de criação de release, você também pode informar um nome diferente para a branch principal por meio de `main_branch`. O mesmo vale para branches de feature, release e hotfix:
 
@@ -132,45 +118,118 @@ Assim como no workflow de criação de release, você também pode informar um n
 2. Para gerar versões _pacth_, o workflow procurará por branches que correspondam ao padrão do parâmetro `hotfix_branches`. Se o parâmetro não for informado, o valor `hotfix` será considerado como nome padrão.
 
 ```yml
-name: Pre-release
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    main_branch: "main"
+    feature_branches: "feature"
+    release_branches: "release"
+    hotfix_branches: "hotfix"
+```
 
-on:
-  pull_request:
-    branches: ["main"]
-    types: ["opened", "synchronize", "reopened"]
+#### 2.2.2. Usando mais de um nome de branch para gerar as versões
 
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    permissions:
-      contents: write
-    with:
-      main_branch: "main"
-      feature_branches: "feature"
-      release_branches: "release"
-      hotfix_branches: "hotfix"
+Por fim, você também pode usar mais de um nome de branch para os parâmetros `feature_branches`, `release_branches` e `hotfix_branches`, caso queira. Por exemplo:
+
+```yml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  with:
+    feature_branches: "feat feature" # aceitará correspondência da branch de origem tanto para 'feat' quanto para 'feature'
+    release_branches: "rel release" # aceitará correspondência da branch de origem tanto para 'rel' quanto para 'release'
+    hotfix_branches: "fix hotfix" # aceitará correspondência da branch de origem tanto para 'fix' quanto para 'hotfix'
 ```
 
-#### Usando mais de um nome de branch para gerar as versões
+### 2.3. Usando o prefixo `v` para as versões
 
-Por fim, você também pode usar mais de um nome de branch para os parâmetros `feature_branches`, `release_branches` e `hotfix_branches`, caso queira. Por exemplo:
+Algumas ferramentas, como o Github, sugerem o uso de versões que comecem com `v` como, por exemplo, `v1.0.0`. Você pode habilitar esse comportamento através da flag `use_v_prefix`:
 
+**Workflow de criação de release**
 ```yml
-jobs:
-  create_release_candidate:
-    name: Create release candidate
-    uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
-    with:
-      feature_branches: "feat feature" # aceitará correspondência da branch de origem tanto para 'feat' quanto para 'feature'
-      release_branches: "rel release" # aceitará correspondência da branch de origem tanto para 'rel' quanto para 'release'
-      hotfix_branches: "fix hotfix" # aceitará correspondência da branch de origem tanto para 'fix' quanto para 'hotfix'
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    use_v_prefix: true
+```
+
+**Workflow de criação de pre release**
+```yml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    use_v_prefix: true
+```
+
+### 2.4. Customizando o nome da release
+
+Por padrão, os nomes das releases geradas recebem o nome usado para gerar a versão. Você pode sobrescrever esse comportamento através da propriedade `release_name`:
+
+**Workflow de criação de release**
+```yml
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name: "My Amazing Release"
 ```
 
-## Contato
+**Workflow de criação de pre release**
+```yml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name: "My Amazing Release"
+```
+
+Com essa propriedade, todas as releases criadas receberão o nome "My Amazing Release" ao invés do nome da versão.
+
+### 2.5. Adicionando um prefixo ao nome da release
+
+Você também pode definir um prefixo a ser adotado no nome da release. Isso é útil em casos que você ainda deseja manter a versão gerada no nome da release, mas quiser adicionar um prefixo de nome de sua escolha. Isso pode ser obtido por meio da propriedade `release_name_prefix`:
+
+**Workflow de criação de release**
+```yml
+create_release:
+  name: Create release
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name_prefix: "Github"
+```
+
+**Workflow de criação de pre release**
+```yml
+create_release_candidate:
+  name: Create release candidate
+  uses: davidsonbrsilva/versioning-workflow/.github/workflows/create-pre-release-template.yml@v1
+  permissions:
+    contents: write
+  with:
+    release_name_prefix: "Github"
+```
+
+Neste exemplo, as releases criadas seguirão o padrão "Github <major>.<minor>.<patch>", como em "Github 1.0.0".
+
+## 3. Contato
 
 Para dúvidas ou sugestões, envie e-mail para <davidsonbruno@outlook.com>.
 
-## License
+## 4. License
 
 MIT Copyright (c) 2024 Davidson Bruno
diff --git a/actions/release-versioning/release-versioning.sh b/actions/release-versioning/release-versioning.sh
index b9d7063..230d0f3 100755
--- a/actions/release-versioning/release-versioning.sh
+++ b/actions/release-versioning/release-versioning.sh
@@ -36,7 +36,7 @@ is_fix() {
 }
 
 is_minor_change() {
-  [[ $(is_in_branches_list "${2[@]}" "${1}") || $(is_in_branches_list "${3[@]}" "${1}") ]]
+  is_in_branches_list "${2}" "${1}" || is_in_branches_list "${3}" "${1}"
 }
 
 contains() {
@@ -93,7 +93,7 @@ do_minor_change() {
   exit 0
 }
 
-check_pull_request_breaking_change() {
+check_pull_request_for_breaking_change() {
   breaking_change_count=$(git log --format=%B ${1}...${2} | grep -c "^BREAKING CHANGE:.*$|^.*[^[:space:]]+!:.*$")
   if [[ "${breaking_change_count}" -gt 0 ]]; then
     major_version="${3}"
@@ -120,25 +120,25 @@ check_pull_request_for_first_release() {
 }
 
 check_pull_request_for_minor_changes() {
-  local feature_branches=("${2[@]}")
+  local feature_branches=("${2}")
 
-  if is_missing "${2}"; then
+  if is_missing "${feature_branches}"; then
     feature_branches=("feature")
     printf "Feature branch names not found. Using default value: feature.\n"
   fi
 
-  local release_branches=("${3[@]}")
+  local release_branches=("${3}")
 
-  if is_missing "${3}"; then
+  if is_missing "${release_branches}"; then
     release_branches=("release")
     printf "Release branch names not found. Using default value: release.\n"
   fi
 
   if is_minor_change "${1}" "${feature_branches}" "${release_branches}"; then
-    local minor_version="${4}"
+    local minor_version="${5}"
     minor_version=$((minor_version + 1))
 
-    local new_tag="${4}.${5}.0"
+    local new_tag="${4}.${minor_version}.0"
     printf "version=%s" "${new_tag}" >> "${GITHUB_OUTPUT}"
     printf "New generated version: %s.\n" "${new_tag}"
     exit 0
@@ -146,18 +146,18 @@ check_pull_request_for_minor_changes() {
 }
 
 check_pull_request_for_patch_changes() {
-  local hotfix_branches=("${2[@]}")
+  local hotfix_branches=("${2}")
 
   if is_missing "${2}"; then
     hotfix_branches=("hotfix")
     printf "Hotfix branch names not found. Using default value: hotfix.\n"
   fi
 
-  if $(is_in_branches_list "${hotfix_branches[@]}" "${1}"); then
+  if is_in_branches_list "${hotfix_branches}" "${1}"; then
     local patch_version="${5}"
     patch_version=$((patch_version + 1))
 
-    local new_tag="${4}.${5}.${patch_version}"
+    local new_tag="${3}.${4}.${patch_version}"
     printf "version=%s" "${new_tag}" >> "${GITHUB_OUTPUT}"
     printf "New generated version: %s.\n" "${new_tag}"
     exit 0
@@ -165,8 +165,8 @@ check_pull_request_for_patch_changes() {
 }
 
 is_in_branches_list() {
-  local branches_list=("${1}")
-  local is_feature_branch=false
+  local branches_list_string=("${1}")
+  read -ra branches_list <<< "${branches_list_string}"
 
   for i in "${branches_list[@]}"; do
     if contains "${2}" "${i}"; then
@@ -206,12 +206,12 @@ get_version() {
     missing_commit_sha=true
   fi
 
-  if [[ "${missing_commit_sha}" && $(is_missing "${COMMIT_MESSAGE}") ]]; then
+  if [[ "${missing_commit_sha}" == true && $(is_missing "${COMMIT_MESSAGE}") ]]; then
     printf "You need to inform 'HEAD_COMMIT' and 'BASE_COMMIT' or inform 'COMMIT_MESSAGE' to proceed.\n"
     exit 1
   fi
 
-  if [[ "${missing_commit_sha}" ]]; then
+  if [[ "${missing_commit_sha}" == true ]]; then
     check_commit_for_breaking_change "${COMMIT_MESSAGE}" "${major_version}"
     check_commit_for_first_release "${COMMIT_MESSAGE}" "${major_version}"
     check_commit_for_patch_change "${COMMIT_MESSAGE}" "${major_version}" "${minor_version}" "${patch_version}"