8

大規模な svn リポジトリを git に移行し、gitflow の使用を開始しました。それは魅力のように機能しましたが、今はその大きなレポをいくつかの小さなレポに分割することを考えています.

レポ ディレクトリ ツリーが次のようになっているとします。

/repo
  - libs
  - apps
    -- app 1
    -- app 2

そして、それを 3 つのリポジトリに分割したいと考えています。1 つはコア構造 (libs および apps ディレクトリ) を含み、残りの 2 つは apps ディレクトリを含みます。

git サブツリーを使用してそのように分割すると、各部分で個別に git フローを使用できるようになりますか、それともグローバルに使用する必要がありますか?

PS: これは、stackoverflow での最初の質問です。親切にしてください :)

4

1 に答える 1

6

I don't use git flow, but I would argue the answer depends on how modular you are. Can you deploy the core structure without deploying app1 and app2? Can you deploy app1 and app2 independently of one another? Is your dev team sufficiently large and sophisticated enough to treat them as independent workflows?

If the answer to these questions is "yes", I'd argue treating them as multiple projects, each with a unique flow. If the answer to any of them is "No", however, I'd avoid fracturing your project. In fact, if changes to app1 and app2 also demand changes to the core repository most of the time, I'd avoid fracturing your repos at all.

Nested repositories, whether they are executed with subtree, submodules, or (deity forbid) just .gitignore by definition make workflows more complicated. Commands like git bisect and git log become just a little bit less useful; tracking history and bugs become just a little bit harder. New developers have to learn just a little bit more to start coding. From personal experience: Tread this path carefully. If your sub-repos are heavily intertwined, you'll be back here in a year writing this answer for someone else looking to fracture their project, like a troubled git version of Pay It Forward.

于 2012-08-17T14:54:17.527 に答える