1

Situation is we have a product that we build for masses, we have it on a GIT repo (lets call it upstream). One of our client wanted a customized version of the product, so we forked it and kept it in a diff GIT repo (lets call it origin).

Idea is to lead origin repo in its own development direction for client customization and yet continue to receive updates from upstream.

I have added the upstream as a remote to my local repo where I am developing it, and I am aware that I can pull updates from upstream, merge them or whatever seems fine but I would like to hear from someone who has done this or do it to make the workflow smooth and any possible pitfalls to avoid?

Edit: Would fetch-merge workflow handle well like the same changes in both repos? Like the work has already began in fork and a few things I fixed in origin itself, but I would need the same fix on upstream too. So should I just make another commit on upstream to fix that and git can detect the similarity when merging them next time for updating fork or I should have committed that fix as a separate commit even if it qualifies for the work commit I did? My concern is more like how can I make this process work with least friction.

Another question: Using cherry-pick seems like a good idea on small changes. Thoughts?

Ashfame
  • 1,731
  • 1
  • 25
  • 42
  • That seems pretty much as you said. You keep `fetch/merge`ing from upstream into your origin. Occasionally, you will have conflicts that you need to resolve. – Shahbaz Aug 01 '12 at 10:06
  • @Shahbaz I added a question, can you check? – Ashfame Aug 01 '12 at 10:15

2 Answers2

1

Avoid cherry-picking if possible, because of future merge issue (as mentioned in "How to merge a specific commit in git")

cherry picking a commit from one branch to another basically involves generating a patch, then applying it, thus losing history that way as well.

This changing of commit IDs breaks git's merging functionality among other things

Try to isolate changes you know you will need to apply to the other repo in their own commits, in order to apply only those changes.
Then a git fetch, followed by a rebase of your branch, is the best way to include in your branch history the commits from upstream.
This is similar to the workflow described in "git workflow and rebase vs merge questions" (see the update section).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • If I have got it all right, I should rebase my modifications on upstream's master everytime I want to pull in changes. Correct? And should I need to take care of anything so that I can minimize my chances of collisions? – Ashfame Sep 11 '12 at 22:14
  • Rebase is best (if you don't have pushed your work already): if your commits are in the right order, you can rebase those on top of the fetched upstream. That would make applying your specific changes trivial. – VonC Sep 12 '12 at 06:07
  • Its not a public repo, so I don't need to take care of people fetching it, just needed something that works. Thanks! – Ashfame Sep 12 '12 at 06:10
  • The issue with rebasing is that you will have a hard time finding back versions that you already shipped. Tags, for instance, will be useless as they will point to commits that may not exist anymore (IDs would have changed because of the rebase). – sylvain.joyeux Sep 12 '12 at 06:16
  • @sylvain.joyeux I agree, that why I would recommend that only for local commits, not for commits already pushed. – VonC Sep 12 '12 at 06:22
  • I understand that rebase changes history, but like I said, this is not a public repo, and customizations are not that heavy. But that got me curious, what should be the updation strategy for a public repo when even people are tracking the forked version? – Ashfame Sep 12 '12 at 06:53
  • @Ashfame for forked repo, the idea is a contributor rebase in his/her own repo before making a pull request: the contract is for the original repo to be able to apply (merge) the pull request in a fast-forward manner (ie: only *new* commits are integrated in the original repo, because the forked repo has rebased its work on top of the original repo latest commits) – VonC Sep 12 '12 at 06:59
  • Yep but my question revolves around maintaining a fork so that I can still pull updates in my customized version that I use. I don't need to send pull requests here, but I understand your point, totally valid. – Ashfame Sep 12 '12 at 07:06
0

To avoid cherry-picking you might need to take a good look at the design/architecture of the system. The more it is split into functional modules, using a plug-in mechanisms etc. the easier it might be to add features and updates to both branches.

If the system is not neatly split into modules, no git workflow will solve your problems during merges and merges will become more and more complex.

Emond
  • 50,210
  • 11
  • 84
  • 115