重新拉取一个PR，但错误并未更改完整，我可能需要一点时间来修复错误

[andylizi]

嗯……请先不要急，现在你的 bixudamajiang:master 分支上有一大堆重复的提交（意思是，先前合并过的更改又出现了一遍），这样的 PR 是没法合并的，只会导致历史越来越乱。你 git pull 一下看似冲突是消失了，但重复的历史仍然存在，并且 Git 在自动处理冲突的时候有时会出错，把段落给重复两遍。这种情况昨天就出现了，因此我花了老长时间把重复的提交删掉。但我的清理工作只更改了 Github 上的历史，你一 pull 到你本地后（ 9803190 ）相当于又把错的提交加回来了。

这本质上是 Git 使用的问题，因此请容我花点时间写篇文章解释要怎么做。

[bixudamajiang]

好吧，我对于git很不熟悉，所以现在处理冲突和错误很烦躁

[andylizi]

OK，开始之前，先介绍两件事：

1. Git 里面，每个提交（commit）都有自己的唯一ID。Git 用 ID 来区分不同提交，而不是内容。两个提交，即使更改的内容一模一样，Git 仍然会认为它们是不同提交。
2. 每个提交都是基于（based on）上一个提交产生的。相当于串成了一条链子。

我们在 Github 上有两个项目。一个是琉璃的，一个是你的 fork。

你希望往琉璃的项目里提交改动。琉璃 的 main 分支（主分支）上已经有五个提交了。我根据其内容把它编号为 1-5。注意！这里的编号代表的是实际改动的内容，而不是提交 ID。

你往 你的fork:master （主分支）上增加了三个改动。我根据其内容把它编号为 6, 7, 8。因为6号改动是基于5号的基础之上的，如图：

OK，你现在发起 PR，想把 你的fork:master 分支合并到 琉璃:main。因此 Github 显示：#1 wants to merge 3 commits into liuli-moe:main from bixudamajiang:master。目前为止都一切正常。

PR 是合并了，但是合并 PR 有多种方式，比如说 squash。这种合并方式会把 PR 的所有提交，给 combine 成一条，再提交到主线。

合并完成后，Git 的历史看上去像这样：

看到那个蓝色的提交吗？那就是把 6+7+8 这三个内容结合到一起的结果。现在 你的fork:master 里仍然有 6、7 和 8，但是 琉璃:main 里只有 (6+7+8) 这一个提交。现实里的例子就是 45042ca7b6aa6968ac01e824f86ca403ba56041b 。

上一个 PR 合并后，你想继续提交 PR。于是你执行 git pull 把 琉璃:main 的更改合并进了 你的fork:master，创建出 Merge branch 'master' of github.com:bixudamajiang/to-the-stars，然后在此之上又作出了 10、11、12 这三个改动：

此时问题来了：6 7 8 的内容重复了两遍！如果你再次提交 PR 的话，就会出现问题。Github 会认为：#2 wants to merge 7 commits into liuli-moe:main from bixudamajiang:master。也就是，不仅包括了新的 10 12 13，连之前的 6 7 8 也错误地包括进去了。

---

刚刚说明了为什么会出现问题。现在解释要怎么避免这个问题。

• 不要从主分支（master/main）发起PR！

正确的实践是，每次要提交 PR 的时候，新创建一个分支。比如说

$ git checkout master       # 切换到 master 分支
$ git pull upstream master  # 合并上游（琉璃）的改动
$ git checkout -b fix-1     # 在最新的上游的基础之上，创建名为 fix-1 的分支

然后在 fix-1 的基础之上修改：

$ git commit -m "改动6"
$ git commit -m "改动7"
$ git commit -m "改动8"
$ git push

等 PR 的三个改动 6 7 8 都写完后，现在你要提交 PR 了。但这时发现，琉璃的主线新增了一个提交（图中9号）。现在我们 fix-1 是基于 (based on) 5 号的，而不是最新的 9 号。此时可以进行变基（rebase）操作：

$ git checkout master        # 切换到 master 分支
$ git pull upstream main     # 拉取并合并琉璃最新的主线改动
$ git checkout fix-1
$ git rebase master

可以看到，rebase 之后的时间线里，6 7 8 这三个提交从基于 5 变成了基于最新的 9。此时就可以发起 PR 了。

PR 合并后，同样是出现了一个组合的 (6+7+8) 提交。但是，跟原先不同的是，既然 6 7 8 的改动内容已经合并到主线了，那 fix-1 就不需要它了——可以直接删掉了！

$ git checkout master
$ git pull upstream main   # 拉取 (6+7+8) 这个蓝色提交
$ git branch -D fix-1      # 删除 fix-1 分支

如图所示，fix-1 扔掉以后，时间线上就不存在重复的改动了。6 7 8 只出现了一次。

那如果想继续提交 PR 怎么办？

创建新的分支！

$ git checkout -b fix-2
$ git commit -m "10"
$ git commit -m "11"
$ git commit -m "12"

这时再提交 PR，里面就只会包括 10 11 和 12。

---

刚刚你关闭了上一个 PR #68，然后重新打开了 #69。其实这个操作没有任何意义，因为一个 PR 对应一个分支。因为你自始至终都只有一个分支 master，因此无论开多少 PR，里面包含的都是同样的内容——即，你的fork:master 到 琉璃:main 之间的差别。现在的问题在于，你的 master 分支里包含了大量已经扔掉了的提交，因此每次 PR 都会把这些重复的提交给包括进来。

