问题
I have many sub -repos, meaning one big umbrella repo that has smaller repos. Now when I do a commit in a leaf repo, it will automatically mean that I get a change in its parents. If you suppose the structure as a binary tree, you may realize it is ridiculous -- having 5 git-repo deep structure could easily mean $ git commit -m 'did 1'; cd ..; git commit -m 'did 1 as mentioned'; ... git commit -m 'did 1 same as earlier'. How can I avoid this kind of repetitive committing?
Example 1: a graphical example about the problem
X---------| | Y---------A --------| | B --------|<-----Pictures (graphic designers, animators--have repo) | C --------|A change in Pictures will change A, B, C, X and Y -- bloated commit, 6 commits due to one change, bad repetition! Now people working with Pictures can be totally different people to people doing things with X,Y, A, B and C, making things more obscure.
Example 2: hand-on -example to trial with sub-sub... -repos
Please, copy this hand-on -example here. You can test things there with 3-level -sub-repos.
So far Suggested
The basic submodules in Git, more here.
Gitslave here.
回答1:
Don't create repositories within repositories. That will avoid repetitive commits. Probably will solve other issues as well.
If you really think you have a need for repositories within repositories then use submodules.
回答2:
It is possible that your design or structure is poor, perhaps the premise behind GoZoner's command "Don't create repositories within repositories.", but it is also possible that your project has come to a point requiring more powerful tools. There are times when basic submodules are not enough and your repos too broad, then you should probably look at -- GitSlave! It is a workflow -tool in which you specify your super -repo and then the slave repos. Instead of repetitive commiting, you use the gits -command -- manual here.
Related threads
Git: a tool to manage and to structure Projects?
Not sure whether you should use Gitslave? Read a small introduction here with a walkthrough.
回答3:
Do the files in your repositories often come with associated changes with other files in other repositories? If so, multiple repositories is not your friend. You should only use multiple repositories when they are completely (or almost completely) independent of one another.
On the other hand, if they are completely independent, then you can just use separate repositories. Then, to build some sort of master project that might use files from each repository (ie, it depends on the other repositories) then you use a submodule.
A repository being a submodule of another repository means that it depends on that submodule. Dependency-links between submodules is probably a bad idea if the API is not stable, but if the API is stable so changes in one won't directly impact the other (ie, no code changes necessary), then two top-level submodules can depend upon each other.
Now, I've been talking about submodules the whole time, but an alternative exists called "subtree" if you want to check that out to see what you prefer. Its in the contrib/ section of the main git repository so it isn't installed by default. Also there exists the subtree strategy (ProGit chapter linked to in a comment)
来源：https://stackoverflow.com/questions/10068119/git-how-to-avoid-repetitive-committing-with-sub-sub-sub-git-repos