Git single or separate for different project?

Question

I would like to know which is a better choice of GIT management for my project?

I have a main project that requires development on Software, Firmware, and Mobile application, the project structure is shown below:

+ MainApplication
     + Software (Visual Studio project)
     + Mobile (Android project)
     + Firmware (ARM project)
     + Document

So, do I seperate each project (software, mobile, firmware) into a single GIT repo? or I just include all projects into a single big GIT?

I have the pros and cons listed below:

• Single GIT

  • GOOD: I can track all the projects at once, and it is not fragmented and easier for me to manage
  • GOOD: it would be easier for people at start using this GIT, because everything is shown in a single GIT
  • GOOD: I can place the document into this main GIT
  • BAD: i cant tag or release each project, unless i prefix them and also it is difficult to track the commit for such a big projects

• Multiple GIT

  • BAD: too many GIT repo, too fragmented, you need to provide 3 git link for each project instead of one, troublesome
  • BAD: i want to track my document folder too, it will be "funny" to create a single GIT jsut for this document folder
  • GOOD: can easily track each project problems and commits

---

UPDATE 1

There are really a lot of good feedback below, and I love some of the approach mention,

• seperate GIT and group them together

  1. GOOD: i like this idea, because i could independently track each of them as mention above
  2. GOOD: and i could group all of the git, and i could browse them easily, rather than a huge git repo that you need to browse through
  3. BAD: sounds strange, you probably needs to create another git just to track the document folder
  4. SOLUTION:
     • In Github, you could use organization (sort of a hack to group all the gits, because now that git no longer belongs to your personal gits
     • In GitLab, you could use label, to group them, so you can easily sort them in the future

• using Git submodule

  1. BAD: hard to use
  2. GOOD: ?

Answer 1

The rule I usually follow is:

• Code that is branched and released together goes into one repository.
• Code that is branched and released independently into a separate repository.

This is because in git you cannot branch or tag some part of a repository (like e.g. in Subversion) - branches and tags are always for the whole repo.

So the question is: Do you always release all parts together? Or are they developed and released separately (maybe even with different version numbers)?

Answer 2

The pro argument about "fragmented" repositories (and it's con counterpart) doesn't hold it's ground.

I can track all the projects at once, and it is not fragmented and easier for me to manage

You already noted yourself: using one repository won't allow you to take properly advantage of tags and it will be hassle to tell the histories apart.

In my opinion it achieves quite the opposite. It will be harder to manage and to track.

As I see it, different repositories are the superior choice.

---

You have three different subprojects with more or less different history. If you somehow want to group them submodules might be the way to go, using a "main" repository for the overall project.

This "main" repository can also be used to track your Documents folder.

Answer 3

Multiple projects in one git repository is an antipattern. Especially when using maven and CBI (e. g. Jenkins). And when using different versions for your (sub)projects then using the maven release plugin in combination with git is impossible. If you have the same version for all projects then this may be an indicator that you could go for the one repo solution. But I advise against it. We decided to use one repository for multiple related projects with good reasons but I would never do that again.

About submodules and other solutions: that depends on how familiar with git you are. If git is new for you do not underestimate the learning curve even without submodules.

This question is quite similar to yours.

Answer 4

I think, will be good for multiple GIT projects. (Not sure again a choice, as Pros and cons mentioned above) Reason which I am thinking on is: In future I got any requirement which only needs a change in Mobile project for example then you not need to worry about changes/ branching/ deployment for other projects. you can easily proceed with changing one project and remain same for others.