2024年10月29日 (二) 08:39的版本

git-flow源于2010年一篇A successful Git branching model的文章^[1]，在这10年间被很多团队采用并成为了一个事实上的“标准做法”。^[2]

主分支

在这种模型下，git仓库中有两个分支是一直存在的：

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.

origin/master(或者main)：这个分支上的最新代码永远是production-ready的
origin/develop：这个分支上的代码永远是下一个发布的最新的交付代码()。也可以称为“集成分支”，用于进行每日构建（nightly builds）

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master. 当develop分支上的代码达到了上线的标准之后，这些改动就会merge回master分支，并打上release版本号的标签。合并代码到master也就意味着新的产品发布，可以使用web hook来自动进行发布过程：每当master分支有commit的时候自动进行编译、发布等操作发布到生产环境。

辅助分支

feature分支

release分支

hotfix分支

↑ https://nvie.com/posts/a-successful-git-branching-model/
↑ 作者自己在2020年做了补充说明，认为10年来发生了一些变化，使用Git开发已经成为潮流且更多的应用在向Web APP方向发展。Web应用跟其他的项目有一个比较大的区别就是：Web应用通常持续集成，有问题通常会直接修复了发布而不会回退，不需要同时支持多个版本。这种情况下，作者建议使用更简单的方式如GitHub-flow代替。但同时，作者认为git-flow仍然很好的适用于以下的场景：构建多版本应用（或者说需要同时支持不同的版本）

[1] ttps://nvie.com/posts/a-successful-git-branching-model/

[2] 作者自己在2020年做了补充说明，认为10年来发生了一些变化，使用Git开发已经成为潮流且更多的应用在向Web APP方向发展。Web应用跟其他的项目有一个比较大的区别就是：Web应用通常持续集成，有问题通常会直接修复了发布而不会回退，不需要同时支持多个版本。这种情况下，作者建议使用更简单的方式如GitHub-flow代替。但同时，作者认为git-flow仍然很好的适用于以下的场景：构建多版本应用（或者说需要同时支持不同的版本）

[1]

[2]

@@ 第1行： / 第1行： @@
 git-flow源于2010年一篇A successful Git branching model的文章<ref>https://nvie.com/posts/a-successful-git-branching-model/</ref>，在这10年间被很多团队采用并成为了一个事实上的“标准做法”。<ref>作者自己在2020年做了补充说明，认为10年来发生了一些变化，使用Git开发已经成为潮流且更多的应用在向Web APP方向发展。Web应用跟其他的项目有一个比较大的区别就是：Web应用通常持续集成，有问题通常会直接修复了发布而不会回退，不需要同时支持多个版本。这种情况下，作者建议使用更简单的方式如GitHub-flow代替。但同时，作者认为git-flow仍然很好的适用于以下的场景：构建多版本应用（或者说需要同时支持不同的版本）</ref>
+= 主分支 =
+在这种模型下，git仓库中有两个分支是一直存在的：
+<q>
+We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
+We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.
+</q>
+* origin/master(或者main)：这个分支上的最新代码永远是production-ready的
+* origin/develop：这个分支上的代码永远是下一个发布的最新的交付代码()。也可以称为“集成分支”，用于进行每日构建（nightly builds）
+<q>
+Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.
+</q>
+当develop分支上的代码达到了上线的标准之后，这些改动就会merge回master分支，并打上release版本号的标签。合并代码到master也就意味着新的产品发布，可以使用web hook来自动进行发布过程：每当master分支有commit的时候自动进行编译、发布等操作发布到生产环境。
+= 辅助分支 =
+== feature分支 ==
+== release分支 ==
+== hotfix分支 ==
 [[Category:Git]]
 [[Category:Development]]