We have some large projects that have been managed by TFS before, but now we need to transfer them to git for use.
But we encountered some problems during the transfer process.
For example, in TFS, we have a core project, and many other projects will reference this core project. In GIT, each project is a repo, so how do repos reference each other?
I drew a schematic diagram:
I have tried submodule and subtree. They will copy the code of the referenced project under the repo of the main project, so there will be many copies of the code. Is there a way for GIT to be like TFS, no matter how many projects reference each other, there is only one code and it is easy to maintain?
Our current project structure is roughly like this:
If you use GIT, the product_core code will be copied many times. Is there a solution that automatically references the project without copying multiple copies of the code?
If it is a java project, it is recommended to use
Maven
或者gradle
管理项目依赖,再用git管理项目工程。当然Maven
,gradle
It can also manage non-java projects.After some searching, this question is similar to the title:
http://programmers.stackexchange.com/questions/114719/organizing-git-repositories-with-common-nested-sub-modules
My understanding is that your various modules are coupled together. But sometimes it's unavoidable.
Public components or code should be changed as little as possible. Modular, it is not recommended to reduce multiple projects into one project
To manage. Many languages now have their own third-party components, and these plug-ins also use git alone
Management, release a stable version, and update it in the project when the components are updated in the future.
I understand that your core is equivalent to a basic project. Why should this reference relationship be maintained at the source code level? The project source code should be relatively independent. What is the purpose of being coupled together like this?
Isn’t maven used to do this job? Why must it be quoted at the source code level?
Split it into independent applications. Your multi-branch development structure will soon be broken into pieces