企业开发里面, 我在团队里面, 会经常review团队成员的代码, 有时候有些项目同时有三队人(中国, 美国, 印度团队) 在开发, 如果只到最后一步才进行merge 远端的主分支, 冲突的解决那真的是难上加难.对于开发人员来讲, 只有当时的开发人员才最熟悉他所更改的代码模块, 所以及早的处理掉和上游分支的冲突, 才是最好的, 同时也可以方便的让我回溯这位开发人员是否在merge的时候进行了错误的解决冲突.rebase 对企业开发不是一个好的流程, 但是对于开源项目接受第三方的PR的时候, 保持主分支 commit log的清晰, 也是很有必要的.On Sun, Sep 1, 2019 at 6:00 PM Faris Xiao <atzlinux@yeah.net> wrote:
在 2019/9/1 下午5:37, Shengjing Zhu 写道:
> On Sun, Sep 1, 2019 at 2:08 AM Faris Xiao <atzlinux@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