You are using the best approach. Keep your stuff on a branch. When they update their stuff, you pull in their stuff and merge into your branch. There are likely to be conflicts. You'll have to resolve them.
Now, the easiest way to do that is to structure your changes in they first place so that they are in separate files. I don't know what language, but if you have added new functions, they absolutely belong in files that are not in the upstream code. If you are MODIFYING their code, again, try to modify it so as to disturb as little as possible and jump off into your code wherever possible. On Mon, Jan 9, 2017 at 3:44 PM, Dan Morton <[email protected]> wrote: > Let's say I've got version 3.1 of some flavor of open source that I like > well enough, but I want to incorporate some of my own changes. I can fork > off a branch and commit my changes to my own local repository. > > Then, the developers of the open source release 3.2. > > What's the best approach to re-introducing the changes I made to 3.1, into > 3.2? Is there something git can do for me to facilitate this process? > > (BTW, I'm using TortoiseGit in a WAMP environment.) > > Thanks > Dan > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Matthew O. Persico -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
