关于 Github branch 使用方式的小疑惑

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2482 天前的主题，其中的信息可能已经有所发展或是发生改变。

众所周知，Github 可以设置一个 Default branch，通常就是 master，它会跟很多东西绑定上，比如：

贡献
代码 merge 时自动关闭 issue
PR 的默认 branch

看第二点的话，这条 (default) branch 的性质可以坐实为 release 无疑了。但是第三点又有点冲突，别人给一个 repo 提交 PR 时的默认 branch 也是它，那么这又有点 dev branch 的意思。（不知道这里能不能自定义？）

另外，很早之前就发现，vuejs 系的项目很多都在 default branch 挂了个 dev 的名字。而很多其它开源项目是用它来做 release 分支的。所以，正确的姿势到底是什么呢？

3 条回复 • 2018-02-08 06:33:59 +08:00

bearzk

2018-02-07 18:54:27 +08:00

- 提 PR 时候可以选要 merge 的 target branch, 我一般 default 是 develop branch
- merge 发生时, 如果在 commit message 里有 fix #issue_id 才会关闭相应 issue. 关闭了的 issue 也并不绝对代表相应的代码已经 release 了
- master 应该用作 release branch, 就是应该是 production ready 的
- 如果还没有试过建议使用 gitflow, 算是一种 git best practice 吧

希望对你有帮助 :)

veightz

2018-02-07 23:42:51 +08:00

@bearzk 基本认同

日常我以 Git Flow 为主, 当较大 feature 进 develop 的时候，以及 develop 合并到 master 的时候会发起个 PR （ gitlab 是 merge request，似乎名字更贴切）。有个 request 的，有个比较合适的地方进行记录相关的说明和 review 的观点。

跨团队及更大跨度的开发时，才会走 PR 这一套，一般都会问对方我从什么分支开发比较合适，从哪儿开，就合并回什么分支。

开源协作项目，一般我会从 master 上单开 release 分支或者标记 tag。确实有点 dev branch 的意思。。不过一般而言，既然 accept，基本是认为开发完成，测试 OK 的。。

wweir

2018-02-08 06:33:59 +08:00 via Android

github 有自己推荐的 workflow，名字叫 github-flow，里面有对各个分支的具体定义