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

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



在 2019-08-30五的 23:48 +0800,atzlinux写道:
> 在我自己的分支上进行 rebase 操作,比较麻烦。如果我有权限在官方git直接
> pull,commit,push的话,就不会存在 merge commit 日志的问题。

Rebase
应该是最优雅的做法,而且在有可视化支持的情况下并不麻烦。变基(rebase)和拣选(cherry-pick)都是维护提交历史的重要工具。对于可视化工具我目
前使用 qgit,但 git 自带的 gitk 和其他第三方的 git-cola 或者 gitg 都是比较好用的工具。

> 这个 merge 日志展示的问题,我下午也在邮件列表里面主动提出,具体请看
> rainysia@gmail.com 和我的邮件,merge
> 日志是否需要保留,这个问题好像业界还没有明确规定。

理论上应该是一个 Merge Request(Pull Request)对应一个 merge commit。对于 rainysia
的邮件所指的应该是最终合并时产生的 commit,而非在你的本地分支上持续不断地拉取并合并而产生许多没有必要的 merge commit
的情况。具体还是请见我上一封邮件的截图。

> 每次在自己的分支上进行工作前,从官方git仓库拉取最新代码后再进行本地修改,这是一种良好的工作习惯。

的确这是很好的习惯,但前提是不要产生多余的 merge commit,而且拉取代码并不意味着必须在本地分支上产生 merge
commit(这是我这封邮件的核心想法;实际上我想说在使用 git 时,请一定不要因为拉取代码而产生 merge
commit),请见我上一封邮件的截图所指出的那些 merge commit。

可以通过提交 Merge Request 之前进行一次 rebase 来避免多余的 merge commit;或者在 webwml
这个大项目来说只要你正在工作的部分没有其他人做了更新的话(在目前的情况下非常不可能出现;即便出现了,也可以每次提交 Merge Request
之前肉眼检查一下,随时 git fetch 并查看提交历史中是否有其他人已经做了可能出现冲突的修改),不在当前分支拉取最新代码直接提交 Merge
Request 也不是大问题(期间可以只做 git fetch 拉取到本地仓库中,而非 git pull 对你正在工作的分支添加没必要存在的 merge
commit;请回忆一下 "git pull == git fetch + git merge"),只要在上次的 Merge Request
被合并后下次工作开始之前把自己本地的分支快进(fast-forward)到上游的 master 分支最新提交上,使两者保持一致就可以了。

> 我看到该项目已经有 83
> 个成员有git写权限了,像这样的项目,没有必要把权限控制得这么严格,会打击大家的工作积极性。

目前我只是项目 Developer 具有推送提交的权限,而非可以赋予他人写权限的 Maintainer/Owner。请联系 webwml 项目的
Maintainer/Owner 以得到写权限。

> 我参加 Debian 中文化的相关工作时间也比较长了,从 05 年的 DR
> 第一版翻译开始,版本控制工具从 cvs 到 svn 到 git,一直都在使用。

每个版本控制系统都有其特性。具体到使用 git 的 webwml 项目来说,保持提交历史的线性或者一次 Merge Request
由进行合并操作的人(而非贡献者自己)产生一个 merge commit 都是比较好的操作。


谢谢,
Boyuan Yang

