This question already has an answer here:
- Forking an open source project nicely 3 answers
I started to get more and more engaged in open source development and I was wondering if there are any guidelines on how to properly document and maintain a fork?
For example, let's say you fork a project to add some specific thing to it. Maybe you do not want to send pull requests back to the original project or maybe your addition is something that won't be merged back. Now you have your version of a project which is not really yours and you probably don't want to neither maintain it nor you really understand it.
But if the original project keeps growing, it would be nice to incorporate patches and new features. So, what do you do? Rebase all the time or merge changes continuously? How do you setup your branches: do you keep master branch which is always unmodified fork of the original with separate branch for your changes?
What about documentation? You most likely want to keep the original readme, since it describes the project rather well. But you also need to specify what your fork does differently or additionally. Maybe you need to remove references to automated build servers from the readme since they relate to the original project.
It is easy to fork and change the code, but that isn't good enough. I want to hear your opinions, experiences and recommendations in regards to the proper and healthy open source development.