（请见信件末尾） 在 2019-09-01日的 02:08 +0800，Faris Xiao写道： > 在 2019/8/31 下午9:34, Boyuan Yang 写道: > > 在 2019-08-31六的 16:18 +0800，Faris Xiao写道： > > > 使用 rebase 操作，非常麻烦！ > > > > > > 要考虑到我在本地有两个分支的情况。 > > > > > > 一个分支 master，用于跟踪官网最新更新； > > > > > > 另外一个分支是 cnwebwmlmaster，用于我向 salsa 我自己 fork > > > 出来的git仓库进行提交，然后再向官网git提交merge请求。 > > > > > > git remote -vvvv > > > cn-webwml git@salsa.debian.org:atzlinux-guest/webwml.git (fetch) > > > cn-webwml git@salsa.debian.org:atzlinux-guest/webwml.git (push) > > > origin https://salsa.debian.org/webmaster-team/webwml.git (fetch) > > > origin https://salsa.debian.org/webmaster-team/webwml.git (push) > > > > > > git branch -vvv > > > * cnwebwmlmaster 8219b5126ac [cn-webwml/master] [chinese] add wnpp new > > > translate > > > master e9acb35a6c7 [origin/master: 落后 1] dovecot > > > > > > 我要获取官网最新更新，需要先在 master 进行 git > > > fetch，这个最新的版本信息只会存在于 master 分支，我的 cnwebwmlmaster > > > 要得到最新的官网更新信息，还是需要在本地进行一次 > > > merge。然后再在本地修改，commit，再push到我自己的 salsa git 仓库上，再登陆 > > > salsa 页面，在官网仓库提交合并请求。 > > > > > > 但是我一旦用 git pull 从官网获取了最新代码，进入到 cnwebwmlmaster 分支 merge > > > 的时候，就会产生 merge log，如果我要在本地消除这个 merge log，就需要运行 git > > > rebase 上一版本，再进行后续工作，本地commit，push，官网登录提合并请求操作。 > > > > > > 这样的工作效率非常低下！ > > 如我先前所说的一样，这时请不要在工作到一半的时候进行 git pull 产生 merge log，使用 git fetch > > 是可以的。等一次工作完成后可以直接提交 merge request，即使有所落后也不要紧. > > 不知道你所说的“工作到一半”，“等一次工作完成后”，这两个操作是如何界定的？ > 要等到你把我的工作合并到官网后，才算完成一次工作吗？ > > > > 我可以说得更明白一点： > > > > * 根源问题来说，是你的 merge request 中包含了太多太多完全没有任何必要存在的 merge commit（即 merge > > log）：在 > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/212/commits > > 这里可以看出一次 merge request 总计 13 个提交中排除两个不应该出现的法语内容的提交后还剩 11 次提交，其中竟然有 6 > > 个起不到任何作用的 merge > > commit，如果原样合并入上游仓库的话无疑是对提交历史的负面影响。只要能解决这个问题，使用任何技术手段都是可以的（包括但不限于我下面说的方式）； > 我今天是在尝试你昨天邮件的方法，使用 git fetch，git rebase 来取消不需要的 > merge log，但是效果不佳，所以最后的日志看起来有很多不起作用的 merge 日志。 > > * 技术手段来说，自行产生 merge commit（merge log）的做法反而大大增加了 rebase 操作的难度。其实 rebase > > 实质上就是“嫁接”操作，把一部分与主干有所偏离的提交“嫁接”到主干的最新提交上。具体到这个仓库来说可以直接在已检出 cnwebwmlmaster > > 分支的情况下使用“git rebase origin/master”完成。在检出 cnwebwmlmaster 分支时贸然使用“git > > pull”拉取远程主分支会立刻产生 merge commit 导致主分支和你的分支历史交织在一起，从此以后一团乱麻的历史除了使用拣选（cherry- > > pick）和人工调整以外已经不好处理了； > > 我的实际操作过程，和你认为的不一样。我是在master 分支，先进行 git pull > 操作，把 master 分支更新到最新版本，再 > > git checkout cnwebwmlmaster;git merge master ,在这一步就会产生merge log。 > > 如果我在 master 分支，是使用 git fetch 获取官网最新信息，再 git checkout > cnwebwmlmaster;git merge master ,在这一步确实不会产生merge log， > > 但是在我接下来进行的 push 到我个人salsa master 分支的时候，会把官网更新 > commit log 内容，也会push上去，结果就是你看到的有两个法文的提交。 > > > * 特定到 webwml > > 仓库来说，这个仓库有非常明显的特点：仓库文件极多，不同语言的翻译人员只在自己语言的翻译子目录中进行提交，绝大多数情况下互不影响。这就导致了虽然每日提 > > 交数量不 > > 少（可能每日在 5 至 20 > > 次提交），但提交之间互相影响、冲突的情况极少发生（以我的经验，约为四个月一遇）。如果以目前的工作进度来看，从开始工作到提出 > > merge request 的时间如果在 24 小时到 48 小时之间，那么完全可以忽视极其不可能存在的冲突情况，在工作中不要进行 git pull > > 产生 > > merge commit，完成工作后直接提交 merge request 即可。 > > 这里设计到一个工作流程标准化和工作习惯的问题。其它的项目，都是用 git pull > 拉取最新代码后再开始工作，唯独这个项目不用 git > pull，需要搞特例，非常不符合标准化工作流程和对所有项目的 git 操作一致性。 > > > > 当然，为确保万无一失，在提交 merge request > > 之前最好能用肉眼检查一遍在开始工作到准备提交之前到底别人修改了什么东西：以我的经验，我会用肉眼使用 git > > 可视化工具完整看一遍这段时间别人的修改内容：如果别人根本没有修改与我工作相关的任何内容，那么我的工作与别人便是没有冲突的，可以安心提交 merge > > request；如果真的出现了冲突，那必定是要手动解决的，无论是此时再产生 merge commit 还是手动 rebase 或是 cherry- > > pick > > 都是合理的手段。这个肉眼检查短则 15 秒长则两分钟，与每次工作到一半就 git pull > > 一遍甚至多遍做合并相比，这样最后做检查既可以保证不出现显性或隐性的内容冲突，也并不会造成额外的工作负担或者降低工作效率。此外，每次提交 merge > > request 时 GitLab 都有自动的检查，万一真的出现了自己没有注意到的冲突的话也会第一时间收到通知。 > 你具备官方分支的 push 权限，你的分支是设置的直接跟踪官网的 master > 分支，你git pull > 后，在你的分支上是可以完整看到这段时间别人的修改内容。但是我的分支上，如果不进行git > pull 或者 git fetch 操作，是不行的，是看不到官网 master > 分支的改动。由于我没有权限向官网分支提交 merge > request，所以我也无法接收到冲突的通知。 > > 其实说了这么多，大半都是与 git 的使用理念和技巧相关的内容。Git 官方一直提供了含有完整简体中文翻译的一本书作为使用介绍（《Pro > > git》），可以在 > > https://git-scm.com/book/zh/v2 这里找到。 > > 综上所述，你之前提到的 git fetch 和 git rebase > 两种方案，都不能够很好的解决及时从官网更新，又不产生过多 merge log 的问题。 > > 同时这些操作都是非常麻烦耗时的。你提到的这本书，我也会抽时间看，但估计一时半会解决不了我们目前遇到的问题。要想参与翻译的每一位都成为 > git 使用高手，估计也不现实。 > > 为进一步对新参与翻译的贡献者有更好的指导，建议更新 chinese/Chinese.README > 文件，详细列出没有官网提交权限的贡献者，参与翻译的相关操作步骤和命令，加强指引，才能够更好的提升协作效率。 > > > > 对于之前提到的 webwml!212 的 merge > > request，我个人基本的想法是把网页内评论中提出的问题解决，之后我可以使用拣选（cherry- > > pick）的方式将内容添加至主仓库。贡献翻译的内容的确是第一位的，但正确使用 git 等工具也是能大大提升工作效率的重要考量。 > > 这次的合并请求，还是麻烦你先手工处理吧。我已经push到我的git master > 分支了，无法回退取消这些 merge 日志的。 > > 你把多余的 merge log 去掉后，直接 merge > 到官网分支，也应该没有问题，里面涉及到的两个法文变更，git官网分支会自动识别处理吧，最终不会影响到法文翻译。 我现在的看法是目前的问题是对 git 不够熟悉所导致的。我会考虑在 https://www.debian.org/devel/website/using_git 页面上添加有关如何使用基于 Merge Request（Pull Request）的工作流进行贡献的内容。 对于未来的 Merge Request，如果其中没有多余的 merge commit 的话我会直接合并，但如果存在额外的 merge commit 的话我会使用拣选（cherry-pick）的方式来将新内容反映到主干中。还请使用最方便的方法对网站的翻译做出贡献。 谢谢， Boyuan Yang
Attachment:
signature.asc
Description: This is a digitally signed message part