git-flow

Initialize it inside an existing Git repository

$ git flow init

$ git flow feature start [feature]

$ git flow feature finish [feature]

$ git flow feature publish [feature]

$ git flow feature pull origin [feature]

git flow subcommand [options]

Examples:
git flow init [-d]
git flow feature start name [base]
git flow release finish version [-s] [-f]

init
    Initializes a new git-flow repository, configuring default branch names and creating `develop`.

feature
    Manages feature branches. Allows starting new features, finishing them (merging into develop), listing, and publishing.

release
    Manages release branches. Facilitates preparing new production releases, including tagging and merging into `main`/`develop`.

hotfix
    Manages hotfix branches for immediate production fixes, branched from `main`/`master`.

support
    Manages long-running support branches for older releases, branched from `main`/`master`.

publish
    Publishes a local git-flow branch (feature, release, hotfix) to the remote repository.

track
    Tracks a git-flow branch (feature, release, hotfix) from the remote repository locally.

version
    Displays the installed git-flow version.

config
    Manages git-flow configuration settings for the repository.

Git-flow is a set of Git extensions that provides high-level repository operations for Vincent Driessen's branching model. This model defines a strict but robust way of managing releases, features, and hotfixes through dedicated branches. It standardizes the workflow around `main` (or `master`) and `develop` branches as core, complemented by `feature` branches for development, `release` branches for preparing new releases, and `hotfix` branches for quick production fixes. Git-flow automates many of the steps involved in this workflow, such as creating, finishing, merging, and deleting these specialized branches, as well as handling tagging. It aims to streamline collaboration and ensure a consistent branching strategy across teams, making complex release cycles more manageable. While opinionated, it's widely adopted for projects requiring predictable and formalized release processes.

• Rigidity: Git-flow implements a very specific and opinionated branching model. While robust, it might be overly complex or restrictive for simpler projects or teams adopting more flexible continuous delivery practices.
• Learning Curve: Teams new to git-flow might require time to understand and adapt to its structured workflow.
• Branch Name Dependence: It relies on specific branch naming conventions (e.g., `feature/`, `release/`, `hotfix/`) which are configured during initialization.

Git-flow defines two main long-lived branches:
master (or main): Holds the official release history, reflecting what's in production.
develop: Integrates new features and prepares for the next release, serving as the branch for ongoing development.

It also uses short-lived, supporting branches for specific purposes:
feature/: For developing new features in isolation, branched from `develop` and merged back into it.
release/: For preparing a new software release, branched from `develop` and merged into both `main` and `develop`.
hotfix/: For quickly patching production issues, branched from `main` and merged into both `main` and `develop`.

The git-flow branching model was first proposed by Vincent Driessen in his 2010 blog post, "A successful Git branching model". This model quickly gained popularity for its clear separation of concerns in development, release preparation, and urgent fixes. The `git-flow` command-line extension, developed by Peter van der Hagen, provides a practical implementation of this model, automating many of its complex steps. Its widespread adoption helped standardize a common approach to branching strategies in Git, especially for projects with distinct release cycles.

git(1), git-branch(1), git-tag(1), git-merge(1)