RN for OpenHarmony项目Git远程同步与AtomGit推送

1. 写在前面：为什么Day2就急着搞远程同步

如果你也是跟着React Native for OpenHarmony这条路在走，大概率Day1的流程是这样的：装环境、初始化一个RN项目、跑通Hello World、然后在模拟器或RK3568开发板上看到界面亮起来。那一刻确实挺激动，但冷静下来之后，一个很现实的问题马上摆在面前——代码全在本地，万一硬盘挂了、系统崩了、或者我想换个电脑继续写，怎么办？

我Day1结束的时候就是这个状态。项目文件夹躺在D:\RNProject\AwesomeProject里，里面一堆node_modules、build目录、各种缓存，真要备份起来又大又乱。当时我意识到，继续往下写代码之前，最该做的是先把Git工作流跑通，把项目推到远程仓库去，这样后面不管在哪台机器上都能拉下来接着写。所以Day2没有急着去研究新的RN组件或者OpenHarmony的API，而是老老实实把"本地项目与AtomGit远程同步"这条链路彻底打通。

这一篇就把Day2的完整过程记录下来，适合正在折腾React Native for OpenHarmony、同时对Git操作还不算太熟的朋友。内容不光是命令的罗列，我会把每一步为什么要这么做、踩了哪些坑、最后怎么解决的都写清楚。包括Git在Windows上的安装细节、AtomGit仓库的创建、SSH免密配置、首次推送的完整过程，以及后面平常写代码时最常用的那套提交推送节奏。

先说结论，这套流程走通之后，你的RN for OpenHarmony项目就算有了一个安全的"云端备份"，而且AtomGit在国内访问速度还不错，配合Gitee或者GitHub作为双远程备份，基本上不会再有丢代码的焦虑。

2. 环境准备：Windows上装Git最容易忽略的三个细节

2.1 下载安装其实不难，难的是安装选项理解

Git的安装包从官网或者镜像站下载都很方便，Windows下就是一个.exe，一路Next就能装上。但我发现很多人在这一步会埋下隐患，主要是安装过程中的几个选项没有认真看。我自己第一次装的时候也是无脑Next，后来用着用着才意识到问题。

安装过程中有几个关键选项需要留意。第一个是"Select Components"页面，这里默认的选项够用，但有两个建议勾上：Git Bash Here和Git GUI Here，这两个会右键菜单里加入Git入口，日常使用非常方便。第二个是"Default editor"选项，默认是Vim，如果你不熟悉Vim的操作，建议直接选Notepad++或者VS Code，不然每次commit写备注的时候被困在Vim里出不来，那种感受我相信不少人都经历过。

第三个是"Adjusting your PATH environment"页面，这里建议选中间那项Git from the command line and also from 3rd-party software。这个选项会把Git加入系统PATH，之后你在任何终端窗口里都能直接敲git命令，包括VS Code自带的终端、Windows Terminal等。如果选了第一项Use Git from Git Bash only，那在CMD或者PowerShell里是找不到git命令的，很多新手卡在"无法将git项识别为cmdlet"这个报错，多半就是这个原因。

2.2 安装完先做三件事：验证版本、配用户名、配邮箱

安装完成后，打开Git Bash，依次执行下面的命令确认环境正常：

bash复制git --version

能输出类似git version 2.43.0.windows.1这样的信息就说明安装成功了。

接下来是全局配置用户信息，这一步很多人会跳过，但涉及后面提交记录里的作者信息，必须做。我见过有人不配直接提交，结果AtomGit仓库里的提交记录显示的是乱码或者一个奇怪的默认用户名。

bash复制git config --global user.name "your_name"
git config --global user.email "your_email@example.com"

这里有两个建议：user.name尽量用英文或者拼音，不要用中文，避免某些终端环境编码问题；user.email建议和你AtomGit注册邮箱保持一致，这样提交记录能更准确地关联到你的账号。

配置完了可以用下面的命令检查一下：

bash复制git config --global --list

2.3 关于换行符和提交规范，趁早定好规矩

Windows环境下还有一个容易被忽略的坑：换行符（Line Ending）。Windows用的是CRLF，而Linux和macOS用的是LF。如果不管这个差异，项目文件里一旦混入两种换行符，Git在diff的时候会提示整个文件都被修改了，非常烦人。

