React Native for macOS 项目中的 Git 工作流详解

React Native for macOS 项目中的 Git 工作流详解

react-native-macos 项目地址: https://gitcode.com/gh_mirrors/rea/react-native-macos

前言

在 React Native for macOS 这个项目中，维护一个高效且清晰的 Git 工作流至关重要。本文将深入解析该项目的 Git 工作流程，帮助开发者理解如何与上游代码保持同步，以及如何正确贡献代码。

项目背景

React Native for macOS 是基于 Meta 的 React Native 项目的一个分支，专门为 macOS 平台提供支持。由于需要同时维护与上游的同步关系以及 macOS 特有的代码，项目采用了特定的 Git 工作流程。

核心工作流程

项目主要关注四种工作流程：

A. 将 react-native-macos 同步到新版本的 react-native

这是最重要的同步流程，需要特别注意：

1. 同步策略：不应直接同步到特定的标签版本，而是应该同步到上游创建稳定分支时的提交点。

2. 查找基准提交：

   • 克隆上游仓库到本地
   • 使用命令 git log main..0.68-stable --oneline | tail -1 找到稳定分支的第一个提交
   • 然后在上游仓库中找到该提交的前一个提交作为基准点

3. 执行同步：

   • 添加上游远程仓库
   • 创建专门的分支进行合并工作
   • 获取并合并基准提交
   • 处理大量预期的合并冲突
   • 创建包含冲突的 PR 以便团队协作解决

重要提示：最终合并时不能使用 squash merge，以保持 Git 历史的完整性。

B. 将 0.XX-stable 分支同步到上游对应分支

创建稳定分支后，需要定期将其与上游同步：

1. 使用上游稳定分支的最新提交作为基准
2. 创建专门分支进行合并
3. 这次可以使用 squash merge
4. 同步完成后可开始准备发布

注意：在版本生命周期内可能需要多次执行此同步。

C. 在分支中添加新功能和修复

对于 macOS 特有功能的开发：

1. 所有新功能都应针对 main 分支提交 PR
2. 合并到 main 后，可以 cherry-pick 到稳定分支
3. Android 相关修改请参考特定文档

D. 直接对稳定分支进行本地提交

这是特殊情况下的应急方案：

1. 应尽量避免直接修改稳定分支
2. 如有必要修改，应考虑同时在 main 分支提交相同修复
3. 禁止在稳定分支和 main 分支之间直接合并

最佳实践建议

1. 保持历史清晰：避免不必要的合并操作，特别是跨分支合并
2. 协作处理冲突：大型同步时，通过 PR 协作解决冲突更高效
3. 及时同步：定期将稳定分支与上游同步，减少后续工作难度
4. 功能分离：macOS 特有功能应在 main 分支开发后再移植

常见问题解答

Q: 为什么不能直接同步到标签版本？ A: 因为上游在创建稳定分支后会进行大量准备工作，直接同步标签会导致历史混乱。

Q: 如何处理大量合并冲突？ A: 建议先提交包含冲突的 PR，然后团队协作逐步解决，而不是一个人处理所有冲突。

Q: 为什么有些合并不能用 squash？ A: 保持原始提交历史有助于后续同步和冲突解决，减少重复工作。

总结

React Native for macOS 的 Git 工作流设计既考虑了与上游的同步需求，又满足了平台特有功能的开发需求。理解并遵循这些流程对于项目的健康维护至关重要。开发者应特别注意同步基准点的选择和合并策略的运用，以保持代码库的整洁和可维护性。

react-native-macos 项目地址: https://gitcode.com/gh_mirrors/rea/react-native-macos