#1 - 2020-8-15 21:40
烈之斩 (V1046-R MAHORO)
原始project为upstream

我fork了之后开始开发X功能,并且提交了PR 里面有4条commits(还没完成,所以还是open)
在这期间upstream也在不停地commit

在现在这个时间点,我想把我的fork和upstream sync然后再继续开发几条commits。

这里没有conflict的问题。

我测试了几个方案

1. fetch+merge 最标准的方案,但是会在PR里留一条merged from xxxx的commit
2. rebase:这个方案会出现以下现象:PR里会出现rebase时间点upstream的master的最后一条commit(哦这个是因为作者把我的PR的base改成非master的branch了),我自己之前加的所有的commit的日期会重新更新为rebase时的日期(而不是保留原始日期)

当然,这两个现象都没啥奇怪的,但是我想问的就是:
有没有办法在同步我的fork的repo文件为mater便于开发(需要测试master最新改动)的前提下,不污染PR里的显示,只显示我的commits(且是原始日期)?
#2 - 2020-8-15 21:58
(我曾与你一同呼吸,那些乘着星辉的凉风 ... ... ... ... ...)
我是喜欢 rebase 一些,人多了或者分支多了之后 rebase 会比 merge 更干净(对 master 而言),而且实际上我们现在一般在合并 pr 的时候会 squash 一下,把整个 pr 内的所有修改变成一次大 commit 提交到 master 上,因为有些 pr 确实会来来回回改很长时间,记录会特别长
#3 - 2020-8-15 22:07
(19914)
实际上rebase之后也有author/committer之分, author的commit的时间是不变的, 到你rebase之后又有新的commit时间, github不显示前者而已。

图一
图二
#3-1 - 2020-8-15 22:15
烈之斩
原来如此!
#3-2 - 2020-8-15 22:17
烈之斩
而且有时候好像都显示,可能两者不同的时候不一样?

我刚瞎操作还整出所有commits显示两遍的骚操作……
#4 - 2020-8-15 22:15
(天生万物以养人,人无一物以报天)
然后作者merge pr的时候选择了squash commits,你的努力全都()
#4-1 - 2020-8-15 22:19
烈之斩
(bgm38) 之前pr过 好像不会(bgm24)
#5 - 2020-8-16 00:38
(我只知道自己一无所知。)
导出 patch 然后删 repo 重新 fork,然后再应用 patch(
#5-1 - 2020-8-16 00:39
橘枳橼
不对这个应该仍然会变 commit 日期……
#6 - 2020-8-19 11:16
先checkout一个新的branch,然后git reset upstream/master --hard,然后checkout你本地branch里的几个commit的hash, git checkout <commit hash>,这样你的几个commit就会放在remote最后的commit之后,同时避免rebase造成hash id的变化。
#7 - 2020-8-19 11:47
(喵~)
push origin master -f(不是
#8 - 2020-8-19 11:48
cherry-pick 很好用