Git 工作流问题

[wangxiaoaer]

小团队，大家用 git 协作的时候流程是怎么样的？

我们目前开一个仓库，权限已分配，大家都往一个库里怼，总感觉不太好。

希望了解下目前的主流是什么？ 这样一方面拥抱最佳实践，另一方面当员工离职的时候能够快速融入主流。

[GoLand]

GitHub Flow https://guides.github.com/introduction/flow/ ，简单易理解，好实施。

[wangxiaoaer]

@GoLand #1 每人 fork 一个仓库吗？

[GoLand]

@wangxiaoaer 是的，每人 fork 一个仓库，各自仓库上建 branch，之后往主仓库提交 pull request，合并到主仓库 master 后部署上线就行了。

[vx]

https://mp.weixin.qq.com/s/rM5pE0Na39b33OIwxHKRiw 可以参考一下，以前写的

[wangxiaoaer]

@vx #4 多谢。

[wangxiaoaer]

@GoLand #3 这样会不会导致仓库里面很多重名仓库（虽然在各自名下），explore 的时候很乱？

[GoLand]

@wangxiaoaer 别人 fork 到自己的名下了，你又不用管别人的仓库。

[yEhwG10ZJa83067x]

https://help.github.com/cn/github/collaborating-with-issues-and-pull-requests/github-flow

[lewinlan]

小团队还用 fork ？迷

[wangxiaoaer]

@lewinlan #9 不然呢？

[caviar]

没必要 fork，每个人都在自己的名字下开 branch 就行吧。例如 username/foobar 这类

[doublleft]

@wangxiaoaer #10 开分支 然后 rebase 呗，一天 10 个迭代，日清 20 个 bug 常事，难道每次都要 fork->MR 么

[GeruzoniAnsasu]

为什么往一个库里怼不好？ 又不是往一个分支怼

[undef404]

github flow 里没说要 fork repo 啊?

[wangxiaoaer]

@undef404 #14 是的，我刚开始下意识一位 PR 是跨库的，现在看来 PR 也可以在同一个库上面操作。

那现在的问题就是 在同一个库中，权限的控制了，比如 master 不能提交，有权限的人员可以接受、检查 pr 并合并到 master 分支，这个我需要去查一查

[weixiangzhe]

gitlab flow 吧 简单点

[weixiangzhe]

git flow 好多东西用不上，release 分支啥的基本用不到， 结我们现在是 gitlab flow 加点 feature 和 hotfix 分支

[aabbcc112233]

小团队整那么复杂干啥

[wangxiaoaer]

@aabbcc112233 #18 希望组员得到锻炼，防止他们跟时代脱节，否则离职找工作的时候发现别人都机械化了，自己还是拿个镰刀挥舞，无所适从。

[aabbcc112233]

@wangxiaoaer 小公司要的就是机动性，没必要用大公司那一套。在什么位置就要做什么样的事，照搬可能带来恶果。当然我不是在否定大公司的做法，是要有选择性的使用。

[cedoo22]

@wangxiaoaer 新来的公司还在用 svn 。。。。8 、9 个人的团队，SVN 都当文件共享服务器在用。。

[adajoy]

@GoLand github flow 上是先部署，生产上验证没问题以后再合 master 。这样就有问题吧？ 1. 部署和合并间隔过久？ 2.多个 feature 如何处理？

[GoLand]

@adajoy 可以调整啊。branch 可以部署 staging 之类的环境，验证没问题再合进 master，一般合进 master 之后才上 prod

[Mithril]

可以参考 Git Flow 。
本质上就是保护主线，确保每次在主线上的提交都是通过 PR 进来的，Review 和 CI 过的。
至于你 PR 是跨库提进来的，还是跨分支进来的都无所谓。
实际上根据团队情况灵活应对就行了。
缺点就是提 PR 的人需要根据情况不停解决 Merge Conflict 。但是这个问题是没法避免的，SVN 还是 Mercurial 还是什么其他的 flow 都没办法解决。只要多人开发就总会有冲突需要解决的。

[wulin]

一开始试验过每个人 fork 后再建分支，实践过程中发现太麻烦了
改成在主仓库建不同分支，master 只接受合并不可提交
所有冲突全部拒绝，个人本地 pull 最新代码处理好了冲突再提交，比较适合几个人的小团队。

[sarices]

小团队就不要 fork 了，没必要，浪费时间，锁定 master 分支就好

[tsaohai]

master 的 policy 设置好，CI 配好，每个人自己开分支发 PR 就可以了。

[gesse]

推荐阮一峰的一篇文章吧

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

[frankkai]

gitflow 3 人团队 2 年实践经验 感觉良好

https://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html

[frankkai]

功能起 feature 、发布起 release 、改 bug 起 hotfix
线上环境 master 、测试环境一个、拟生产环境一个
目前没遇到太大的问题 感觉还行

[GeruzoniAnsasu]

我们目前的实践（ gitlab EE ）：
- protected: master 、R-*
- 开发分支随便开，命名要求由 ci 维护者制定，但不做特殊要求。这条的意思是，我可以写前端 check 只在 fe/*分支上跑，那么自然所有的前端 feature 都需要带 fe/前缀
- 设置自动发布环境的 CI，T-* 分支会自动执行发布脚本发布到测试环境，意味着你想要做前后端集成测试，必须把 fe/*分支和 be/*分支都 merge 到一个 T-* 上，由于 T-*分支不设保护，所以任何人都能进行 merge 操作，方便前后端联调
- 规定 R-*和 master 分支只允许从 T-*分支合并，由于分支受保护，因此仅有 maintainer 可以合并，他们可以拒绝不合规的 MR;同时这些 MR 信息必须使用模板，填写相关看板任务并通过 check list
- master 会集中所有主线修改，所有 feature 和修复优先进入 master 。当某个迭代周期结束后，产生该迭代的 release 分支 R-*，并且打上版本 tag 。 R-*分支只接受与该期迭代相关的修改 MR，如 bug 修复，该迭代结束日暂时没做完 delay 掉的 feature 等
- T-*分支的发布使用测试私钥签名，R-*分支使用生产私钥签名（与产品 license 相关）


其实只要用得熟练小团队也可以很完善很自动。一开始这个组三四个人的时候只有 master 、T-*、开发分支，现在全组大概 30 个人，也基本还是沿用以前的流程

[djoiwhud]

你可能是需要多开工程，而不是 fork pr 。小于 100 人的公司完全不需要 fork pr 流程。

[Erroad]

一般的团队感觉没有多库的必要，而且这种东西每个公司都不太一样，去了现学一会儿也就上手，有啥脱节不脱节的

[ClericPy]

以前一直走的老的 git flow, 就是单独项目开仓库, 功能分支自己 rebase 最后提 pr 然后等 review 再合并后面自动走 CI

然后去年突然看到楼主说的这种, 而且还好多文章 diss 我用过的那种, 到处充斥着 "时代变了" 的气息... 那些文章说的其实也是很有道理, 也是所有项目都在一个仓库, 然后开分支, 好处很明显是真的, 一次 make 全家受益

老了唉

[hhyvs111]

开分支就好了，master 只合入

[gbin]

#3 说得对，可以参考 Angular 的开发 flow