编程与软件工程nvie.com编辑精选
十年后再看《成功的 Git 分支模型》
A note of reflection after 10 years of “A successful Git branching model”
2010 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Vincent Driessen 2010 年那篇著名的 Gitflow 分支模型文章的页面（master/develop/feature/release/hotfix 分支体系），作者在 2020 年于文首加了一段十年反思，承认这套模型对多数团队来说过于复杂，如今他更推荐更简单的工作流。它既是 Gitflow 的经典原始出处，也记录了作者本人对它的修正。
为什么经久不衰：它是最具影响力的 Git 工作流文章之一，而作者十年后的自我反思让这篇"经典"同时成为理解 Gitflow 为何被主干开发等更简方案取代的起点。
HN 评论精选
Gitflow 过于复杂，团队转向更简单的主干开发。
我试着在团队里用 Gitflow，但对我来说太复杂了。我们最终改用主干开发（TBD），我和团队都觉得简单得多。
umvi查看英文原文
I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler. [1] https://trunkbaseddevelopment.com/
为了掌控部署内容与时机，团队从 Gitflow 转向基于发布的分支策略。
我们从 gitflow 起步，但团队最终采用了基于发布的分支体系，因为持续集成各种功能让我们对部署什么、何时部署失去了控制。最常见流程是：开发者从 master 拉功能分支；功能在某个时点归入某个发布，发布分支从 master 拉出；开发者把功能分支以 PR 提交到发布分支；部署时发布分支再合并回 master。
keithnz查看英文原文
We started with gitflow, but our team ended up going with a Release based branching system as the constant integration of various features ended up giving less control on what to deploy and when. Most common scenario... Devs create feature branches from master Features will be targeted to a release at some point, Release branch gets taken from master Devs PR feature branches to the release branch Release branch merges back to master on deployment.
新手提问：直接在 master 上 PR 加 tag 发布的简单流程是否有名、是否可行。
看评论我发现自己是个 Git 新手（没怎么参与开源，也不知道"gitflow"这回事），请原谅我的幼稚问题。那这种简单流程如何：开发者在 master 之上提 PR（自己负责 rebase，PR 必须通过集成测试），管理员负责合并、维护线性历史，发布只是在 master 上打 tag。这套流程有名字吗？有什么问题吗？
yodsanklai查看英文原文
Reading the comments, I realize I'm a git neophyte (limited experience working on some open source software, didn't know "gitflow" was a thing) so excuse me for my naive question. But what about this simple workflow. Developers submit PR on top of a master branch (developer is in charge of rebasing, PR must pass integration test). Administrator is in charge of merging, maintains a linear history. Releases are just tags on master. Has this workflow a name? anything wrong with it?
指出作者配套开发了 git-flow 工具，并给出相关讨论线索。
作者还开发了 git-flow——一套帮助管理这个工作流的扩展工具，并附上了多个相关讨论的链接。
nixme查看英文原文
The author also developed git-flow, a set of extensions to help manage this workflow: http://github.com/nvie/gitflow Related discussions: - Why aren't you using git-flow? http://news.ycombinator.com/item?id=1617425 - Ask HN: What's your dev teams git multi-environment setup workflow like? http://news.ycombinator.com/item?id=1738934 - Our Git Workflow: Private Development, Public Releases (at Braintree): http://news.ycombinator.com/item?id=1611667 - My Git Workflow (Michael Ivey): http://news.ycombinator.com/item?id=441670 - My Common Git Workflow (Yehuda Katz): http://news.ycombinator.com/item?id=1343753 - Git Workflow for Agile Teams: http://news.ycombinator.com/item?id=624319
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选