I'm having problems with this situation:
I have a base repository that contains a 'docs', 'layout', 'pub' and 'sql' folder, there is just a blank 'index.html' in the 'docs' and 'layout' folder. In the 'pub' folder I have Joomla installed.
When I have a new client I make his directory and init a repository, then I add a remote named 'base' pointing to the base bare repository (the one with Joomla), fetch it, checkout base/master and then do 'checkout -b master' to create the master branch from the base's master branch. The开发者_高级运维n I make a 'clone --bare' of the client's repo in my local server and clone from it in local workstations. We save docs when needed, the designer makes the layout then it's commited and pushed to the client's bare repo. We always do a 'rebase origin/master' before pushing, to make sure the local repo is up to date.
So when the layout is done and pushed, I pull it and start to make the Joomla template. So I make lots of commits, then I realise that I have to make changes in a Joomla component. Ok, I change the component, commit and continue making the template, commit, ...
Now I want to bring all the Joomla component's commits to the 'base repo' because I want all my clients to have the same changes. When I tried @jleedev solution (rebasing), all my client's commits went to the top, rewriting it's SHA's that were already in the client's bare repo.
The basic idea is to have the commits of files in the 'docs', 'layout', 'pub/templates/client_template' folder and maybe some Joomla hack just for that client unique to the client's repo, but all other commits I would like to have in the 'base' Joomla repo too so I can merge into all clients repos.
Any ideas? Maybe a different organization?
Thanks in advance!
So when the layout is done and pushed, I pull it and start to make the Joomla template. So I make lots of commits, then I realise that I have to make changes in a Joomla component. Ok, I change the component, commit and continue making the template, commit, ...
Now I want to bring all the Joomla component's commits to the 'base repo' because I want all my clients to have the same changes
So you have two set of files for two different purpose.
I would keep those two separate (i.e. one not being included in the other), with the Joomla component part as a submodule.
- You can modify a submodule directly in the client's repo, and then push it to a central repo
- You can update your clients repos with the latest revision of that Joomla component.
The other directories would remain client-specific.
Maybe you could do the changes you want all clients to have directly in your Joomla base repo. And then merge that into all client repos.
Edit: This would require you to decide before every change in the Joomla components if you want the change to be available to all clients or if it's just a client specific change. Maybe that isn't always easy to do.
I think this problem is outside the scope of git.
I'd say you should always keep the 'common base' common for all projects.
If one project requires a specific hack, you should try and make so that it doesn't affect other repos. For example, make it off by default, and only on for that certain website.
One way to force yourself to do that is have them all use the exact same "common" repo; not a clone of it. You can use symlinks for the base/common code base, for instance.
To get what you have now into base/master, you could try this: In a client repo, create a "base" branch at base/master. (git checkout -b base base/master). Then cherry-pick the joomla commits you want to push back into the base. Then push base to base/master.
You might end up with a tricky rebase if you try to rebase master onto the new base/master, though, since the commits you cherry-picked will be in a different order. Not sure what to do about that.
There are tricks for keeping two separate trees in the same repo; maybe this is what you should use. Read http://progit.org/book/ch6-7.html and see if that idea could work for your situation, where you want to keep a slightly modified Joomla and various other repos.
This question seems almost like an inheritance problem (with respect to your organisation).
Similar to what hasen j said, you need a base that contains everything that's in common, and then branch out from there - if you have a specific structure for some of your client's websites that is not in others, you'll use a sub-base git repository to represent the common functions among that specific subset.
That way, if you want to make a change to all repositories, make it through the base repository. If you want to change a specific subset, change the sub-base repository created for that subset.
精彩评论