1

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:

  1. Create my own online repository to save changes.
  2. Push vendor code as is into "master" branch in my online repo.
  3. Create a new remote branch "custom" where we make and push our changes.
  4. Run 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.

Plasty Grove
  • 2,473
  • 4
  • 23
  • 34

1 Answers1

1

Your approach is sound: you need two branches:

  • upstream/master after a fetch from the upstream vendor repository
  • origin/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

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283