1

In the team I just joined, they have a git repository structured in this way:

-----------------> Main project
     |-----------> Sub-project1
     |-----------> Sub-project2

So, development is done in the "Main project" main trunk (and short term branches). The branches "Sub-project1" and "Sub-project2" contain code which is not related to what is in the main trunk, i.e. the files in these branches do not exist there.

Is this a reasonable/common way to use git, or any revision control system in general?

Pietro
  • 12,086
  • 26
  • 100
  • 193
  • 1
    It's not good to use branches for independent projects. Instead consider using sub-modules? – evolutionxbox May 13 '21 at 10:31
  • 3
    No. Repositories are cheap, why not create a repo per subproject? – phd May 13 '21 at 11:19
  • 1
    Hi - can you remove the 'rcs' tag please ? This is a question about git, not rcs (confusingly rcs is a specific piece of software, not a generic description of revision control systems). – PJP May 16 '21 at 14:19

2 Answers2

4

No. It isn't a common way in git. Generally speaking, the master branch (main if you like github newest nomenclature) contains the dev code, on top. Other branches (what you called "short term branches") should be created in order to apply fixes/changes/improvements (huge refactoring, if needed) starting from code available on master branch. In this way, you will be able to merge the branches on top of the master branch via pull request (and/or merge requests, here, again, if you use gitlab and prefer it's nomenclature). This is the common way to work in git.

Nobody can say that you mustn't create a "Sub-project1" and "Sub-project2" branches for storing files that are not related to the "Main project". But, what if, for some reason, you need to use, those files, in another project located in a different git repo? What if "Sub-project1" contains a tool you need? Should you download the entire repo (it may became huge... GBs), switch the branch, pull the file? ok, git partial clone, sparse checkout, etc... may help, but, isn't better to avoid this complexity by designing a better repo from the beginning keeping everything in order?

So, after this preamble, I think that another git repo with its own branches fits good in your case, instead of branches "Sub-project1" and "Sub-project2". If you need to integrate, in the future, something coming from "Sub-project1", into another project (including the "Main-Project") you may use the git submodules. They should be used carefully, but they are useful in a lot of circumstances.

bitfox
  • 2,281
  • 1
  • 18
  • 17
  • 1
    You exactly described the way I use git, which seems to be the standard one, and thank you for confirming my doubts about the other approach. – Pietro May 13 '21 at 16:30
1

It's certainly not usual, keeping separate histories separate is one of those things people learning Git learn is possible, sensible, practical, clean but it's hard to point to any irremediable downsides to this. You can casually clone and create work trees for single branches either way; you can fetch and push any histories either way, there's really very little consequential difference to the way they're doing it, it's just a little unclean from within the Git-aware aesthetic view. And if all those branches are part of a single development workflow, well, yay, one fetch and it's all there for you. So I wouldn't call it unreasonable going just on what you've given here.

jthill
  • 55,082
  • 5
  • 77
  • 137