我分享一下我们公司的协作。尽管我们都有写权限，但是我们还是采用 fork/pull -> PR -> merge 的方式协助，没有直接向 repo 写入代码，主要有二： 一是 PR 会触发 CI 二是 需要 reviewe 如果是 bug 或新功能 commit 都要带 issue#，合并意味着自动打包测试版本。
本地的分支合并之后就会删除，我们只看主线上的日志。 -Never rainysia <rainy...@gmail.com> 于2019年9月1日周日 下午6:13写道： > > 企业开发里面, 我在团队里面, 会经常review团队成员的代码, 有时候有些项目同时有三队人(中国, 美国, 印度团队) 在开发, > 如果只到最后一步才进行merge 远端的主分支, 冲突的解决那真的是难上加难. > > 对于开发人员来讲, 只有当时的开发人员才最熟悉他所更改的代码模块, 所以及早的处理掉和上游分支的冲突, 才是最好的, > 同时也可以方便的让我回溯这位开发人员是否在merge的时候进行了错误的解决冲突. > rebase 对企业开发不是一个好的流程, 但是对于开源项目接受第三方的PR的时候, 保持主分支 commit log的清晰, 也是很有必要的. > > On Sun, Sep 1, 2019 at 6:00 PM Faris Xiao <atzli...@yeah.net> wrote: > >> >> 在 2019/9/1 下午5:37, Shengjing Zhu 写道: >> > On Sun, Sep 1, 2019 at 2:08 AM Faris Xiao <atzli...@yeah.net> wrote: >> >> 这里设计到一个工作流程标准化和工作习惯的问题。其它的项目，都是用 git pull >> >> 拉取最新代码后再开始工作，唯独这个项目不用 git >> >> pull，需要搞特例，非常不符合标准化工作流程和对所有项目的 git 操作一致性。 >> >> >> > 这个仓库并不特殊，你也可以随时pull master branch，但前提是你理解git的概念，而不是盲目地操作一些命令。 >> 针对我现在遇到的具体问题，Boyuan Yang 的意见，是不用 >> pull。我也尝试按他的意见进行 rebase 等操作，目前还没有达到目标。 >> > >> >> 综上所述，你之前提到的 git fetch 和 git rebase >> >> 两种方案，都不能够很好的解决及时从官网更新，又不产生过多 merge log 的问题。 >> >> >> >> 同时这些操作都是非常麻烦耗时的。你提到的这本书，我也会抽时间看，但估计一时半会解决不了我们目前遇到的问题。要想参与翻译的每一位都成为 >> >> git 使用高手，估计也不现实。 >> >> >> > 对于一般的翻译者，即使提交的Merge >> > >> Request包含“奇怪”的commit，也无妨。因为最后的Merge的人，可以帮忙清理commit。但是如果你想获得直接push的权限，那么你就必须要学会git了。 >> >> 要在开源社区顺利的贡献自己力量，确实需要“学会”git >> 才行。我此次的遇到的具体问题，我刚才还向邮件列表发邮件反馈具体情况。 >> >> 同时欢迎各位 git 大拿给出具体的指导意见。 >> >> > >> -- >> 肖盛文 Faris Xiao >> >>