我建议在全局配置中明确设置core.autocrlf:

bash复制git config --global core.autocrlf true

这个设置的意思是在提交时把CRLF转换成LF，检出时再转换回CRLF。对于Windows用户来说，这是最省心的方案。如果你和团队协作，建议在项目根目录加一个.gitattributes文件来统一规范，但自己写个人项目的话，全局配置这一个就够用了。

至于提交规范，我自己的习惯是：feat:表示新功能，fix:表示修复，docs:表示文档变动，chore:表示构建或辅助工具变动。比如feat: add login page、fix: resolve white screen on startup。这个习惯从Day1就应该养成，后面项目大了翻提交历史的时候你会感谢当初的自己。

3. AtomGit远程仓库创建与本地项目初始化

3.1 在AtomGit上建一个空的远程仓库

AtomGit是开放原子开源基金会旗下的代码托管平台，国内访问速度确实快，而且对OpenHarmony生态的项目支持很友好。登录之后，在首页右上角找到"新建仓库"按钮，进入创建页面。

仓库名称我建议和本地项目名保持一致，比如我就叫AboutMeApp（这是我Day1搭好的RN项目名）。可见性可以选私有，毕竟学习阶段代码不一定想公开。其他选项基本保持默认就行，不需要勾选"使用README初始化仓库"，因为我们本地已经有项目了，远程只需要一个空仓库。

创建完成之后，AtomGit会给你一个仓库地址，有HTTPS和SSH两种格式。这里我强烈建议用SSH，理由是免密推送，后面每次git push不用输账号密码，体验好太多。SSH地址长这样：

bash复制git@atomgit.com:your_name/AboutMeApp.git

3.2 本地项目初始化：先理清哪些文件不该提交

回到你的RN项目目录，打开Git Bash，执行初始化命令：

bash复制git init

这一步会在项目根目录生成一个.git隐藏文件夹，代表这个目录现在由Git接管了。然后执行：

bash复制git status

你会看到一堆Untracked文件。这时候千万别急着git add .，因为RN项目里有大量不该进版本库的东西，尤其是node_modules目录，里面成千上万个文件，提交进去不仅让仓库变得臃肿，而且完全没意义——package.json和package-lock.json已经能完整描述依赖关系，别人克隆下来之后执行npm install就能恢复。

正确的做法是创建.gitignore文件，把不需要追踪的文件和目录排除掉。RN项目的话，下面的配置基本够用：

gitignore复制# dependencies
/node_modules

# build output
/build
/dist

# React Native specific
*.log
*.hprof
.expo
.watchmaninfo

# IDE
.idea/
.vscode/
*.iml

# OS
.DS_Store
Thumbs.db

# npm/yarn
npm-debug.log*
yarn-debug.log*
yarn-error.log*

这里要特别提醒一下OpenHarmony相关的构建产物。如果你用的是React Native for OpenHarmony的脚手架工具，项目里可能会有oh_modules、entry/build之类的目录，这些也建议加进.gitignore，因为它们都是构建生成的，不需要进版本库。

.gitignore建好之后，再看一次git status，确认只剩需要提交的源码文件，再执行添加操作：

bash复制git add .
git status

这次git status会列出所有要提交的文件，建议花点时间扫一眼，确认里面没有.env这类可能包含密钥或敏感信息的文件。我见过有人在git status列出几千个文件的时候懒得检查，直接提交，结果把本地配置文件里的API密钥也推上去了，后面被平台安全扫描警告。

3.3 第一次提交：把项目的起点打上印记

执行提交：

bash复制git commit -m "chore: init project with React Native for OpenHarmony"

到这里，你的本地仓库有了第一个提交。可以再看看日志：

bash复制git log --oneline

会看到类似a1b2c3d chore: init project with React Native for OpenHarmony这样的一条记录。这个提交点就是你项目历史的起点，以后回滚、分支都从这里开始。

4. SSH密钥生成与配置：实现免密推送的关键一步

4.1 为什么SSH比HTTPS更适合日常开发

如果你用HTTPS方式推送代码，每次都要输入AtomGit的用户名密码。虽然可以配置credential helper来缓存凭据，但SSH的方式一劳永逸——只要把公钥放到AtomGit上，之后所有Git操作都不需要再输密码。特别是当你有多台电脑的时候，每台电脑生成自己的密钥对，把各自的公钥加到账号里，在哪台机器上都能直接推送。

