一觉醒来,我成为了41.5k+⭐AI项目的贡献者?但坏消息是什么?(附git实操收获学习分享)

图片



docs:Synchronize Chinese documentation with updates from English
Add new Cherry-Studio client

如图,第一次给GitHub大项目PR贡献,成功合并了! :partying_face:

事情是,我最近在看和找好的AI MCP服务,看到这个GitHub大合辑,一开始是看中文文档,

后面某一天不知道怎么地突发奇想去看英文文档,然后发现非常不同步,中文的落后英文非常多!然后就fork一份开始同步更新。
这么多的一个个列表项目怎么知道中文比英文少了哪些?一开始是想让ai去找,用cline和cursor去干这活发现都纯**,这么简单的事情没办法干好,总是有疏漏。最后使用最蠢最底的人工办法──人工比对核查!

(其实可以写简单小程序对两文档的列表收到有序集合里进行比对,因为中英文文档虽然语言不同但中括号里的名字是一样的,不过我懒得弄了)

就是一个个去找,我把顺序保持与英文文档的一样,反复从头到尾全看一遍尽最大力确保不漏一个。

翻译选择:DeepSeek-v3-0324:plus:人工精翻校对 的方案

大部分ai翻译能准确表达意思的,但还有一些一眼我就觉得不对劲;比如:

  • 一些专有名词不能翻译要保留原有英文,cursor不能翻译成光标;
  • 而对于一些翻译,由于ai翻译严重缺乏上下文,翻译不行,还需要我手动点进那个mcp的GitHub看了readme才知道应该怎么准确翻译,句子的顺序逻辑

举个例子@co-browser/browser-use-mcp-server这个在英文文档是browser-use packaged as an MCP server with SSE transport. includes a dockerfile to run chromium in docker + a vnc server.,
直接翻译就是以MCP服务器形式封装的浏览器应用,采用SSE传输协议。包含一个Dockerfile用于在Docker中运行Chromium浏览器及VNC服务器。,
我一眼就看出是不对了,进行校对之后:browser-use是一个封装了SSE传输协议的MCP服务器。包含一个dockerfile用于在docker中运行chromium浏览器+VNC服务器。

(我英文不强尽力传达对应专业意思,如果翻译还是不到位轻喷)

后面再进行更新同步就简单多了,用idea的git可视化来比对英文文档新旧提交差异。

但坏消息是什么?

首先是:



该仓库作者一下子腹泻般处理完一堆滞留PR,多了整整179次提交,然后我的主线分支落后了整整321提交!又得继续接着继续同步更新中文文档。(悲
刚开始还以为落后的简单问题,先看一下我的提交从哪里开始落后

总结

从我同步更新中文文档的 5e188685fb868607532c9ba3c78dc008c4f5227c 的提交或者 2043a253283b80dcfaaf90e66ce42334a22a67ea 的解决pr合并冲突的最后一次提交,有新增加了非常的多的commit,只有少数是对中文文档更新的commit外其他绝大部分英文commit都需要我去同步。

发现严重问题,让我第一次直面感觉到什么才叫 Git分布式协作

总结

在我pr之前就已经堆积很多的其他pr了,他们的commit全在我之前,但我开始fork仓库的时候并未合并进去。。。emmm…,好像成糊涂账了,以上游主的远程GitHub看的commit是实时最新的,但我本地仓库的commit历史发现新合并pr进来的commit并没有!


画了个简单小图,应该是这样。
所以不管这么就以我最后一次提交为准来对比最新提交,签出新建分支old然后上传远程备份。

Git实操收获分享

3、已PR但未合并前上游新合并导致合并冲突:可以直接在GitHub网页上直接操作,把冲突标识删掉剩下最终的就是合并冲突解决方案了,也可以下GitHub Desktop打开对应的PR然后用VSCode打开然后进行编辑。貌似也可以添加上游分支的远程仓库然后再合入到当前PR的分支最后推送也可以解决冲突?我没试过这个。想起了之前看过的不错讨论:Github进行fork后如何与原仓库同步:重新fork很省事,但不如反复练习版本合并 · Issue #67 · selfteaching/the-craft-of-selfteaching · GitHub
2、未提交的本地修改在不想提交的前提下更新最新上游仓库到本地:
暂存本地所有修改

#GitHub上操作把上游更新到自己fork的仓库
#获取远程变更但不合并
git fetch origin
#暂存当前修改
git stash
#拉取上游变更
git pull
#恢复暂存的修改并删除记录 或 应用最近暂存修改(不删除)
git stash pop  |  git stash apply

1、多个提交合并成一个但不产生新提交和修改远程仓库提交记录:有时候几个提交中比较水,只是修改了错别字之类的,可以把它们合成一个提交。
这就使用到交互式变基 git rebase -i,有idea的可以用git GUI工具进行操作
如果是个人的远程仓库可以用git push --force或git push --force-with-lease强制推送来修改,但对于多人协作的分支一般不会使用这个而是合并产生一个新提交记录。

git比较菜轻喷,这是我实操git收获的,ai的帮助也是很大。
之前是快速上手
【【GeekHour】一小时Git教程】 https://www.bilibili.com/video/BV1HM411377j/?share_source=copy_web&vd_source=b11655502851d8dfea6c51b9ddd6f643
会了一些基础概念和操作,但是有IDEA GUI连命令都省,点点点就完事了,看差异也很方便;只要会fork、clone、pull拉取、push就完事了,顶多稍微了解一下Merge和 Rebase

额外附图

121 个赞

佬 太厉害了 有耐心

3 个赞

既然选择开始做了,那没有停的道理,就只能做完 :tieba_087:

11 个赞

:tieba_087: 大佬太强了!

4 个赞

大佬太强了

3 个赞

大佬太强了

3 个赞

大佬太强了

2 个赞

AI项目的星星是真多
想起来我也有个100k的pr,遇到问题自己修好了就顺便提交了
好在这bug修起来简单,改的代码很少,就没遇到冲突

7 个赞

是 stable-diffusion-webui!我记得我很久之前收藏的项目当时为了AI绘画,不过现在看主线最后一次commit好像是九个月前了:thinking:
看一下最后PR和开发分支:thinking:

3 个赞

哈哈用心了

2 个赞

什么时候出个一小时RUST教程

2 个赞

牛哇牛哇

2 个赞

不常用的话,后面就忘了。。。别问我怎么知道的。。

没关系 已经很厉害了 多语言文档慢几个版本是很常见的

1 个赞

我不会啊 :tieba_087:

一是这些命令我从来没有刻意记过,都是现用现查的,现在也有AI了随时谁地问,提个醒我就回忆起来了,不至于记忆力这么差吧。
二是记笔记啊,建立知识索引!我喜欢把我学到的东西系统地整理成文档和索引,然后去折腾别的东西立刻把它全部忘记(相当于内存清空吧),等要用到的时候我可以根据脑力索引很快找到对应内容。现在也有AI+知识库更加方便了。

1 个赞

只要我有空,看到内容更新了我就尽量追。当然,靠大家努力,我一段时间没关注了,可能还有其他人也加入进来一起完善。 :grinning_face:

好强啊大佬

1 个赞

感谢佬的分享

1 个赞

:tieba_087:好强,回去细品!

1 个赞