[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 请问下目前 Debian 官网的翻译情况是怎样的?




企业开发里面, 我在团队里面, 会经常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


Reply to: