修改第三方代码时的 Git 子模块工作流程
因此，我有一个项目 A ，其第三方依赖项 B 位于其他服务器上。
如果我将 B 添加为 A 的子模块，那么我可以使用标准子模块工作流程轻松获取对 B 的第三方更改。此外，我可以将 A 克隆到另一台机器，并使 B 处于我期望的确切状态。
如果我将 B 添加为 A 的子模块并进行自己的一组更改并提交给 B，我仍然可以获得 B 的第三方更新。但是，如果我尝试将 A 克隆到另一台机器，B 将最终陷入困境声明，因为我对 B 所做的承诺不是“公开的”。
完成第二个场景的良好工作流程是什么？也就是说，能够在不牺牲 git 分布式特性的情况下使用、修改和更新存储库中的第三方子模块？
So I have a project A with a third party dependency B which lives on some other server.
If I add B as a submodule of A, then I can easily get the third party changes to B using the standard submodule workflow. Furthermore, I can clone A to another machine and have B in the exact state that I'd expect.
If I add B as a submodule of A and make my own set of changes and commits to B, I can still get third party updates to B. However, if I try to clone A to another machine, B will end up in a bad state since the commits I made to B aren't 'public'.
What's a good workflow to accomplish this second scenario? Namely, being able to use, modify, and update third party submodules from a repository without sacrificing the distributed nature of git?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
叉
B。将您的 fork 包含为A的子模块。向上游拉动更改是一个两步过程；将更改从B拉入您的分支，更新A中的子模块。这还假设您的分叉存储库可以被您想要签出
A的任何其他机器访问。Fork
B. Include your fork as a submodule ofA. Pulling upstream changes is then a two step process; pull the change fromBinto your fork, update your submodule inA.This also assumes that your fork repository will be accessible to whatever other machine you want to checkout
Aon.