使用 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，官网登录提合并请求操作。 这样的工作效率非常低下！ 在 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 记录里面，感觉没有啥意义，不知道是否需要处理下？ >>>>>> >>>>>> 肖盛文 -- 肖盛文 Faris Xiao
Attachment:
signature.asc
Description: OpenPGP digital signature