git-flow AVH Edition 1.1.0

In a previous article I discussed how to use git as a workflow for development. I mentioned the fork I created from the original nvie’s git-flow and today is the release of version 1.1.0 of git-flow AVH Edition.

I have been asked by several people why I created the AVH Edition, instead of contributing to the original fork.
As I was in need of the implementation of hooks and filters in git-flow, I wrote a patch for the original git-flow. After 5 months the patch still wasn’t implemented and I decided to focus my work on creating the git-flow AVH Edition.

While implementing the hooks and filters and improving the patch I had written before, I noticed several parts of the code that could use some improvements. I rewrote several of the internal functions, replaced porcelain functions with plumbing functions. While working on the git-flow AVH Edition, Daniel Dehennin contributed several improvements and bugfixes.

Because of the rewrite we did it seems very likely that the patches for new features and bugfixes we create for the AVH Edition, are not compatible with the original git-flow.


Peter van der Does

  • Bugfix: feature finish does double merge when using squash option.

  • Add the ability to keep/delete local/remote branches on finish.
    When finishing a release/hotfix/feature you now can keep/delete the
    local/remote release/hotfix/feature branch.

  • New command: git flow release branch
    With this command you can directly release a given branch. There is no need
    to start a new release and finish it. You can not use this command on the
    git-flow branches feature/hotfix/release/support.

  • Do not display object fetch summary if flag was not set.
    Thanks to Daniel Dehennin.

  • Bugfix: Checking if branch exists will fail for remote branches.

  • Make die output consistent for each die case.

  • Bugfix: When running git flow init an error message pops up.

  • Show correct help for subactions.
    When requesting help with -h for the subactions, the help would show the
    incorrect command line.

  • Support reading the tag message from a file in release/hotfix finish.
    Add the option -f,–messagefile to release and hotfix finish. Thanks to
    Steve Streeting for the original coding.

  • Bugfix: git_current_branch fails for git prior 1.7.10.
    git symbolic-ref does not have the –short option prior to version 1.7.10.
    Bug found by Daniel Dehennin.

  • Clean up code.
    Remove all porcelain commands.
    Refactor code.

  • Improve the back-merge functionality.
    Adds an command line option (-b), which the user can utilize if the user
    doesn’t want to back-merge but rather merge the release branch into

  • Add the sub-action delete to sub-commands feature, release and hotfix.
    The sub-commands feature, release and hotfix now have a new sub-action,
    delete. With that action you can delete the branches, locally and remote.
    The action has two options, -f and -r. With -f you can force the deletion,
    even when the to be deleted branch was not merged yet. With -r the remote
    branch will also be deleted.

Daniel Dehennin

  • Bugfix: release/feature/hotfix start -F fails.
    Usage of positional parameters requires to eval ${FLAGS_ARGV}. The “eval set”
    in function call does not propagate to the caller.

  • Accept tags as base for hotfix/release/support start.
    Commit pointed by tags are reachable with ^0[1].

  • Check for parameter existence for branch and tag existence helpers.

  • Do not finish hotfixes if they have no commits.
    A hotfix branch must have some commits and be ahead of master.

  • Bugfix: When running git flow version an error message pops up.

  • Reorder fetch and sanity checks.
    When a user requests a fetch for git flow {feature|hotfix|support} start, do
    this before some sanity checks to avoid any conflict in branch names
    and/or version.

  • Fix flag test in cmd_delete().

Myke Hines

  • Feature and Release squashing options.
    This allows a -S option to both feature and releasing finishing actions so
    that developers can squash commits into one large one.

Peter Ragone

  • Add init to git-flow-{feature,release,hotfix,support}.
    Fixes the relatively minor issue where ‘git flow subcommand help’
    gives “Not a gitflow-enabled repo yet”.

  • Special thanks to the following individual:
    Gert Van Gool

If you want to use git-flow, and I don’t know why you wouldn’t, download it from github, follow the installation instructions and start using it. And while you are using it contribute to the git-flow AVH Edition. Check the wiki on how you can help improve git-flow AVH Edition.

This article is filed under the categories Software » git » git-flow and has the following tag associated with it: .
  • Why don’t you rename, for example to git-reflow or git-work or git-workflow or git-wf or git-yaflow ? If your fork is still compatible, you might add a symlink from git-flow to git-YOURS upon installation, to maintain compatibility with scripts. That way, there wouldn’t be discussions like or, and you’d have a better name than “git-flow AVH Edition” (though this is subjective ;-] ).

    Btw, it’s about the same mariadb does: Maintaining compatibility to mysql, but stil being a separate, distinctive project.

    • Peter

      Well I started out by submitting patches to the original project, but after months of those patches not being implemented (and I believe they still aren’t implemented), my fork just took of. And like you say, I’m not renaming to maintain compatibility with existing scripts. The discussion about the Homebrew Formula would still be there if I renamed the project and used a symlink.

  • I also wondered why not to rename AVH Edition to avoid confusion with the original git-flow. It’s tricky, indeed.

    Currently, git-flow names an approach/a model to Git branching as well as original, reference if you like, implementation of related Git extensions.
    It is important to distinguish the two names.

    In my opinion, every new implementation or significant fork or git-flow flavour should be renamed to avoid confusion (also, to allow use of original git-flow side-by-side other flavours).
    Naming, however, should indicate relation to git-flow model.

    For example, HubFlow guys decided, sensibly, to use different name: git hf.

    AVH Edition of git-flow could use: git vhf