git 提交后挂钩
我有两个 git 项目存储库，它们有两个或三个共同文件。
像这样的东西：
Project A ------> helper_functions
项目 B ------> helper_functions
我想知道是否有一种可接受的方法可以在存储库之间“共享”这些通用帮助程序文件，这样我就不必在两个存储库中维护单独的副本。
当项目 A 的 helper_functions 更新时，类似提交后钩子的东西会更新项目 B 中的 helper_functions 吗？或者是否有一种更无缝的方法来确保两个项目都具有最新和最好版本的 helper_functions 文件，并且该文件自动包含在项目的任何包中？
感谢您提供有关处理此问题的可接受方式的任何想法或资源。
另外，我想补充一点，这两个项目都有协作者，因此理想情况下它是自动的，因此我们都在同一页面上，而不必使用软链接或别名。
I've got two git project repos that have two or three files in common.
Something like this:
Project A ------> helper_functions
Project B ------> helper_functions
I'm wondering if there's an accepted method to "share" these common helper files between the repos, so that I don't have to maintain separate copies in both repos.
Would something like a post commit hook that would update the helper_functions in Project B when the helper_functions from Project A are updated? Or is there a more seamless method for ensuring both projects have the latest and greatest version of the helper_functions file and that the file automatically gets included in any package of the project?
Thanks for any ideas or resources on an accepted way to deal with this.
Also, I wanted to add that both of these projects have collaborators, so it would ideally be automatic, so we're all on the same page without having to use soft links or aliases.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有些人可能会说这对于几个文件来说太过分了，但对我来说，这听起来像是使用 git 对子模块的支持的一个很好的例子。基本上，您将创建一个名为
helper_functions的新存储库，并将其作为子模块添加到每个现有存储库中：但是，使用子模块有一些微妙之处，因此值得先读一些书。我喜欢 git 手册中的描述 作为一个起点，但还有很多其他很好的解释，例如来自 Pro Git。
但是，我不会创建钩子来提交和推送子模块 - 我认为当您想要更新在主存储库中提交的子模块的版本时，最好仔细考虑。不过，我发现非常有用的是使用
commit-submodule脚本，确保在存储库中提交新的子模块版本之前推送子模块更改。Some people might say this is overkill for just a few files, but to me this sounds like a good case for using git's support for submodules. Basically, you would create a new repository called
helper_functions, and add that to each of the existing repositories as a submodule with:There are a few subtleties to do with working with submodules, however, so it would be worth doing some reading first. I like the description in the git manual as a starting point, but there are plenty of other nice explanations, e.g. that from Pro Git.
I wouldn't create hooks to commit and push the submodule, however - I think it's better to carefully consider when you want to update the version of the submodule that's committed in the main repository. What I have found quite useful, though, is to use a
commit-submodulescript that makes sure you push your submodule changes before committing a new submodule version in the repository.我会使用子模块，但建议使用“git Slave”来处理共享存储库的任何更新。
另一种方法是使用子树。
I would use a submodule but would recommend the use of "git slave" to work with any updates to the shared repository.
The alternative is the use of subtree.