4.2 生成密钥对的具体操作

在Git Bash中执行：

bash复制ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行后会询问保存路径，默认是~/.ssh/id_rsa，直接回车用默认即可。接着会让你设置passphrase（口令），这个可以留空，直接回车就会生成无口令的密钥对，缺点是私钥一旦泄露别人就能直连你的仓库。设置口令更安全但每次使用要输口令，也麻烦。我个人的建议是学习阶段直接留空，等以后工作项目再考虑用ssh-agent来管理口令。

生成完成后，查看公钥内容：

bash复制cat ~/.ssh/id_rsa.pub

公钥是一段以ssh-rsa开头的长字符串，复制的时候要完整复制，不要漏掉末尾的邮箱地址。

4.3 在AtomGit上添加公钥并验证连通性

登录AtomGit，进入"个人设置" -> "SSH公钥"页面，把复制的公钥粘贴进去，起个名字方便识别，比如my-pc。保存之后，在Git Bash中执行：

bash复制ssh -T git@atomgit.com

如果配置成功，会收到一条欢迎信息。如果提示Permission denied (publickey)，可以先用eval "$(ssh-agent -s)"启动ssh-agent，再把密钥加进去：

bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

然后再试一次ssh -T。这个报错最常见的两个原因：一是公钥粘贴时少了字符，二是ssh-agent没有把私钥加载进来。

5. 本地仓库与AtomGit关联：remote配置里藏着的小讲究

5.1 添加远程地址并验证

本地仓库和远程仓库建立关联的命令是：

bash复制git remote add origin git@atomgit.com:your_name/AboutMeApp.git

这里的origin是一个别名，表示远程仓库的指代名称，后面所有推送、拉取命令里都会用到它。查看当前远程仓库配置：

bash复制git remote -v

会看到两条输出，分别是fetch和push的地址。这一步主要确认URL没写错，如果发现写错了，可以用git remote set-url origin 正确的地址来修正。

5.2 分支命名的第一道坎：main还是master

这是我在Day2碰到的一个值得记录的坑。本地git init之后，默认分支名是master。但AtomGit新建仓库时默认分支名叫main。首次推送时，本地是master分支，远程是main分支，两边对不上就会出问题。

解决方案有两种。第一种是推之前把本地分支改名：

bash复制git branch -M main

第二种是推送时指定远程分支名：

bash复制git push -u origin master:main

-u参数会建立本地分支和远程分支的追踪关系，之后直接用git push和git pull就能自动识别该跟哪个远程分支同步。我选的是第一种方案，先git branch -M main统一用main，这样命令更干净。现在的Git初始化和各大平台默认分支都是main了，建议你也这样统一。

6. 首次推送踩坑实录：从失败到成功的一次完整排查

6.1 第一次push直接报错

一切配置就绪，执行推送：

bash复制git push -u origin main

结果等了几秒钟，报错信息弹出来：

text复制git@atomgit.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

看到这个错误的第一反应是SSH密钥没配对。但理论上不该啊，明明刚才ssh -T git@atomgit.com已经验证通过了。我花了不少时间反复确认公钥有没有贴错、ssh-agent有没有启动，后来发现问题是出在一个容易被忽略的地方。

6.2 hidden issue：多套密钥时Git选错了私钥

检查一下~/.ssh目录，里面有好几套密钥：id_rsa（AtomGit用）、id_ed25519（GitHub用）、还有一个github_rsa。因为我之前给GitHub配置过SSH密钥，当你有多套密钥的时候，SSH客户端不知道该用哪一把去认证，默认会尝试id_rsa，但我印象里AtomGit用的应该是另一把。

查看~/.ssh/config文件，里面写了一堆Host配置，其中有一条把atomgit.com映射到了id_ed25519，这就不对了。AtomGit上我加的是id_rsa.pub的公钥，而SSH连接时用的是id_ed25519的私钥，两边对不上，自然认证失败。

找到问题就好办了，改一下~/.ssh/config里的配置，确保atomgit.com使用正确的私钥：

text复制Host atomgit.com
  HostName atomgit.com
  User git
  IdentityFile ~/.ssh/id_rsa

改完执行git push -u origin main，这次终于顺利推上去了。

