@optional .... 见我后面的补充, dev 分支存在比较久... 到 rebase 的时候不一定记得有这么个坑要填....知道有这个问题了还是比较好处理的.

@leonshaw 这个需求是比较奇怪, 原先最朴素的想法是这个问题在主线上的某个产品出现, 所以要求直接提 MR 给主线, 但是修改人提交的 MR TARGET branch 选错了, 变成了 dev 分支, 而 dev 分支上在开发其他产品, 跟这个 bug 没关系, 就直接 revert 了.
注: 这个 bug 改的不是公共代码, 而是主线上某个产品分支的代码, 而这个产品分支在 dev 上不涉及, 换句话说, dev 分支上在开发其他产品.

@godpeo 这是种解决方案, 但 dev 是公共分支, 在开发期间 reset 等价于修改公共分支的历史, 有较大的风险, 因此不太想这么做.

@rrfeng
> If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped and warnings will be issued (if the merge backend is used). For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):

https://git-scm.com/docs/git-rebase

@kyuuseiryuu 实际 dev 分支存在时间比较久... 不一定记得有这么个坑在.

@renmu 是指变基完成后再 revert 一遍吗? 实际因为 dev 分支开发比较久, 在变基时不一定记得有这个坑在里面...

@Pastsong 那 main 分支上的 Q 修改就丢了, 因为 dev 上没改这个.

@hsfzxjy 实际 dev 开发时间比较久, 不一定会记得有这种 revert.

同意 @tealover007 的看法, 建议试下四条内存插满能不能用, 如果可以只是 CPU 或主板对内存通道顺序有要求, 不用在意这个事(属于正常现象).

@hanxiV2EX 多谢老哥, 已经解决了.

@hanxiV2EX 没弄过 js, 老哥看下这个(仓库)[https://github.com/TehShrike/private-github-website/]里的东西是否符合你说的思路.

@oneisall8955
@SenLief 确实没用过 ghproxy, 这么用的是话是挺方便的.

@SenLief 那感觉就比较麻烦了, 还要另下个代理软件.

@SenLief 放 github gist 的话不弄 tizi 能正常访问吗?

@wherelse 这个方案收费吗?

@sduoduo233 不想再解一遍, github page 能不能设置密码访问?

@care 感谢, 我了解下.

@si 某种程度上说是很有用的工具.

@westoy 秒杀只是举例, 确实是最实用的举例...