Git merge with cloned projects (best practice)

Question

I'm looking for the best practice for working with GIT. Here is my problem:

I have a BASE project and, for each client, I clone it. Because those projects will be very similar (only changes some config files and images), and each web project will be stored in a different directory.

So I think the best practice is to clone the base project, make some changes and upload to the new clients dir.

Until here is all fine but: How do I merge changes if I found a critical bug or if I add a new feature to all (or to some) of the projects? Do I need to create a patch or something similar? How?

I would like, if you please, an easy understanding answer, because I am not a GIT master (but I want to learn!)

Thank you very much!

Thanks, I'm taking a look in the official doc and some examples. I'll try it at localhost and then I feedback. Thanks for your time! — Dani Sancas, Jul 11 '13 at 14:39
Feedback comes! Now I'm more used to work with GIT and yes, `git cheery-pick` helps a lot. Thanks, mate! — Dani Sancas, Jan 03 '14 at 11:51
for lazy people like me, there is twice a typo in comments above : > git cherry-pick — Nicolas D, Mar 24 '17 at 10:31

score 3 · Accepted Answer · edited May 23 '17 at 12:10

You might want to weigh your options depending on the changes in your base repository (client repositories) that you want to incorporate in some/all of your client repositories(base repository).

Assume what you want the changes to be incorporated into is a client and the changes that you want are in base. Let's say you have a remote that points to the base repository. So, in your client repo, you would:

git remote add basepro <url>

Here are some cases you might encounter:

You make a basic change/ major bug fix in your base repository that you want incorporated in all/some of your clients. In case your base repository is also local and rewriting commit history doesn't affect you in anyway, you can consider a rebase:
```
git rebase -i basepro/master
```
This will take you back to the last common commit of the base project and your client project and then apply all the commits you have made to the client project one by one. But, you might have to manually merge a few changes here and there and continue:
```
git rebase --continue
```
Rebase is your friend if you want the commit history to look as if you have that feature in the base before you started working on changes specific to the client. In your other client projects, you might similarly rebase to the branch you want to or even specific commits that you want to be rebased from.
You want only specific commits in a base repository to be applied to client repositories or specific commits of one client to be applied to another.
```
git cherry-pick -Xpatience <commit>
```
You can also specify a range of commits.
You have similar files in client1 and client2, and they are both based on a file in the base. Now, you want to merge these files in the two clients for another client 3.

In this case, you might want to use
```
git merge-file <client1file> <basefile> <client2file>
```
The merged file will be written into client1file. In this case, you have to first checkout the required files into your working tree, when you are in client 3 repo.
```
git checkout baserepo/master -- basefile
```
would checkout the basefile.
You could rely on git merge in case your base now has some features that you want in your clients and that wouldn't affect your independent development of client or in any other case where you want a branch to be merged in your current branch directly. You might want to use an ours strategy to keep client repo's changes in case of conflicts or do a manual fix, just to be sure.
```
git merge -s ours baserepo/master
```
Applying patches can also be done as explained to me in this answer:

Wow! Thanks for the post, mate. The `rebase` command looks good, maybe is a good point to work with. And, if doesn't please me, I always can use `cherry-pick`. I will take your answer as the correct one because of the extense and clear explanation. Thank you! — Dani Sancas, Jul 12 '13 at 07:17
I also found a easy working solution, at least it works with my local examples. I have BASE project and, cloned from it, CLIENT1 and CLIENT2 projects. When I do a bugfix or add a new feature, I create a `tag` from it (for example: Mytag). Then at CLIENT1 (or CLIENT2) I `fetch` from `origin` so then I can do a local merge from it's tag, because `Mytag` appears. — Dani Sancas, Jul 12 '13 at 10:39

score 1 · Answer 2 · answered Jul 11 '13 at 14:41

1

What you can do - is you can add other repositories as remotes and cherry pick changes into them.

 git remote add project <address>
 git checkout project master
 git cherry-pick <sha1>

answered Jul 11 '13 at 14:41

Ruslan Osipov

5,655
4
29
44

Let me know if I'm right: I have the BASE project and, 3 months ago I cloned it and named ROSIPOV, and continued working. Now, if I introduce a new feature at BASE and wanted it at ROSIPOV, then I must add BASE as a remote of ROSIPOV (and then checkout and cherry-pick)? – Dani Sancas Jul 11 '13 at 14:59

Git merge with cloned projects (best practice)

2 Answers2