4 tips for a healthy fork
Sometimes you want to use a project but you don’t really like what they have coded. Or it doesn’t have a feature you need. Or it would be so much faster without that useless feature and you need the speed. Sometimes it’s time for a fork. You should know about what a fork is right now because of how many people do cool things with forks, like my own project Terser, a fork of uglifyjs.
It is oft said that forking a project is not such a good idea. But consider for a moment the benefits of a fork, and that you, by reading this article, will be better prepared for maintaining a fork easily. It will be easy to maintain the fork so you will not waste too much time on it, unlike what people usually say. Just see if these principles make sense to you, and if so, try following them in your next fork!
Forking tips, in no particular order:
Number 1
Tip #1 is, make sure that your fork changes as little existing code as possible!
You have to write a very minimal change, in its own separate line, where you import code from another file which has the actual changes you want! You can use callbacks here for example, so your fork’s core can read and write the project’s internal variables and change behaviour as the code goes.
Minimal fork changes, means minimal merge issues when you want to update your code with the upstream changes.
Number 2
Now for Tip #2, which is to ensure that new files you create have names that the original project owner might use, so as to avoid merge conflicts. I think this is obvious so let’s move on.
Number 3
Tip #3 is to try to make the fork changes as low-level as possible, changing for example a single line in a function deep in the project. This is because low-level code is a lot more in quantity, making it harder for a conflict to land on exactly the lines around the line you changed.
Bonus points if the function you’re changing is already unit tested and is really small. If need be, go a little bit higher level until you find a really small function. Those change less often.
Number 4
Tip #4 is to use Upfork.sh to automatically update your fork. Whenever your (hopefully tiny) changes cause a conflict to happen, you get an e-mail so you can fix it!
Two features that are going to be available soon are an automatic merge of master into all your branches, so you never have to update your PR branches, and automatically testing your branch when changes are made.
Upfork enables automatic forks and that is a great way of keeping up to date with upstream. Upstream changes will find their way into your fork magically.
