HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nvie
gitflow
Shell2010–2024
nvie / gitflow · Archived

gitflow

Git extensions to provide high-level repository operations for Vincent Driessen's branching model.

28Distinct people
29Mentions
3Explicit recommenders
26.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Git extensions to provide high-level repository operations for Vincent Driessen's branching model.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I cannot imagine attending a hackathon without a branching strategy. It may be out of touch for some beginners but I highly recommend Nvie's GitFlow…

Swelly used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:01:28 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year29 dated mentions

Observed mentions: 2010-10-24 17:39:04 UTC to 2024-01-15 10:41:09 UTC.

02462010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC505
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC505
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC606
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC606
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Important ⚠️ git-flow has moved to git-flow-next! This repository is no longer maintained. The wonderful team at Tower has created git-flow-next — a modern, fully customizable evolution of git-flow, built on a generic branch dependency model. It’s fully backward compatible with git-flow, open source, and actively maintained. Get started with git-flow-next: Website: https://git-flow.sh GitHub: https://github.com/gittower/git-flow-next Evolution Story: Read about the journey from git-flow → git-flow-avh → git-flow-next in their blog post Why git-flow-next? git-flow-next builds upon the foundation laid by the original git-flow, offering: Full customization of branch names and workflow Modern implementation with active maintenance Backward compatibility with existing git-flow workflows Upcoming features like stacked branches and topic branch syncing Thank you ❤️ To everyone who has used, contributed to, and supported git-flow over the past 15+ years — thank you! Your feedback, contributions, and adoption made git-flow one of the most widely-used Git workflow tools. Special thanks to Peter van der Does for maintaining git-flow-avh, and to the folks at Tower for carrying the torch forward with git-flow-next. (Below, you’ll find the original documentation for historical reference.) git-flow A collection of Git extensions to provide high-level repository operations for Vincent Driessen's branching model. Getting started For the best introduction to get started with git flow, please read Jeff Kreeftmeijer's blog post: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ Or have a look at one of these screen casts: How to use a scalable Git branching model called git-flow (by Build a Module) A short introduction to git-flow (by Mark Derricutt) On the path with git-flow (by Dave Bock) Installing git-flow See the Wiki for up-to-date Installation Instructions. Integration with your shell For those who use the Bash or ZSH shell, please check out the excellent work on the git-flow-completion project by bobthecow. It offers tab-completion for all git-flow subcommands and branch names. FAQ See the FAQ section of the project Wiki. License terms git-flow is published under the liberal terms of the BSD License, see the LICENSE file. Although the BSD License does not require you to share any modifications you make to the source code, you are very much encouraged and invited to contribute back your modifications to the community, preferably in a Github fork, of course. Initialization To initialize a new repo with the basic branch structure, use: git flow init [-d] This will then interactively prompt you with some questions on which branches you would like to use as development and production branches, and how you would like your prefixes be named. You may simply press Return on any of those questions to accept the (sane) default suggestions. The -d flag will accept all defaults. Creating feature/release/hotfix/support branches To list/start/finish feature branches, use: git flow feature git flow feature start <name> [<base>] git flow feature finish <name> For feature branches, the <base> arg must be a commit on develop. To push/pull a feature branch to the remote repository, use: git flow feature publish <name> git flow feature pull <remote> <name> To list/start/finish release branches, use: git flow release git flow release start <release> [<base>] git flow release finish <release> For release branches, the <base> arg must be a commit on develop. To list/start/finish hotfix branches, use: git flow hotfix git flow hotfix start <release> [<base>] git flow hotfix finish <release> For hotfix branches, the <base> arg must be a commit on master. To list/start support branches, use: git flow support git flow support start <release> <base> For support branches, the <base> arg must be a commit on master.
Read the full README on GitHub

What Hacker News says

1 sources
`git push -f` and solipsistic shared reality; when you `push -f` everyone gets to vote on what chain of commit hashes is the real ${orgname}/${reponame}//${branch} There is no formal consensus mechanism beyond push permission in git itself; and so what would be regressive centralization of technically decentralized [git] in order to enforce directory-level permissions like e.g. CODEOWNERS is actually necessary for quality control. Eventually, Github and Gitlab integrated code review like ReviewBoard and Gerrit (instead of mailing list patchbombs and quilt); and code review approval from zero one or more authorized reviewers is now an optional necessary precondition for merging to a git branch as a social construct. DevSecOps says, Pull Requests (or Merge Requests) are merged only when (1) all of the automated tests pass; and (2) enough n
Read the rest
ecessary reviewers have indicated approval. Git doesn't tell you when it's necessary to have full test coverage and manual infosec review in development cycles that produce releases, and neither do Pull Requests. https://westurner.github.io/hnlog/#comment-19552164 ctrl-f hubflow It looks like datasift's gitflow/hubflow docs are 404'ing, but the original nvie blog post [1] has the Git branching workflow diagrams; which the wpsharks/hubflow fork [3] of datasift/gitflow fork [2] of gitflow [1]has a copy of in the README: [1] https://github.com/nvie/gitflow [2] https://github.com/datasift/gitflow [3] https://github.com/wpsharks/hubflow?tab=readme-ov-file https://learngitbranching.js.org/ is still a great resource, and it could work on mobile devices. The math of VCS deltas and mutable and immutable content-addressed DAG nodes identified by 2^n bits describing repo/$((2*inf)) bits ; >> "ugit – Learn Git Internals by Building Git in Python" https://www.leshenko.net/p/ugit/ SLSA.dev is a social construct atop e.g. git, which is really a low-level purpose-built tool and Perl and now Python porcelain. jj (jujutsu) is a git-compatible VCS CLI: https://github.com/martinvonz/jj "Ask HN: Best Git workflow for small teams" (2016) https://news.ycombinator.com/item?id=12941997 How much social construct atop git is necessary for e.g. the CPython project? Python Devguide > Getting Started > [ Git bootcamp and cheat sheet , Lifecycle of a pull request ] https://devguide.python.org/getting-started/ Python Devguide > Development workflow > Development cycle > Branches: https://devguide.python.org/developer-workflow/development-c... : > [ In-development (main) branch, Maintenance branches, Security branches, End-of-life branches ] Git branches have lifecycles.
In Git Branches as a Social Construct

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.