> 在 2019/8/30 下午10:58, Boyuan Yang 写道:
> > 根据现在的 git 历史可以看出你对 git 的分支理解还不够明晰;如附件截图所示,所有标出的 merge commit 均是没有存在必要的。
> > 
> > 在工作的时候,请不要无故创建没有必要的 merge commit;从仓库的 master HEAD 开始的工作可以直接提交 merge
> > request
> > (pull request)
> > 而无需合并上游最新的提交(这是在不会产生冲突的时候的做法;考虑到当前仓库的内容多而提交密度相对低,遇到冲突几乎是不可能的),我会通过一个统一的
> > merge
> > request 将新的贡献合并或者直接进行拣选(cherry-pick)。如果想让历史更好看一些,请使用 git
> > rebase(变基)操作将你的工作成果“嫁接”到最新的 master HEAD 提交上。
> > 
> > 目前我有时间可以审阅你的贡献并按需合并,所以可以继续走 merge request 的方式进行贡献。如果之后的 merge request
> > 展现出了对工作流更好的理解的话,可以稍后再申请对 webwml 仓库的直接写权限。
> > 
> > 谢谢,
> > Boyuan Yang
> > 
> > 在 2019-08-30五的 16:29 +0800,atzlinux写道:
> > > 既然是 git 的设计初衷,那我在本地分支进行 merge 的时候,还是保留移植日志吧。
> > > 如果在本地分支用如下命令进行移植:
> > > git merge master --squash 
> > > 会把 master 上的文件改动同步到本地分支,但我下次在本地分支进行 commit 的时候,也会把这些文件在本地再次提交,也不合适。
> > > 在 2019/8/30 下午1:49, rainysia 写道:
> > > > git 设计初衷就是为了清晰的记录每次commit, 你的merge也是一个commit. 这样可以快速剥离错误的merge.
> > > > git merge 默认就带了 fast-forward  
> > > > 
> > > > 想要没有merge的commit, 加一个--squash
> > > > 
> > > > 
> > > > On Fri, Aug 30, 2019 at 10:03 AM atzlinux <atzlinux@yeah.net> wrote:
> > > > > 谢谢指导!
> > > > > 这样操作,merge 的时候,会在我本地分支生成一个移植日志,这个日志在我 push 到我的 salsa 分支的时候,会带过去,
> > > > > 我在向官网主分支提出合并请求,并被接受后,也会有这个移植记录。
> > > > > commit 59257d294988d999f955d70b63363ef0cc428846
> > > > > Merge: e698cb88a6f 3c680de4fb9
> > > > > Author: Faris Xiao <atzlinux@163.com>
> > > > > Date:   Thu Aug 29 17:14:57 2019 +0800
> > > > > 
> > > > >     Merge branch 'master' into cnwebwmlmaster
> > > > > 
> > > > > 像这个我在本地的移植记录,最后传递到官网 git 记录里面,感觉没有啥意义,不知道是否需要处理下?
> > > > > 
> > > > > 肖盛文
> > > > > 在 2019/8/30 上午8:59, rainysia 写道:
> > > > > > 这是标准git的PR流. 采用fork->创建分支, 提交Pull Request到主仓库申请合并.
> > > > > > 没有任何问题, 你本地不更新, 需要加一次主仓库作为远程仓库.
> > > > > > 具体如下
> > > > > > 
> > > > > > 1, 增加远程仓库
> > > > > > git remote add upstream git@salsa.debian.org:webmaster-
> > > > > > team/webwml.git
> > > > > > 2, 更新全部仓库的缓存
> > > > > > git remote update -p
> > > > > > 3, 切换到你本地需要拉取最新代码的分支进行合并
> > > > > > git stash && git checkout master && git merge upstream/master
> > > > > > 4, 切回你的分支
> > > > > > git checkout 你自己建的分支
> > > > > > 5, 合并最新代码
> > > > > > git merge master 或者直接放弃3,4步, 直接git merge upstream/master
> > > > > > 6, pop stash
> > > > > > git stash pop
> > > > > > 
> > > > > > 
> > > > > > On Thu, Aug 29, 2019 at 5:10 PM atzlinux <atzlinux@yeah.net>
> > > > > > wrote:
> > > > > > > 我刚刚尝试提交了一个合并请求,麻烦看下。
> > > > > > > 
> > > > > > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/208
> > > > > > > 
> > > > > > > 我现在对 salsa 的 git 仓库分支的协作,还不太熟练。
> > > > > > > 
> > > > > > > 我目前的做法如下:
> > > > > > > 
> > > > > > > 1:将官方 https://salsa.debian.org/webmaster-team/webwml.git 仓库 fork
> > > > > > > 派生了一份到我的用户下,形成:
> > > > > > >  git@salsa.debian.org:atzlinux-guest/webwml.git 仓库。
> > > > > > > 
> > > > > > > 2:将我自己名下的这个仓库 clone 到本地电脑
> > > > > > > 
> > > > > > > 3:对本地 master 分支进行修改提交后 push 到 salsa 我名下的 webwml.git 仓库
> > > > > > > 
> > > > > > > 4:在 salsa 上,提出合并请求。
> > > > > > > 
> > > > > > > 但这样做,会有一个问题,我本地 master 分支不能够及时获取官网仓库最新 git
> > > > > > > 更新,担心翻译了旧文件,也不利用和大家协调翻译工作。
> > > > > > > 
> > > > > > > 不知道大家是否有更好的办法来解决这个问题?
> > > > > > > 
> > > > > > > 谢谢!
> > > > > > > 肖盛文
> > > > > > > 
> > > > > > > 在 2019/8/27 下午11:27, Boyuan Yang 写道:
> > > > > > > > 在 2019-08-27二的 15:09 +0800,atzlinux写道:
> > > > > > > > > 大家好!
> > > > > > > > > 
> > > > > > > > >     我最近辞职,有比较多空闲时间,想参与下 Debian 官网的翻译工作。
> > > > > > > > > 
> > > > > > > > > 请问目前官网翻译的整体情况如何?如何协调中文翻译工作的?
> > > > > > > > > 
> > > > > > > > > 简体中文和繁体中文,目前是在同一个目录中翻译,然后由 系统的 opencc
> > > > > > > > > 自动转换编码吗?
> > > > > > > > > 
> > > > > > > > > 在同一个文件中,可以允许同时出现简体字和繁体字吗?
> > > > > > > > 现在 Debian 的网站除了极少数内容(例如导航栏、底栏)以外,其它绝大多数网页均没有 gettext
> > > > > > > > 化,也就是说不能通过翻译
> > > > > > > PO
> > > > > > > > 文件的方式进行翻译。中文页面和英文页面实际上是两个平行的网页,通过一定的方式检查中文网页内容是否落后于英文页面。当然,所有的
> > > > > > > > PO
> > > > > > > 文档也是需要翻译的。
> > > > > > > > www.debian.org 这个域名下页面所有的源代码均可以在 
> > > > > > > > https://salsa.debian.org/webmaster-team/webwml
> > > > > > > 找到,请先浏览并查看已有翻译是如何运作的。如果需要更新,请提交
> > > > > > > > GitLab 的合并请求。我可以复核并对贡献的新内容进行合并。
> > > > > > > > 
> > > > > > > > 文章中可以混合简体字和繁体字,前提是混合的情况可以被 opencc 识别并转换。推荐至少同一句话内只使用简体字/繁体字。
> > > > > > > > 
> > > > > > > > 在动手之前,请务必阅读 https://www.debian.org/devel/website/
> > > > > > > > 上面的信息,尤其是如何使用
> > > > > > > git 处理 Debian
> > > > > > > > 网页、如何使用 WML 标记语言以及如何保持翻译更新这三篇文章。
> > > > > > > > 
> > > > > > > > 谢谢,
> > > > > > > > Boyuan Yang

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: