Reputation: 2877
We have a vendor who builds and maintains a project and shares it with us via read-only git repo. Periodically, there may be some updates in the project (bugs, policy etc) and we get notified when these get updated. However, we are adding our own custom changes to the project as well.
Here is what I was thinking:
git merge master
whenever the vendor code updates and resolve changes.Is this a reasonable approach? Is there a better one? Please note we're all noobs with git with varying level of programming experience, so ease of use is high priority.
EDIT: I just found out that we can have different remotes for different branches. This means we probably don't need step #2.
Upvotes: 1
Views: 285
Reputation: 1324837
Your approach is sound: you need two branches:
upstream/master
after a fetch from the upstream vendor repositoryorigin/master
: your own master branch pushed to your own remote repository, which includes your changes.That would use the different remotes (even outside the context of a fork)
You can reconcile the changes at any time with a git merge upstream/master
Upvotes: 1