尧图网站建设 
ET9 项目包更新实战基于 Git master/dev 分支的包同步与合入方案【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ETET9 将框架拆分成了一个个标准 Unity Package以cn.etetet.前缀命名的 npm 包但这对使用方而言影响不大——包更新并不需要逐包手动拷贝替换而是通过一套基于 Git 分支的固定流程完成项目与包全部入库作为 master 分支开发在 dev 分支进行每次更新时先更新 master 再合并回 dev。本文以 8.3ET9项目怎么进行包更新.md 为核心结合仓库中Packages/目录、manifest.json与初始化脚本完整讲解这套包更新工作流并给出可直接复制的 Git 命令序列与常见问题排查方法。读完本文你将掌握 ET9 项目先同步上游包、再合入开发分支的标准更新姿势避免把包代码和个人业务代码混在一起造成更新冲突。一、背景ET9 为什么变成了包的形式ET9 与以往一个巨型仓库的形态最大的区别在于框架本身被拆分成大量独立包存放在Packages/目录下。以当前仓库为例可以看到cn.etetet.core、cn.etetet.loader、cn.etetet.login、cn.etetet.actorlocation、cn.etetet.statesync等几十个包每个包都是标准 Unity Package命名格式统一为cn.etetet.包名规范详见 8.1ET Package制作指南.md。从机制上看这些包本质上是 npm 包托管在 GitHub Packages 上。Unity 通过manifest.json中的scopedRegistries来拉取它们{ scopedRegistries: [ { name: ET-Packages, url: https://npm.pkg.github.com/ET-Packages, scopes: [ cn.etetet ] } ] }这段配置的语义是所有cn.etetet作用域下的包都从ET-Packages这个私有 registry 解析。包安装完成后会自动位于Packages目录下每个包内部还带有package.json、packagegit.json、Ignore.ET.*.asmdef等元数据文件例如 cn.etetet.core/package.json 中声明了该包对cn.etetet.sourcegenerator、cn.etetet.memorypack的依赖。虽然底层机制是 npm 式包管理但如原文档所说对用户来说区别不大——你不需要像手动拷 DLL 那样管理包的物理文件需要做的只是把项目 包整体纳入自己的 Git 仓库然后按分支流程同步更新即可。二、核心思想master 同步上游dev 承载开发ET9 包更新方案的核心是一个双分支模型master 分支存放项目 全部包的完整快照是纯上游内容。它用于接收来自 ET 官方的包更新保持与上游一致。dev 分支从 master 切出的开发分支承载你自己的业务代码、自定义配置和本地改动。为什么要这样做因为包更新是高频、且来自上游的事件而开发改动是持续累积的本地产物。如果不做分支隔离git pull上游包更新时会直接污染正在开发中的代码冲突难以收拾。把两者放在不同分支上每次更新就退化成两个稳定操作在 master 上拉取/覆盖包更新提交在 dev 上合并 master把更新合入开发线。从仓库结构看这套模型与 ET 官方仓库自身的组织方式一致框架代码、Packages/、Book/文档与Scripts/工具脚本共存于仓库根目录说明包与项目同仓是官方认可的使用形态。初始化脚本 Initialize-Project.ps1 也印证了这一点——它只负责初始化主包、链接ET.sln、编译 Luban 与 CodeMode 工具并不会替你管理 Git 分支分支策略需要开发者自己落实。三、初始化把项目 包提交为 master 分支在开始这套更新流程之前先要完成一次性的仓库初始化。参考运行指南1.1运行指南.md拿到 ET9 项目后在项目根目录执行初始化pwsh ./Scripts/Initialize-Project.ps1脚本会检查环境需要 .NET SDK 10、Git、生成MainPackage.txt、把主包的ET.sln链接到项目根目录并编译 Luban 与ET.CodeMode等工具。初始化完成后将整个项目目录含Packages/初始化成本地 Git 仓库提交为 master 分支并推送到自己的远端仓库git init git checkout -b master git add . git commit -m init: ET9 project with packages git remote add origin 你的仓库地址 git push -u origin master从 master 切出开发分支 dev后续所有日常开发都在 dev 上进行git checkout -b dev git push -u origin dev这里的关键点与原文档完全一致master 分支上保存的是项目 全部包的整体而不是只提交业务代码。这样每次上游包更新时master 分支就是一个干净的、可整体拉取的基线。四、日常包更新完整的 Git 命令流程原文档给出的更新流程可以概括为四个步骤切 master → 更新并提交 → 切回 dev → 合并 master。展开成可执行的命令序列如下。步骤 1切到 master 分支并拉取上游包更新git checkout master包更新的来源有两种情况如果你的仓库直接 fork 或 clone 自 ET 官方仓库则直接拉取上游git pull origin master如果包的更新是通过 Unity Package Manager 解析例如官方发布了新版本包需要先在 Unity 中刷新解析到的包版本重新打开工程或点击 UPM 刷新包文件更新到Packages/目录后再走 Git 提交流程。无论哪种方式最终都要保证 master 分支上的Packages/目录内容是最新上游包的状态。步骤 2在 master 上提交包更新git add -A git commit -m update: sync upstream packages git push origin master这一提交只应包含包的变更。建议每次更新单独提交保留清晰的更新历史方便日后回溯某次包更新引入了什么问题。步骤 3切回 dev 分支git checkout dev步骤 4把 master 合并进 devgit merge master git push origin dev合并完成后本次包更新就完整进入了开发分支。原文档强调这样就完成了合并其本质就是利用 Git 的三方合并能力把上游包变更与本地开发改动按文件粒度自动合并。五、进阶冲突处理与合并策略dev 分支上如果改过Packages/下的包文件比如修过框架 bug、改过包内配置合并 master 时就会产生冲突。处理原则优先保留上游包的源码应以上游为准本地对包内文件的修改尽量通过包外扩展或二次封装实现而不是直接改包。ET 包规范见 8.1ET Package制作指南.md也建议通过packagegit.json声明依赖、在包外编写代码从结构上减少直接改动包的需求。冲突时逐文件裁决git merge master报冲突后用git status查看冲突文件逐文件确认是保留上游、保留本地还是手动合并。合并不了及时中止如果本次更新问题较多可以git merge --abort退回合并前状态排查清楚后再重试。可选策略如果团队希望 dev 的历史更整洁可以改用git rebase master将 dev 变基到最新 master 上但注意 rebase 会改写提交历史多人协作时需谨慎默认推荐 merge。六、配套细节包结构、主包与依赖说明理解了分支流程后补充几个与包更新密切相关的仓库细节帮助你在更新时判断哪些文件属于包、哪些属于项目自身包目录规范Packages/下的cn.etetet.*目录即为一个个 ET 包。每个包包含Scripts/热更代码、Runtime/AOT 代码、DotNet~服务端专用工程~号防止被 Unity 编辑器识别、Luban/、Proto/等目录以及package.json、packagegit.json和顶层Ignore.*.asmdef默认让包代码不生效运行ET-Init后才会装配详见 8.1ET Package制作指南.md。包的 Id 与依赖packagegit.json中定义了包的 Id、名字与 Git 依赖例如 cn.etetet.core/packagegit.json 中Id: 1, Level: 1AllowAnyPackageAccess为 true。包 Id 由官方统一分配更新时留意 Id 是否变化有助于判断包的版本归属。哪些包会一起更新官方包目录见 8.2ET Package目录.md从cn.etetet.core纤程、网络、Entity 基础到cn.etetet.statesync状态同步 demo、cn.etetet.lockstep预测回滚帧同步等更新时可根据自己项目实际引用的包判断影响范围。值得注意的是当前仓库的manifest.json只声明了cn.etetet.mapplay一个file:本地包依赖其余大量包是随仓库整体携带的——这正说明包与项目同仓、整体入库、分支同步是 ET9 的标准使用方式。热更相关目录若项目启用了 HybridCLR 热更新打包链路HybridCLR - Generate、ET - HybridCLR - CopyAotDlls等操作在更新包后可能需要重做更新后建议按 1.1运行指南.md 的打包过程重新走一遍。七、总结与最佳实践清单ET9 的包更新本质上是一套上游同步 本地合入的 Git 分支工作流官方文档以极简的方式给出了核心步骤。落到实操上可以整理为以下最佳实践清单一次性初始化把项目 全部包整体提交为 master 分支并推送远端日常开发一律在 dev 分支进行。每次更新都走完整流程git checkout master→ 拉取/刷新包更新 →git add -A git commit git push→git checkout dev→git merge master→git push。不要跳过任何一步尤其是先提交 master 再合并 dev的顺序不能颠倒。尽量不改包内源码对包的定制通过包外代码、二次封装或依赖声明实现从源头减少合并冲突。更新后验证包更新合入 dev 后建议重新执行pwsh ./Scripts/Initialize-Project.ps1中涉及的工具编译步骤并在 Unity 中跑通ET-Init与 Play 验证确认包版本变更未破坏现有功能。保持 master 干净master 上只应有来自上游的包更新提交不要混入业务代码否则会失去分支隔离的意义。这套方案不依赖任何第三方工具只使用 Git 原生能力非常适合个人开发者或中小团队在 ET9 上长期跟进官方包更新。【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ET9 项目包更新实战：基于 Git master/dev 分支的包同步与合入方案
ET9 项目包更新实战基于 Git master/dev 分支的包同步与合入方案【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ETET9 将框架拆分成了一个个标准 Unity Package以cn.etetet.前缀命名的 npm 包但这对使用方而言影响不大——包更新并不需要逐包手动拷贝替换而是通过一套基于 Git 分支的固定流程完成项目与包全部入库作为 master 分支开发在 dev 分支进行每次更新时先更新 master 再合并回 dev。本文以 8.3ET9项目怎么进行包更新.md 为核心结合仓库中Packages/目录、manifest.json与初始化脚本完整讲解这套包更新工作流并给出可直接复制的 Git 命令序列与常见问题排查方法。读完本文你将掌握 ET9 项目先同步上游包、再合入开发分支的标准更新姿势避免把包代码和个人业务代码混在一起造成更新冲突。一、背景ET9 为什么变成了包的形式ET9 与以往一个巨型仓库的形态最大的区别在于框架本身被拆分成大量独立包存放在Packages/目录下。以当前仓库为例可以看到cn.etetet.core、cn.etetet.loader、cn.etetet.login、cn.etetet.actorlocation、cn.etetet.statesync等几十个包每个包都是标准 Unity Package命名格式统一为cn.etetet.包名规范详见 8.1ET Package制作指南.md。从机制上看这些包本质上是 npm 包托管在 GitHub Packages 上。Unity 通过manifest.json中的scopedRegistries来拉取它们{ scopedRegistries: [ { name: ET-Packages, url: https://npm.pkg.github.com/ET-Packages, scopes: [ cn.etetet ] } ] }这段配置的语义是所有cn.etetet作用域下的包都从ET-Packages这个私有 registry 解析。包安装完成后会自动位于Packages目录下每个包内部还带有package.json、packagegit.json、Ignore.ET.*.asmdef等元数据文件例如 cn.etetet.core/package.json 中声明了该包对cn.etetet.sourcegenerator、cn.etetet.memorypack的依赖。虽然底层机制是 npm 式包管理但如原文档所说对用户来说区别不大——你不需要像手动拷 DLL 那样管理包的物理文件需要做的只是把项目 包整体纳入自己的 Git 仓库然后按分支流程同步更新即可。二、核心思想master 同步上游dev 承载开发ET9 包更新方案的核心是一个双分支模型master 分支存放项目 全部包的完整快照是纯上游内容。它用于接收来自 ET 官方的包更新保持与上游一致。dev 分支从 master 切出的开发分支承载你自己的业务代码、自定义配置和本地改动。为什么要这样做因为包更新是高频、且来自上游的事件而开发改动是持续累积的本地产物。如果不做分支隔离git pull上游包更新时会直接污染正在开发中的代码冲突难以收拾。把两者放在不同分支上每次更新就退化成两个稳定操作在 master 上拉取/覆盖包更新提交在 dev 上合并 master把更新合入开发线。从仓库结构看这套模型与 ET 官方仓库自身的组织方式一致框架代码、Packages/、Book/文档与Scripts/工具脚本共存于仓库根目录说明包与项目同仓是官方认可的使用形态。初始化脚本 Initialize-Project.ps1 也印证了这一点——它只负责初始化主包、链接ET.sln、编译 Luban 与 CodeMode 工具并不会替你管理 Git 分支分支策略需要开发者自己落实。三、初始化把项目 包提交为 master 分支在开始这套更新流程之前先要完成一次性的仓库初始化。参考运行指南1.1运行指南.md拿到 ET9 项目后在项目根目录执行初始化pwsh ./Scripts/Initialize-Project.ps1脚本会检查环境需要 .NET SDK 10、Git、生成MainPackage.txt、把主包的ET.sln链接到项目根目录并编译 Luban 与ET.CodeMode等工具。初始化完成后将整个项目目录含Packages/初始化成本地 Git 仓库提交为 master 分支并推送到自己的远端仓库git init git checkout -b master git add . git commit -m init: ET9 project with packages git remote add origin 你的仓库地址 git push -u origin master从 master 切出开发分支 dev后续所有日常开发都在 dev 上进行git checkout -b dev git push -u origin dev这里的关键点与原文档完全一致master 分支上保存的是项目 全部包的整体而不是只提交业务代码。这样每次上游包更新时master 分支就是一个干净的、可整体拉取的基线。四、日常包更新完整的 Git 命令流程原文档给出的更新流程可以概括为四个步骤切 master → 更新并提交 → 切回 dev → 合并 master。展开成可执行的命令序列如下。步骤 1切到 master 分支并拉取上游包更新git checkout master包更新的来源有两种情况如果你的仓库直接 fork 或 clone 自 ET 官方仓库则直接拉取上游git pull origin master如果包的更新是通过 Unity Package Manager 解析例如官方发布了新版本包需要先在 Unity 中刷新解析到的包版本重新打开工程或点击 UPM 刷新包文件更新到Packages/目录后再走 Git 提交流程。无论哪种方式最终都要保证 master 分支上的Packages/目录内容是最新上游包的状态。步骤 2在 master 上提交包更新git add -A git commit -m update: sync upstream packages git push origin master这一提交只应包含包的变更。建议每次更新单独提交保留清晰的更新历史方便日后回溯某次包更新引入了什么问题。步骤 3切回 dev 分支git checkout dev步骤 4把 master 合并进 devgit merge master git push origin dev合并完成后本次包更新就完整进入了开发分支。原文档强调这样就完成了合并其本质就是利用 Git 的三方合并能力把上游包变更与本地开发改动按文件粒度自动合并。五、进阶冲突处理与合并策略dev 分支上如果改过Packages/下的包文件比如修过框架 bug、改过包内配置合并 master 时就会产生冲突。处理原则优先保留上游包的源码应以上游为准本地对包内文件的修改尽量通过包外扩展或二次封装实现而不是直接改包。ET 包规范见 8.1ET Package制作指南.md也建议通过packagegit.json声明依赖、在包外编写代码从结构上减少直接改动包的需求。冲突时逐文件裁决git merge master报冲突后用git status查看冲突文件逐文件确认是保留上游、保留本地还是手动合并。合并不了及时中止如果本次更新问题较多可以git merge --abort退回合并前状态排查清楚后再重试。可选策略如果团队希望 dev 的历史更整洁可以改用git rebase master将 dev 变基到最新 master 上但注意 rebase 会改写提交历史多人协作时需谨慎默认推荐 merge。六、配套细节包结构、主包与依赖说明理解了分支流程后补充几个与包更新密切相关的仓库细节帮助你在更新时判断哪些文件属于包、哪些属于项目自身包目录规范Packages/下的cn.etetet.*目录即为一个个 ET 包。每个包包含Scripts/热更代码、Runtime/AOT 代码、DotNet~服务端专用工程~号防止被 Unity 编辑器识别、Luban/、Proto/等目录以及package.json、packagegit.json和顶层Ignore.*.asmdef默认让包代码不生效运行ET-Init后才会装配详见 8.1ET Package制作指南.md。包的 Id 与依赖packagegit.json中定义了包的 Id、名字与 Git 依赖例如 cn.etetet.core/packagegit.json 中Id: 1, Level: 1AllowAnyPackageAccess为 true。包 Id 由官方统一分配更新时留意 Id 是否变化有助于判断包的版本归属。哪些包会一起更新官方包目录见 8.2ET Package目录.md从cn.etetet.core纤程、网络、Entity 基础到cn.etetet.statesync状态同步 demo、cn.etetet.lockstep预测回滚帧同步等更新时可根据自己项目实际引用的包判断影响范围。值得注意的是当前仓库的manifest.json只声明了cn.etetet.mapplay一个file:本地包依赖其余大量包是随仓库整体携带的——这正说明包与项目同仓、整体入库、分支同步是 ET9 的标准使用方式。热更相关目录若项目启用了 HybridCLR 热更新打包链路HybridCLR - Generate、ET - HybridCLR - CopyAotDlls等操作在更新包后可能需要重做更新后建议按 1.1运行指南.md 的打包过程重新走一遍。七、总结与最佳实践清单ET9 的包更新本质上是一套上游同步 本地合入的 Git 分支工作流官方文档以极简的方式给出了核心步骤。落到实操上可以整理为以下最佳实践清单一次性初始化把项目 全部包整体提交为 master 分支并推送远端日常开发一律在 dev 分支进行。每次更新都走完整流程git checkout master→ 拉取/刷新包更新 →git add -A git commit git push→git checkout dev→git merge master→git push。不要跳过任何一步尤其是先提交 master 再合并 dev的顺序不能颠倒。尽量不改包内源码对包的定制通过包外代码、二次封装或依赖声明实现从源头减少合并冲突。更新后验证包更新合入 dev 后建议重新执行pwsh ./Scripts/Initialize-Project.ps1中涉及的工具编译步骤并在 Unity 中跑通ET-Init与 Play 验证确认包版本变更未破坏现有功能。保持 master 干净master 上只应有来自上游的包更新提交不要混入业务代码否则会失去分支隔离的意义。这套方案不依赖任何第三方工具只使用 Git 原生能力非常适合个人开发者或中小团队在 ET9 上长期跟进官方包更新。【免费下载链接】ETUnity3D Client And C# Server Framework项目地址: https://gitcode.com/GitHub_Trending/et/ET创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考