I just migrated a large svn repo to git and started using gitflow. It worked like a charm but now I'm thinking about splitting that big repo into a number of smaller ones.
Let's supposse the repo directory tree is as follows:
/repo
- libs
- apps
-- app 1
-- app 2
And we want to split it into three repos, one with the core structure (libs and apps directories) and the other two with the apps directories.
If I use git subtree to split like that will I be able to use git flow individually in each part or I'll have to use it globally?
PS: This is my first question in stackoverflow, please be kind :)
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.