如何在 GIT 中最好地组织多个项目?
我正在评估GIT是否可以组织我们的项目。 我们在本地网络上使用 Visual Studio 2010 在 Windows 下工作。
我们的项目组织如下:
我们有一个共享代码库(称为SHARE),允许所有开发人员扩展、修改和修复错误。 所有开发人员都有多个依赖于共享代码库的私有项目。 所以结构是:
root
|
+-- SHARE
+-- Project 1 Dev 1
+-- Project 2 Dev 1
+-- Project 1 Dev 2
我想到的是网络驱动器上的一个原始存储库,每台开发人员 PC 上都有克隆,以及开发人员 PC 上每个项目的 1 个私有存储库(也许还有网络上的一些备份)。最好是某种链接,这样当开发人员检查他的项目时,他也将获得正确的共享源。 这可以用 GIT 实现吗?如何实现?
或者您能推荐更好的方法吗?
I'm elaluating whether GIT is possible to organise our projects.
We are working under Windows with Visual Studio 2010 on a local network.
Our project organisation is as follows:
We have a shared code base (call it SHARE) where all developers are allowed to extend, modify and do bug fixes.
All developers have multiple private projects which depend on thes shared code base.
So the structure is:
root
|
+-- SHARE
+-- Project 1 Dev 1
+-- Project 2 Dev 1
+-- Project 1 Dev 2
What I think of is one origin Repository on a network drive with clones on every developer PC and 1 private Repository for each project on the developer PCs (maybe some backup on network as well). Good would be some kind of link, so that when a developer checks out his project he will get the correct shared source as well.
Is this possible with GIT and how?
Or can you recommend a better way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
子模块可能就是你想要的——它们让你存储一个“指针”主项目(“超级项目”)内的其他一些存储库包含有关子项目的确切“状态”的元数据,因此每个人都在致力于一致的共享子项目。
子模块本身可以像任何其他存储库一样进行处理和改进,并且“状态”指针可以在适当的时候更新为新商定的版本。
因此,您的超级项目将包含一个子模块:“共享”,当开发人员克隆您的主存储库时,他们会运行 git submodule init && git submodule update 以根据需要自动设置其子模块。
Submodules is probably what you're after -- they let you store a "pointer" to some other repo inside a main one (the "superproject") with metadata about the exact "state" of the subproject so everyone is working against a consistent shared subproject.
The submodule itself can be worked on and improved just like any other repository, and the "state" pointer can be updated to the newly agreed upon version whenever is appropriate.
So your superproject would contain one submodule: "shared", and when devs clone your main repo, they run
git submodule init && git submodule update
to automatically get their submodules set up as necessary.