目前的状况怎么解决？办法之一就是用 git reset --hard 命令把你的 master 的状态恢复到正常的某个提交，比如昨天的 e8f89f9e325bbe259de7dbc461dbb378c1d28716 ：

$ git reset --hard e8f89f9e325bbe259de7dbc461dbb378c1d28716
$ git push --force

但是注意：这样会丢弃你在这个提交之后进行的所有更改。所以操作前做好备份。

---

一句话总结：

提交PR的时候，不要直接在主分支（master）上修改，给每个 PR 都建立新的临时分支再修改

---

当前的状况可以在 https://github.com/liuli-moe/to-the-stars/network 这里查看：

[bixudamajiang]

其实不仅仅是GitHub工程上的混乱，我对于tts的修改也是很混乱。我曾经按照译文对照表进行过大量的正则替换，又在此基础上随便修改，导致我不知道要抛弃过去的工程选择从头开始还是把手上的混乱理清

[bixudamajiang]

我对于把手头上的混乱理清这件事没有底气（因为批量替换的缘故），所以我想问问您的意见

[andylizi]

建议把 批量替换 的改动和 手动修改 的改动分开来，分成多个 PR 提交。这样不仅改起来方便，review 起来也方便。昨天看的时候，重要的改动与不重要的混在一起，我一眼扫过去，千千万万个改动要中挑出有意义的那些，实在是非常费力……

这也是为什么建议给每个 PR 单独一个分支，并且保持小粒度。这样不同的改动可以并行进行。比如你提交一个批量替换译名的 fix-1，同时提交一个改动某个段落的 fix-2。前者没啥争议很快就能合并了，后者可能得要讨论几个来回，但不会互相影响。

至于现在要怎么理清混乱，我有一个建议。首先

$ git fetch --all -p                # 拉取最新的提交，但不进行任何更新
$ git reset upstream/main --

这样会把你的分支的状态回退到与琉璃保持一致，但是不会影响文件内容。换句话说：这会撤销你作出的提交，但是本地的改动仍然会保留，回到提交之前的状态：

然后把批量替换的内容，给反向替换回去。比如之前把 —— 替换成了 —— 的话，那现在就反过来操作：

以此类推。把批量替换给撤销后，理论上剩下的就是手动的改动了，可以新建一个分支再提交。

目前这个 PR 是从 master 中合并，这一点 Github 不允许更改。所以建立新分支后，你得重新从新的分支发起 PR 才行。

[bixudamajiang]

现在的主要问题是很多改动是基于已有的改动（比如给西文增加空格，给破折号增加空格，将繁体译名替换为简体译名等等）。我个人是觉得我把历史更改清除后，一章一章来进行更改（全部转换为手动更改，并按章节提交）。这样既能保证不容易被他人的更改AOE到的同时，review的工作量不会那么大。 但这样也有一个问题，我参照的译名对照表是过时的（比如关于“AI委员”，在琉璃的网站上写的是“人工智能委员”），所以我需要最新的译名对照表，但是石墨那边的文档我又没有权限查看

[andylizi]

但这样也有一个问题，我参照的译名对照表是过时的（比如关于“AI委员”，在琉璃的网站上写的是“人工智能委员”），所以我需要最新的译名对照表

我不清楚石墨文档上的对照表与 Github 上具体是什么关系（哪个版本才算标准？），但委员的译名两者是一致的……

搜了一下QQ群的聊天记录，这些改动似乎没有讨论过。个人来说，我是不赞成其中部分更改的。

但是石墨那边的文档我又没有权限查看

……我本来还在琢磨这个权限得要谁来设置，结果一看文档信息，创建者竟然是我自己…… :joy:

总而言之，邀请发到你用来 Git 提交的那个 163 邮箱上了。如果不是那个邮箱的话就发封邮件说一声吧，我的联系邮箱在我 Github 主页上有写。

[bixudamajiang]

“该文件公开分享受限 请联系文件创建者(andylizi)获取文件权限。 如无法联系文件创建者，您可以升级账号获取文件权限。”

[bixudamajiang]

石墨文档好像要我爆金币了……

[andylizi]

石墨文档好像要我爆金币了……

这应该是不需要会员的……你注册石墨文档时用的邮箱/手机是哪个？我这里可以给特定的邮箱/手机号添加权限。不方便公开发的话，我的邮箱在 Github 主页。

我个人是觉得我把历史更改清除后

这个可以用下面两条命令做到。注意这会把所有文件都不可挽回地回滚到琉璃（upstream）的 main 分支的状态。

$ git restore .
$ git reset --hard upstream/main

[rxliuli]

我不清楚石墨文档上的对照表与 Github 上具体是什么关系（哪个版本才算标准？），但委员的译名两者是一致的……

GitHub 上的译名对照表最初从石墨文档复制，吾辈个人倾向于在 GitHub 上有单一来源，但 QQ 群里似乎更喜欢石墨文档维护翻译。。。最近没怎么关注这个项目，不过前两天确实为小说站点添加了 Twitter Card 分享预览，后续在 Twitter 上分享小说将会有更好的效果（