What's the canonical method to add in changes from the original source of a forked Git repo?

Question

For simplicity's sake, let's say I'm maintaining a fork of Bootstrap. My changes are specific to my theme, so they'll never be merged back into the original Bootstrap project, but I still want to make sure that my project has the latest changes. Over the life of the project, I'll merge in Bootstrap's changes several times.

What's the appropriate way to add in Bootstrap's changes to my fork knowing that I'll be doing so multiple times throughout the life of the project? Would constantly rebasing create issues later down the line, or would that always be the most appropriate option (assuming I want 100% of the changes in Bootstrap). How would I approach a situation where I only wanted some of the changes? Would this prevent me from rebasing in the future?

Answer 1

If you have only one machine with the fork then rebasing is an option. However if your fork have more than one machine hosting it (for example, if you share it with another developer or if you have it on Github - remember Github server is also a machine) then you should not rebase, merge instead.

Rebasing changes past git history. Git has no simple mechanism to pull past history. Which means that once you do a rebase and push it everyone else cannot do a pull. Instead they must delete their local copy and clone again.

So the rule of thumb is simple: you can only push a rebase once when initially pushing the branch. After that rebasing will screw up the repo.

Answer 2

You might be able to rebase your own changes on top of the current Bootstrap release depending on how you plan to release your changes. Rebasing the other direction (the original repo on top of your changes) will be nearly impossible.

In either direction, merging is almost certainly the best solution.

To select individual commits, or a range of commits, use git cherry-pick.