1. 为什么是 Gitee 而不是网盘或 GitHub先说结论如果你要的是公司和家里两台电脑编辑同一批文件夹打开就是最新版那网盘、GitHub、Gitee 都能做到一部分但真正用下来你会发现在国内环境里Gitee 是最省心的那一个。我试过的组合不少。最早用百度网盘把工作文件夹丢进同步盘问题在于它按文件时间戳和目录遍历来同步经常出现一个文件在公司改完回家打开还是旧版更难受的是Office 或编辑器在文件占用状态下网盘客户端会报文件被占用无法同步你得手动去点重试。后来试过坚果云同步体验好一些但对单个文件夹的版本管理几乎没有——你误删了一个文件想找回三天前的版本网盘不一定留得住。GitHub 反而更适合做这件事但它有两个现实障碍一是国内访问不稳定push/pull 频繁失败经常要重试尤其是文件多的时候二是私有仓库虽然免费但仓库名和部分交互在国内网络环境下各种别扭。相比之下Gitee 是国内的 Git 托管平台访问速度快、私有仓库免费、操作习惯和 GitHub 几乎一致而且它本身就是 Git 协议天然拥有版本管理、历史回溯、分支合并这些能力。1.1 网盘同步与 Git 同步的本质差异很多人第一次接触 Git 同步时会觉得它没有网盘自动化。确实是网盘是后台守护进程盯着文件夹你保存文件它立刻上传Git 需要你手动敲命令或点击提交按钮。但正是这个手动的环节带来了网盘没有的好处每一次提交都是一次全量快照你可以随时回到任意历史版本而不是只有当前状态。提交信息记录了这次改了什么、为什么改配合 commit 历史你能知道文件为什么变成现在这样。同步是显式的——你不会出现以为同步了其实没传上去的情况因为 push 成功与否命令行会明确告诉你。我个人的经验是网盘适合同步不需要版本管理的素材Git 适合同步需要谨慎修改、需要回溯的文档和代码。对于公司和家里继续编辑同一份文档这个场景Git 的版本管理能力恰好覆盖了网盘最薄弱的环节。1.2 三套方案的取舍清单方案访问速度私有仓库版本回溯自动化程度适合人群Gitee快国内节点免费完整可回滚手动提交需要版本管理、追求稳定GitHub不稳定看网络环境免费完整手动提交网络环境好、习惯用 GitHub 的人网盘快不涉及有限依赖客户端自动不关心版本、只要最新版如果你只是临时放几个文件网盘更省事但你的目标是长期维护一批文件且两边都能安全地改那我建议直接用 Gitee。1.3 什么样的文件夹适合这种方案不是所有文件夹都适合托管到 Git 仓库。根据我的踩坑经验适合的有文档类Markdown 笔记、需求文档、工作日志、简历、合同模版代码类个人项目、学习代码、脚本、爬虫配置类编辑器配置、shell 配置、常用工具配置不适合的有超大文件视频、镜像、数据库备份Git 仓库会越来越臃肿频繁变动的二进制文件比如大型图片素材库每次提交都要全量比对含敏感信息的文件密码文件、密钥文件、私人资料除非确认是私有仓库否则慎重判断标准很简单文件是否以文本为主是否需要版本回溯如果是那 Git 就是对的方案。2. 仓库准备注册、新建仓库、许可证到底选什么在配置本地环境之前先把远端仓库准备好。这个过程很多人随口就跳过了但恰恰是许可证选什么仓库可见性这些细节后期改起来特别麻烦。2.1 注册与实名认证Gitee 注册流程不算复杂邮箱手机号就能搞定但有一个重要环节实名认证。Gitee 对实名认证的要求比较严未认证用户很多操作受限比如新建仓库、上传大文件、开通 Pages 服务都会卡住。注册后直接提交实名认证人脸或身份证照片二选一审核速度通常几分钟到几小时。实测下来注册时用常用邮箱最省事因为后续的 Git 操作记录会关联这个邮箱以后换邮箱会导致历史提交作者信息显示异常。这点和 GitHub 一样一旦正式用起来就不好改了。2.2 新建私有仓库的关键选项登录 Gitee 后右上角 号选择新建仓库这时候有几个选项需要认真对待仓库名称建议全小写英文单词用短横线连接比如work-docs、home-lab。中文名称在 Git 命令里会变成转义字符操作起来很痛苦。开源选择私有。如果你只是想自己或少数几台电脑同步完全没必要公开。Gitee 的私有仓库免费不限制数量。初始化仓库我建议先不勾选生成 README 文件和初始化仓库。因为本地文件夹可能已经有内容远端初始化之后再往本地拉会产生冲突增加不必要的处理步骤。干净的远端仓库等你本地 init 之后直接推上来就行。分支模型默认分支建议保持 master 或 main不要在这里折腾。对个人同步场景来说单分支最简单。2.3 开源许可证选什么如果你选择的是私有仓库许可证其实无所谓因为它不对外发布。但热词里很多人搜gitee开源许可证选什么说明大家对这个概念有误解。许可证的本质是如果你把仓库公开别人使用你的代码时需要遵守什么规则。常见的几个选项MIT最宽松别人可以自由使用、修改、商用只需保留版权声明Apache 2.0比 MIT 多了专利授权相关条款适合开源项目GPL 3.0传染性强别人用了你的代码也必须开源对你私人同步的文档文件夹来说这些都不重要。我的建议是私有仓库直接用 MIT 或干脆不选公开仓库再根据你的意愿决定。选错许可证对个人同步场景没有实际影响不用过度纠结。3. 本地环境与 SSH 密钥配置仓库建好了接下来是本地的 Git 环境和身份认证。这一步很多人卡在密钥配置和多账号冲突上我拆开讲。3.1 安装 Git 并验证Windows 用户直接去 Git 官网或国内镜像下载安装包一路下一步即可。安装完成后打开终端cmd 或 PowerShell输入git --version看到版本号就代表安装成功。Mac 用户更简单系统自带 Git或者用 Homebrew 装最新版。安装完之后的全局配置是很多人忽略的。虽然不配置也能用但提交历史里的作者信息会变成空白或乱码后面回溯版本时很痛苦git config --global user.name 你的名字 git config --global user.email 你注册Gitee的邮箱注意这里的名字和邮箱会显示在每一次提交记录里如果你想保护隐私可以用一个固定的昵称但邮箱建议和 Gitee 账号一致否则 Gitee 的提交记录不会关联到你的头像和账号。3.2 生成 SSH 密钥并添加公钥Gitee 支持 HTTPS 和 SSH 两种协议。HTTPS 每次 push/pull 都要输账号密码虽然 Gitee 现在支持记住密码但经常失效SSH 配置一次之后可以长期免密操作。所以我的建议是直接用 SSH。生成密钥的命令ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车会生成一对密钥文件默认在用户目录的.ssh文件夹下id_rsa是私钥id_rsa.pub是公钥。私钥永远不要给别人公钥要添加到 Gitee 上。查看公钥内容cat ~/.ssh/id_rsa.pub然后登录 Gitee进入设置 - 安全设置 - SSH 公钥把公钥粘贴进去标题随意。添加成功后测试ssh -T gitgitee.com如果看到Hi xxx! Youve successfully authenticated, but GITEE.COM does not provide shell access.这样的提示就说明 SSH 配置成功了。3.3 本地全局配置与 Gitee 和 GitHub 的密钥冲突热词里有一个高频问题本地全局设置了 Gitee 和 GitHub 两个库冲突怎么设置并且解决这个问题我知道很多人遇到过。现象是配置了 Gitee 的密钥又配置了 GitHub 的密钥结果 push 到其中一个平台时提示权限认证失败。原因在于 SSH 默认会读取~/.ssh/id_rsa这个固定文件如果你把 Gitee 的公钥覆盖了 GitHub 的或者用同一个密钥分别添加到两个平台本身没问题但如果你生成了两套密钥默认配置就不知道该用哪一套。解决办法是用 SSH 的 config 文件指定不同平台的密钥。在~/.ssh目录下创建config文件# Gitee Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee # GitHub Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github生成密钥时不要一路回车而是指定文件名ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_gitee -C 邮箱 ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_github -C 邮箱然后把各自公钥分别添加到对应平台。这样系统会按域名自动匹配对应的私钥两边互不干扰。这是我最推荐的方案比反复删除重配密钥省心得多。4. 把现有本地文件夹托管上库完整分步操作现在到了核心环节。你已经有一个本地文件夹里面可能是一堆文档、项目代码或笔记目标是把整个文件夹托管到 Gitee 仓库然后从另一台电脑克隆下来继续编辑。4.1 初始化本地仓库并完成首次提交打开终端进入你的目标文件夹。注意进入的是文件夹本身而不是它的上级目录cd /path/to/your/folder然后初始化一个 Git 仓库git init执行后文件夹里会多出一个隐藏的.git目录这就是整个 Git 仓库的元数据区域。这个目录不要手动删也不要同步到网盘否则仓库会损坏。接着把所有文件加入暂存区。这里有个小陷阱git add .会把当前目录下所有文件都加进去包括临时文件、日志文件、系统自动生成的隐藏文件。所以执行之前最好先用git status看一眼确认没有不该提交的文件git status如果发现混入了垃圾文件先创建.gitignore把不需要的文件排除掉下一节细说。然后git add . git commit -m 首次提交提交成功后会显示一行摘要包含文件数量和变更内容。4.2 关联远程仓库并推送现在本地仓库已经就绪回到 Gitee 仓库页面复制 SSH 地址长这样gitgitee.com:你的用户名/仓库名.git执行关联git remote add origin gitgitee.com:你的用户名/仓库名.git然后推送git push -u origin master加了-u参数的用意是设置上游分支告诉 Git 本地的 master 分支对应远端的 origin/master。这样以后只需要敲git push或git pull不需要再带参数。推送成功后刷新 Gitee 仓库页面应该能看到你的全部文件。4.3.gitignore的灵魂用法哪些文件不该进仓库gitignore是决定这个方案能不能长期用的关键。在一个普通工作文件夹里哪些东西不该进 Git 仓库系统文件Windows 的Thumbs.db、macOS 的.DS_Store编辑器配置.vscode/里可能包含个人偏好不一定适合共享临时文件.tmp、~$开头的 Office 临时文件日志文件.log、崩溃转储文件构建产物编译生成的目录比如node_modules/、dist/、build/一个典型的工作文档gitignore长这样.DS_Store Thumbs.db ~$*.doc* *.tmp *.log .idea/ .vscode/创建.gitignore的正确时机是在git add .之前。如果你已经误提交了某些文件需要先执行git rm -r --cached 文件名这会从仓库中移除文件但保留本地文件。然后再把规则加入.gitignore提交一次。我记得早期用这个方案时把工作文件夹里几 GB 的压缩包也推上去了结果仓库越来越大每次 pull 都慢得难受。后来花大力气清理才意识到从一开始就应该用一个干净的gitignore。5. 公司和家里两端的日常同步工作流仓库建立好了接下来是日常使用。这一步是整个方案的核心如何保证两台电脑编辑同一批文件始终处于同步状态。5.1 第二台电脑的克隆与接管到了公司电脑装好 Git、配好 SSH 密钥后克隆远程仓库git clone gitgitee.com:你的用户名/仓库名.gitGit 会把整个仓库包括所有历史版本拉取到本地。克隆完成后你不需要再执行git init因为仓库是完整的。有一个常见误区克隆下来的仓库如果你用git config user.name和user.email查看会发现提交作者信息是全局配置的不是当前仓库的。如果这台电脑上只是临时用无所谓。如果这台电脑你会长期使用最好检查一下本机全局配置是否正确避免提交记录变成Unknown。5.2 最稳妥的四连操作顺序日常同步的标准流程我总结成四个命令每一步都有它的必要性git status # 查看当前状态确认有没有未提交的修改 git add . # 把修改加入暂存区 git commit -m 描述本次修改内容 git pull # 先拉取远端的最新内容 git push # 再推送本地内容为什么要先 pull 再 push因为如果公司在上午改了文件并推送你在家里下午改了文件后直接 pushGit 会因为远端有你不认识的提交而拒绝推送。你必须要先 pull把远端的进度合并到本地然后才能 push。这个顺序不能变。先 pull 再 push会让你始终在远端最新版本的基础上提交冲突的概率会大幅降低。5.3 提交信息的规范与同步节奏提交信息是给自己看的不要写修改或更新这种毫无信息量的话。我自己的习惯是每条提交说清楚改了什么、为什么改例如修复第三章数据统计公式、补充面试准备笔记、调整博客样式中的字体大小一次提交只做一件事不要攒着几十个文件一起提交。如果文件很多且彼此无关分开提交回滚时才有意义同步节奏每次结束工作前提交并推送第二天到另一台电脑先 pull。这个习惯一旦养成你永远不会遇到到底哪台电脑是最新的这种问题我见过不少人嫌麻烦好几天才提交一次结果某天改完忘了 push回家 pull 下来还是旧版然后一脸懵。Git 不是自动同步工具它的前提是你主动记录。把这个动作变成工作收尾仪式一样的存在才是真正用好这套方案的关键。6. 冲突是怎么产生的以及如何破解即便流程正确总有一天你会遇到冲突conflict。这不丢人Git 设计冲突机制本来就是给你兜底的关键是你懂不懂它背后的逻辑。6.1 一次真实的冲突复现我举一个真实的例子。假设你在家修改了notes.md的第10行写的是下周三项目评审会。第二天在公司你忘了 pull直接在旧版本上修改了第10行写的是下周四项目周会。提交推送时Git 告诉你 push 被拒绝你执行 pull然后提示CONFLICT (content)。这时候notes.md文件内部会变成这样 HEAD 下周四项目周会 下周三项目评审会 你自己提交的版本号 HEAD和之间是当前本地的内容和之间是远端拉下来的内容。你要做的不是关闭文件而是打开它把两段内容合并成你想要的样子然后删除那三行标记。6.2 解决冲突的标准流程合并完成后执行git add notes.md git commit -m 解决notes.md冲突统一为周四周会这个 commits 完成了一次真正的合并。之后继续 push远端就会接收你的修改。第一次遇到冲突时很多人会恐慌觉得文件坏了。实际上只要记住一点、、是 Git 加的特殊标记手动处理掉标记保留你想要的内容然后重新 add 和 commit一切就恢复了。冲突并不可怕可怕的是你在不知道的情况下直接覆盖掉另一边的工作成果。Git 的冲突提示恰恰是最好的保护。6.3 多电脑同步的其他坑冲突是最大的坑但不是唯一的坑。多电脑同步几年下来我还踩过这些换行符问题Windows 和 Linux/macOS 的换行符不同。如果仓库里的文件在 Windows 上编辑后提交换行符可能变成 CRLF造成不必要的 Diff。解决办法是在本地全局配置里设置git config --global core.autocrlf trueWindows或inputMac/Linux让 Git 自动转换。文件名大小写Windows 文件系统不区分大小写你重命名文件时只改了大小写比如Notes.md-notes.mdGit 可能察觉不到。需要执行git mv来强制重命名否则仓库里的文件名会和你本地不一致。大文件推不动如果仓库里不小心混入几十 MB 以上的二进制文件Gitee 对单文件大小有限制push 时直接失败。这时候不要硬扛把大文件移出仓库目录或者使用 Git LFS。同一时刻只在一台电脑上编辑同一个文件这句话是废话但最重要。多人协作模式下Git 靠分支管理来解决个人多设备同步场景最好只保持一条主线分支。两边同时改同一个文件哪怕没撞上合并时也要你手动处理白费精力。我的体会是这套方案真正跑顺之后你会慢慢习惯提交-推送-拉取的节奏甚至开始享受它的确定性——文件在哪台电脑上改的、改了几次、什么时候改的全部有据可查。相比之下网上那些同步软件反而让人心里没底。最后分享一个小习惯我在每台电脑的终端里把git pull设成了每天开工的第一条命令。这么做不是因为怕冲突而是为了让一天的工作始终从最新状态开始。配合 Gitee 的访问速度整个过程不到几秒钟却省掉了无数文件到底哪个新的纠结。