6.3 这次踩坑的复盘：排查SSH问题的一个标准路径

把这个排查过程总结一下，以后遇到类似问题可以参考这个顺序：

1. 先用ssh -T git@atomgit.com验证密钥本身是否有效。这个测试能通过说明公钥、私钥、平台的关联都没问题。
2. 如果测试通过但push报错，检查~/.ssh/config里是否有针对该Host的特殊配置，尤其是IdentityFile指定了哪把私钥。
3. 如果测试不通过，检查公钥内容是否完整粘贴、是否是新生成的密钥对、ssh-agent是否正确加载了私钥。
4. 最后再看仓库地址是不是SSH格式，别把HTTPS地址用在SSH密钥体系下。

6.4 推送成功的标志与验证

推送成功后，终端会显示一串统计信息，包括对象数量和写入速度。到AtomGit仓库页面刷新一下，就能看到main分支下出现了你的所有源码文件。

顺手验证一下本地和远程的关联状态：

bash复制git remote show origin

会输出远程仓库的详细信息，包括远程分支和本地分支的追踪关系，看到local ref configured for 'git push'就说明一切正常。

7. 日常开发循环：从改代码到同步远程的标准流程

7.1 每次写代码的基本节奏

远程同步配置好了，不等于每次都要等到大功能做完才提交。我个人的习惯是一天至少提交三次，每次提交对应一个完整的逻辑单元。节奏是这样的：

bash复制# 1. 查看当前改了什么
git status

# 2. 查看具体的改动内容，确认不是误改
git diff

# 3. 添加要提交的文件（这里按需添加，避免把不相关的改动混在一起）
git add src/pages/HomePage.tsx

# 4. 提交并写清楚备注
git commit -m "feat: add home page header component"

# 5. 推到远程
git push

这里特别想强调一个习惯：不要用git add .一揽子添加所有文件。改了两个功能、三个文件，最好分两次提交，每次提交只包含一个功能相关的改动。这样以后翻历史、回滚代码都会轻松很多。

7.2 关于Gitee和GitHub多远程备份的思路

我有一次不小心把本地仓库搞坏了，虽然最后救回来了，但那次之后我就再也不敢只依赖一个远程仓库。做法很简单，给同一个项目添加多个remote地址：

bash复制# 在已有origin（AtomGit）的基础上，再添加一个Gitee远程
git remote add gitee git@gitee.com:your_name/AboutMeApp.git

# 推送时分别推送到两个远程
git push origin main
git push gitee main

或者用git remote set-url --add origin在一个remote下加多个推送地址，但这样推送日志看不太清楚推到了哪里，我更喜欢分开命名。AtomGit作为主力远程，Gitee作为备份，GitHub如果网络条件允许也可以加一个，这样三个地方任一处挂了代码都不会丢。

7.3 修改提交信息或漏提交的补救方式

写代码的过程中总会遇到"commit写错了"或者"少提交了一个文件"的情况。常用的补救命令：

bash复制# 修改最近一次提交的备注信息
git commit --amend -m "feat: add home page header component and styles"

# 把漏掉的文件补进最近一次提交
git add src/styles/HomePageStyles.ts
git commit --amend --no-edit

注意一点：--amend会改写提交历史，如果已经推送到了远程，再使用--amend后推送会被拒绝，需要用git push --force才能覆盖。但--force是个危险操作，如果是多人协作仓库，强制推送可能会覆盖别人的提交，务必谨慎。个人项目倒是无所谓。

8. 一个完整的实操案例：把Day1的RN项目从头到尾同步一遍

为了把这个过程串成一个完整可参考的流程，下面用假设场景走一遍，假设你的RN项目叫AboutMeApp，在D:\RNProjects\AboutMeApp目录下。这是Day2我实际操作的完整复盘，不是片段介绍。

8.1 假设场景：全新的项目目录

Day1用React Native for OpenHarmony脚手架创建的项目已经存在，里面已经有package.json、entry目录、oh_modules目录等结构。在项目根目录打开Git Bash：

bash复制cd /d/RNProjects/AboutMeApp

注意Git Bash的路径格式，Windows的D:\在Git Bash里要写成/d/。

8.2 初始化并整理文件

bash复制git init

把.gitignore内容填好（上文给出过完整配置），然后：

bash复制git add .

