Geek Answers Handbook

Structuring related components in git

My team is considering moving from about 2 dozen subcontracting repos to git repos. What we are trying to fix is ​​that now everyone has their own subversion for each of their product components. What I would like to do is try to reduce some of the growth that we have and help build a clear path forward.

I am looking for tips on how to structure repositories. One of the highlights is how to group related projects. We have two products. Each product has a set of web service codes (php), an Android client code (java), an iphone client code (obj c), an ipad code (obj c) and a website client code (php + js). Currently, each owner has their own component in a separate svn repository.

My thought was to try combining these components together into one repo, but I cannot say if this is good practice with git. Does this provide any real benefit through a separate repo? It would seem that this contributes to a better social contract for the quality of what is checked in connection with general visibility, but will we pay for it in other ways?

+7
source share
3 answers

The criteria for combining different sets of files into one “component” (here is one Git repo) is their respective development life cycle (the way they are developed in terms of marking and branching):

  • Can you make an evolution on php or java-module without having to make any changes to other modules (for example, objects)?
  • Can you highlight some changes / corrections in the branch that are made only for one of these modules, and not for others?
  • Is it possible to reuse a specific version of one of these modules in several projects?

If so, it is best to use a component approach (i.e. one Git repo per module), as opposed to a single repo with everything in it ( system approach ).
See For example, a component-based web project catalog layout with Git and symbolic links .

The component is a “coherent set of files” and is best managed in its own Git repo.

+5
source

You have at least two options:

If your projects are mostly private, I recommend you stick with the first one. Read the documents, everything will be easy.

+3
source

I know little about Git workflows, but I know that you have at least three options:

  • For each project, its own repo is probably the safest option. Tags and good testing tools are your friends.
  • Divide the branches into a group of projects and each branch has its own branch . Before you do this, be sure to return everything. Watch a video of Scott Chacon on empty branches. I have not done this before, but the Github gh-pages branches are a living example.
  • Submodules Each project gets its own Git repository, inside the Git repository itself. Probably the best idea around.
+1
source

More articles:


All Articles