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

[wxsm]

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

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

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

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

[bearzk]

- 提 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]

@bearzk 基本认同

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

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

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

[wweir]

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