2

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: ?
Cœur
  • 37,241
  • 25
  • 195
  • 267
Tim
  • 3,755
  • 3
  • 36
  • 57
  • Have you considered [Git Submodules](http://git-scm.com/book/en/v2/Git-Tools-Submodules)? – Garrett Hyde Jan 29 '15 at 07:09
  • @GarrettHyde yup, but that requires me too create multiple git and then create a main git to link all the other gits, would this be good? or what is the norm for this kind of situation> – Tim Jan 29 '15 at 07:16

4 Answers4

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.

Sascha Wolf
  • 18,810
  • 4
  • 51
  • 73
2

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)?

sleske
  • 81,358
  • 34
  • 189
  • 227
  • that is a good rule, but if you use seperate git do you keep on trap of all of them by bundling into 1 big git repo like submodule? or u just left them independently? – Tim Jan 29 '15 at 14:21
  • 1
    @Tim: I just leave them independently. We use [Stash](https://www.atlassian.com/software/stash) from Atlassian as our Git server, which lets you group repos by "Project". If you have many Git repos, you'll probably need some kind of Git server which lets you group your repositories - that will help keeping track of them. I think most other git hosting servers (like Gitorious, Gitlab etc.) also have some notion of "project". – sleske Jan 29 '15 at 14:44
  • that is a very good idea to group them up together, i like that, but how do i track the document folder? create a git just for that document folder? – Tim Jan 30 '15 at 00:45
  • 1
    In your case, you could have one project "MyApplication", with four repos: Software (Visual Studio project), Mobile (Android project), Firmware (ARM project),Document. Though it might be better to store the documents in/as a wiki, not in git. – sleske Jan 30 '15 at 06:26
1

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.

Community
  • 1
  • 1
mithrandir
  • 738
  • 1
  • 6
  • 17
0

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.

Varun
  • 95
  • 7