这是一个创建于 2050 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果每个开发人员一个以自己名字命名的开发分支，还有一个 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
janus77 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 这是没错的。
|
|
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 的工作流来看 |
|
15
CFM880 2019-04-12 07:49:14 +08:00
这种 git 工作流，坚决不手敲命令，sourcetree 的 git 工作流很好解决了这问题。如果工作流操作规范没有必要保留 release featue hotfix，操作不规范，就有保留分支必要
|
 |
16
bunnyblueair 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