2

There are some child projects: "Project 1", "project 2" and so on in the future.

Also, There is a project that named: "Base Project" and it's foundation of other projects. "Base Project" is a content management system (CMS).

All projects have their own git repositories.

"Project 1" , "project 2" and others uses "Base Project" to develop and grow.

There are some methods in git like submodule or subtreemerge. but don't seem to fit here. "Base Project" not should be clone into a sub directory. It's in root directory. It's growing in "project 1" or "project 2"...

When I work in child projects, I have to be able to push "Base Project" changes separately to It's own repository to fetch in other children.

What can I do?

Vahid Hallaji
  • 7,159
  • 5
  • 42
  • 51

1 Answers1

3

Subtree merge or submodules are for a component-based development: two different but coherent set of files combined together.
Each set of files is in its own directory, because they can be branched or labelled independently (submodules), or together (subtree merge, while keeping the ability to get back an history of their own).
Both are requiring a separate directory though.

But what you are describing ("Base Project" is in root directory, growing in "project 1" or "project 2") is about a system-based approach: all components merged into one large component: one large set of file which will always evolve together, as one unit.
So you can have one branch per project: branch1 for CMS-projet1, branch2 for CMS-project2, and so on.

But if you need to report projectx-specific modifications or CMS-specific modifications back to their original (and separate) repos, then make said specific changes in dedicated branches, and then combine those changes:

  • branchp1 would be for changes affecting project1
  • branchc1 would be for changes affecting CMS
  • branch1 would be the result of the merge from branchp1 and branchc1

(same thing for branch2)

You can then export those changes as patches:

  • from branchp1 to project1 repo
  • from branchc1 to CMS repo

The inconvenient is that Git won't remember what has already been merged back to the original repos, but that would allow you to report the common history developed in your CMS-projectx set of files back to your original CMS and projectx repos.

Note: if you don't want to manage 2 extra branches, another solution is to:

  • make sure each commit only include CMS modification OR project modification
  • leave a commit message which helps to distinguish them ("[CMS] my CMS modification comment...", or "[Project1] my project1 modification comment..."
  • use the script git-extract-patches to export as patches only the right commits.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Example of patch export (as mentioned in http://stackoverflow.com/questions/10722650/export-specific-git-commits-as-patches): https://github.com/amenk/SelfScripts/blob/master/git-extract-patches – VonC Nov 25 '12 at 21:15
  • Thank you for full answer @vonc :) I think it should be a way to solve this problem. Can you please explain me a little about how do you push only some changes to a specific branch? for example `A file` should push to `branchp1` and `B file` should push to `branchc1`. After pushing `A file` to It's branch, When try to commit `B file` to `branchc1`, It makes `A file` to push to the `branchc1` too. I have problem understanding here... – Vahid Hallaji Nov 25 '12 at 21:24
  • @Hallaji basically, each time you make a CMS modification, you rebase the CMS branch `branchc1` on top of `branch1`, switch to it (checkout), make the modification(s), commit, switch back to `branch1` and merge `branchc1` to it. Now, I realize it is convoluted, so an easier solution would be to keep on `branch1`, and cherry-pick the right commits to `branchc1` or `branchp1` depending on the nature of each commits (see http://stackoverflow.com/a/13524494/6309 for more on cherry-picking). The idea remains: having two branches recording CMS or project specific commits. – VonC Nov 25 '12 at 21:31
  • @Hallaji If you have those branches in addition to your regular `branch1`, then you can export those commits as patches, and apply them on the respective repositories (CMS and `project1`). If you have only one branch per project, then commits of different nature are mixed-together, and that doesn't help for export them back to their initial repo. – VonC Nov 25 '12 at 21:32
  • It's so helpful @vonc . Thanks – Vahid Hallaji Nov 26 '12 at 07:57
  • @Hallaji Note: I have edited the answer to include a similar solution which doesn't involve two extra branches. – VonC Nov 26 '12 at 08:41