在git中构造相关组件 [英] Structuring related components in git

问题描述

我的团队正在考虑从二十多个subversion回购转入git回购。我们正试图弥补的是，目前，每个人都有自己的颠覆回购每个他们的产品组件。我想要做的就是尽量减少我们的蔓延，并帮助建立一条清晰的道路。

我正在寻找关于如何构建回购协议的建议。一个关键点是如何将相关项目分组。我们有两种产品。每个产品都有一组web服务代码（php），android客户端代码（java），iphone客户端代码（obj c），ipad代码（obj c）和网站客户端代码（php + js）。目前，每个所有者都有自己的组件在一个单独的SVN回购。

我的想法是试图将这些组件组合成一个回购，但我不知道这是git的一个好习惯。这是否提供任何真正的好处，因为有单独的回购协议？这似乎是由于共同的可见性而为检查的质量制定了更好的社会契约，但是我们是否会以其他方式来支付？ >解决方案

在一个组件（这里是一个Git仓库）中组合不同文件集的标准是它们各自的开发生命周期（它们在标签和分支方面的发展方式）：

• 您可以在php或java模块上进行进化而不必对其他模块进行任何修改（如obj c）？
  
• 你可以在分支机构中分离出一些只为 这些模块而不是其他的的进化/修复吗？
  
• 在几个项目中重用这些模块的特定版本？

如果是，基于组件的方法最好（即一个git每个模块的回购），而不是一个包含所有内容的回购（系统方法）。

参见。

组件代表连贯的文件集，最好在自己的Git仓库中进行管理。

My team is considering a move from about 2 dozen subversion repos into git repos. What we are trying to remedy is that currently, everyone has their own subversion repo for each of their product components. What I'd like to do is try to reduce some sprawl we have and help build a clear path forward.

I'm looking for advice on how to structure the repos. One sticking point is how to group related projects. We have two products. Each product has a set of web services code (php), android client code (java), iphone client code (obj c), ipad code (obj c) and website client code (php + js). Currently each owner has their component in a separate svn repo.

My thought was to try to combine these components together into one repo, but I can't tell if that is a good practice with git. Does this provide any real benefit over having separate repos? It would seem to foster a better social contract for the quality of what gets checked in because of the common visibility, but are we going to pay for that in other ways?

解决方案

The criteria for combining different set of files in one "component" (here one Git repo) is their respective development lifecycle (the way they evolve in term of labelling and branching):

• can you make evolution on php or java module without having to make any modifications to other modules (like the obj c ones)?
• can you isolate in a branch some evolutions/fixes which are only made for one of those modules and not the others?
• can you reuse a specific version of one of those modules in several projects?

If yes, a component-based approach is best (i.e. one git repo per module), as opposed to one repo with everything in it (system approach).
See for instance "Component based web project directory layout with git and symlinks".

A component represent a "coherent set of files" and is best managed in its own Git repo.

这篇关于在git中构造相关组件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！