在 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，如果原样合并入上游仓库的话无疑是对提交历史的负面影响。只要能解决这个问题，使用任何技术手段都是可以的（包括但不限于我下面说的方式）； * 技术手段来说，自行产生 merge commit（merge log）的做法反而大大增加了 rebase 操作的难度。其实 rebase 实质上就是“嫁接”操作，把一部分与主干有所偏离的提交“嫁接”到主干的最新提交上。具体到这个仓库来说可以直接在已检出 cnwebwmlmaster 分支的情况下使用“git rebase origin/master”完成。在检出 cnwebwmlmaster 分支时贸然使用“git pull”拉取远程主分支会立刻产生 merge commit 导致主分支和你的分支历史交织在一起，从此以后一团乱麻的历史除了使用拣选（cherry- pick）和人工调整以外已经不好处理了； * 特定到 webwml 仓库来说，这个仓库有非常明显的特点：仓库文件极多，不同语言的翻译人员只在自己语言的翻译子目录中进行提交，绝大多数情况下互不影响。这就导致了虽然每日提交数量不 少（可能每日在 5 至 20 次提交），但提交之间互相影响、冲突的情况极少发生（以我的经验，约为四个月一遇）。如果以目前的工作进度来看，从开始工作到提出 merge request 的时间如果在 24 小时到 48 小时之间，那么完全可以忽视极其不可能存在的冲突情况，在工作中不要进行 git pull 产生 merge commit，完成工作后直接提交 merge request 即可。当然，为确保万无一失，在提交 merge request 之前最好能用肉眼检查一遍在开始工作到准备提交之前到底别人修改了什么东西：以我的经验，我会用肉眼使用 git 可视化工具完整看一遍这段时间别人的修改内容：如果别人根本没有修改与我工作相关的任何内容，那么我的工作与别人便是没有冲突的，可以安心提交 merge request；如果真的出现了冲突，那必定是要手动解决的，无论是此时再产生 merge commit 还是手动 rebase 或是 cherry-pick 都是合理的手段。这个肉眼检查短则 15 秒长则两分钟，与每次工作到一半就 git pull 一遍甚至多遍做合并相比，这样最后做检查既可以保证不出现显性或隐性的内容冲突，也并不会造成额外的工作负担或者降低工作效率。此外，每次提交 merge request 时 GitLab 都有自动的检查，万一真的出现了自己没有注意到的冲突的话也会第一时间收到通知。 其实说了这么多，大半都是与 git 的使用理念和技巧相关的内容。Git 官方一直提供了含有完整简体中文翻译的一本书作为使用介绍（《Pro git》），可以在 https://git-scm.com/book/zh/v2 这里找到。 对于之前提到的 webwml!212 的 merge request，我个人基本的想法是把网页内评论中提出的问题解决，之后我可以使用拣选（cherry- pick）的方式将内容添加至主仓库。贡献翻译的内容的确是第一位的，但正确使用 git 等工具也是能大大提升工作效率的重要考量。 谢谢， Boyuan Yang > 在 2019/8/31 上午1:22, Boyuan Yang 写道: > > 在 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 记录里面，感觉没有啥意义，不知道是否需要处理下？ > > > > > > > > > > > > > > 肖盛文
Attachment:
signature.asc
Description: This is a digitally signed message part