CODEWITHSUNDEEP
git
Ashfame
Ashfame

Reputation: 1759

Workflow for Git fork in case of different development direction

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?

Upvotes: 1

Views: 185

Answers (2)

VonC
VonC

Reputation: 1325377

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).

Upvotes: 1

Emond
Emond

Reputation: 50682

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.

Upvotes: 0

Related Questions