执行git status检查一下有没有不该提交的文件混进来。RN for OpenHarmony的脚手架会在项目里生成oh_modules目录，即OpenHarmony的依赖模块，这个一定要确认在.gitignore里被排除了。

确认无误后提交：

bash复制git commit -m "chore: init RN for OpenHarmony project"

8.3 配置SSH并推送

前面第4节和第5节的步骤都在这个环节用上。密钥生成、公钥配置、remote添加、分支统一。最后执行：

bash复制git push -u origin main

推送成功后，AtomGit仓库页面就能看到完整的项目文件了。

8.4 验证克隆一份副本

推送完成后，为了确认整个过程没有遗漏，我在另一个目录下测试克隆：

bash复制git clone git@atomgit.com:your_name/AboutMeApp.git /d/RNProjects/AboutMeApp-Clone

克隆下来之后对比一下package.json是否一致。然后进入克隆目录执行npm install测试依赖能否正常安装。这一步很重要，它验证的是你的仓库内容是否完整，其他人在另一台电脑上能否直接从这个仓库还原出可运行的项目。

9. 容易忽视的几个小组节：来自Day2的实际体会

9.1 提交信息写清楚，比想象中重要

Day1的时候我commit过一次，只写了类似first commit这种信息。Day2回看这条记录，完全想不起来当时改了什么。从那之后我强制自己每次提交都写具体一点，比如feat: add login page form validation、fix: resolve white screen issue on RK3568 device。缩进和格式不用太严格，但内容一定要让别人（以及未来的自己）能看懂。

9.2 大文件别往Git仓库塞

RN项目的构建产物里有不少体积很大的文件，特别是.hprof堆转储文件动辄几百MB，还有打包生成的.so依赖库。这些一旦被提交，仓库体积会极度膨胀。除了把构建产物排除在.gitignore里，我还会定期检查仓库里有没有大文件：

bash复制# 查看仓库里最大的5个文件
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print $3, $4}' | sort -rn | head -5

如果发现有几百MB的垃圾文件进了历史记录，用git filter-repo或者BFG Repo-Cleaner清理一下。

9.3 关于RN for OpenHarmony项目的特殊目录说明

React Native for OpenHarmony的项目和普通RN项目有些不同，它会多出一些OpenHarmony特有的目录和配置文件。比如entry目录是OpenHarmony应用的主入口模块，oh-package.json5是OpenHarmony侧的包管理配置，build-profile.json5负责构建配置。这些文件都建议保留在版本库里，因为它们定义了应用如何构建和运行。只有构建过程中自动生成的那些目录需要排除，比如entry/build、oh_modules、node_modules。

9.4 网络波动导致的推送失败怎么处理

AtomGit国内访问体验不错，但偶尔也会遇到网络波动，推送卡住或报错。我碰到的情况通常是这样的：

text复制error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413

这个报错通常是HTTP方式推送大文件时触发了服务器限制。解决思路有两个：一是改用SSH方式推送（SSH协议没有这个限制）；二是检查是否有大文件混进了提交。还有一个通用做法是把HTTP缓冲调大：

bash复制git config --global http.postBuffer 524288000

但说实话，根本解药还是别把大文件推上去。

10. 总结一下今天的收获就可以收工了

Day2的任务到这里就完整结束了。梳理一下完成的事情：

• Git在Windows上的安装和关键配置，注意了PATH选项和换行符问题
• 用.gitignore把RN for OpenHarmony项目的构建产物排除在版本控制之外
• 在AtomGit创建远程仓库，生成SSH密钥并配置免密推送
• 处理了本地master和远程main分支名不一致的问题
• 完整推通了git push流程，验证了克隆还原的可行性

花这几个小时把这些基础工作夯实，后面写RN for OpenHarmony的时候就能完全聚焦在业务代码上。哪怕某天电脑出问题，只需要装好环境、git clone一下项目、npm install，整个开发环境就能原地复活。

最后分享一个小技巧：如果你跟我一样用Windows，我强烈建议在项目根目录放一个README.md文件，把项目的初始化命令、启动命令、以及一些注意事项都写进去。配合Git仓库一起推送到AtomGit，这样不管换到哪台机器，只要看这个文件就能快速把环境搭起来。Day2收工，Day3准备开始研究RN页面组件和OpenHarmony原生模块的联调了。