这是一个创建于 2453 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果每个开发人员一个以自己名字命名的开发分支，还有一个 dev 测试分支，有必要同时保留 master 和 release 吗，
 | 1 boris1993 2019-04-11 19:48:39 +08:00 via Android release 用 tag 管就够了吧 |
 | 2 2kCS5c0b0ITXE5k2 2019-04-11 19:50:44 +08:00 release 类似公测 dev 是内测 master 是稳定 (个人理解 |
 | 3 rb6221 2019-04-11 20:14:10 +08:00 在你说的这种情况下，我觉得 master 才是测试用的分支使用 master 的代码和 release 的配置、环境这些东西，模拟真正的 release 测试。 如果测试不通过还可以改，测试通过以后再新开分支 or 打 tag 作为 release 使用。 |
 | 4 Mutoo 2019-04-11 20:22:47 +08:00  3 master 是最新稳定版本，release 是对外发布的版本快照， 新开发的 feature 会 merge 到 master 上 而 patch 则 merge 到 release 上 |
 | 5 NicolayShi OP @Mutoo 求解释您这段话的意思，我小白有点不大理解，（掩面哭泣），新功能合并到 master，补丁合并到 release，但是不应最终都合并到和线上保持一致的 master 分支吗，版本快照又怎么理解呢， |
 | 6 xy90321 2019-04-11 22:00:00 +08:00 via iPhone @NicolayShi 在他的描述里和线上一致的是 release 分支。m 打到 release 分支的 hotpatch 最终也会在某一个时间点合并回 master 这是没错的。 |
| /td> | 7 NicolayShi OP @Mutoo 我看公司的代码提交记录是修改都合并到了 release，但是奇怪没有合并到 master 的记录 但是 master 的 log 记录却和 release 的 log 一致，不好意思问老大，所以在这边问了，（掩面哭泣） |
| 8 NicolayShi OP @xy90321 我们好像和您说的一样，但是我不确定，因为我查到 开发人员的分支的修改都会合并到 release，但是 没有 合并到 master 的记录，master 又和 release 的 log 相同，这和您说的 hotpatch 有关吗，不是太理解这个 hotpatch， |
 | 9 shawndev 2019-04-11 22:05:58 +08:00 latest 和 stable 的差别吧。 |
 | 10 gz911122 2019-04-11 23:52:58 +08:00 release 是支持一个新的用于生产环境的发布版本, 允许修正小问题，并为发布版本准备元数据。 https://www.git-tower.com/learn/git/ebook/cn/command-line/advanced-topics/git-flow 可以看下这个 |
| 11 xy90321 2019-04-12 00:07:09 +08:00 |
 | 12 SharkIng 2019-04-12 00:19:09 +08:00 |
 | 13 msg7086 2019-04-12 00:45:29 +08:00 2 master 和 release 分支怎么用应该是贵司自己决定的呀。 比如我司是做产品的，所以旧版代码也要打补丁维护，所以我们有 release-4.1 这样的分支来 backport 补丁。 比如我维护的开源软件，旧版代码一般维护一个版本，所以我有 stable 分支和 oldstable 分支，再老的不维护的版本就打个 tag 解决。 比如我自己写网站的时候，因为只有一台生产和一台 staging，所以 master 推 staging，然后 production 推生产。 不同的环境下做法不一样的。 |
14
CFM880 2019-04-12 07:43:16 +08:00 release 测试开始回归时开的分支，master 线上分支，每个 merge 点都是可编译的分支，且是比较稳定的
release 分支 commit 会比较少，提交比较多，证明测试在前期测试可能不太好。
具体的可以结合 sourcetree 的工作流来看
release 分支 commit 会比较少，提交比较多，证明测试在前期测试可能不太好。
具体的可以结合 sourcetree 的工作流来看
| 15 CFM880 2019-04-12 07:49:14 +08:00 这种 git 工作流，坚决不手敲命令，sourcetree 的 git 工作流很好解决了这问题。如果工作流操作规范没有必要保留 release featue hotfix，操作不规范，就有保留分支必要 |
 | 16 v2zhao 2019-04-12 08:36:53 +08:00 via Android Android aosp 的 master 分支经常编译不过，稳定个 |
 | 17 corningsun 2019-04-12 08:40:05 +08:00 via iPhone 可以参考 gitflow，另外推荐个 ui 客户端，GitKraken，可以清晰地看到各个分支的合并记录 |
 | 18 Biwood 2019-04-12 08:42:38 +08:00 via Android “如果每个开发人员一个以自己名字命名的开发分”，是不是现在很多开发者觉得用 git 特别高大上，但是压根就不知道为什么要用 git。 |
 | 19 Godaigo 2019-04-12 08:47:35 +08:00 via Android @NicolayShi release 是程序发布的 branch 定时从 master 分出来 之后做发布前的最后测试 masrer 就是码农们日常工作时 merge 进去的主分支 当然也是经过一系列自动化测试 基本算是稳定 出了问题也可以 revert. |
 | 20 ThomasZ 2019-04-12 08:51:13 +08:00 release 是发布的稳定版, master 主版本不一定是稳定版或者发布版, master 的版本号始终是最大的, 也是平时开发的那个版本 |
 | 21 Jasonwxy 2019-04-12 08:53:28 +08:00 https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md 之前了解 git-flow 看的一篇文章，可以看看，还是比较容易懂的 |
 | 22 hantsy 2019-04-12 08:58:11 +08:00 一般开源软件，比如 Spring，都是按 GitFlow 类似的流程来管理代码，相对 Github Flow 比较复杂，但能对付复杂的版本发布计划。 GitFlow 最初介绍： https://nvie.com/posts/a-successful-git-branching-model/ 一般小项目，使用 Github Flow 就行了，每个任务开分支，创建 PR，Code review, 并结合 CI 运行测试，没什么大问题，合并到 Master 直接通过 CI 发布。 Github Flow Master 一般代表可以部署的稳定版本，通常会禁用开发人员直接到 Master 提交代码，必须通过分支（在测试运行通过，代码质量达到要求的情况）合并。另外过去的实践中，在一个分布式团队中，都是先 Fork 项目，再在自己的账号下创建分支。 Understanding the GitHub flow： https://guides.github.com/introduction/flow/ |
| 23 hantsy 2019-04-12 09:05:40 +08:00 @NicolayShi “如果每个开发人员一个以自己名字命名的开发分支”，你说的这个方法使用 Git，完全不知道你想干嘛。 GitFlow 分支一般是分类 /issue 描述。 hotfixs/fixes-missing-link-in-readme， 有工具可以协助你命名。 Github Flow 中过去我们使用就是简单的 issueid-issue 描述，或者就是简单的 issue 描述 。 |
| 24 NicolayShi OP |
Select Language