Fix readme.dev to our fork workflow about tulipaenergymodel.jl

[abelsiqueira]

Maybe relates to #676

[gnawin]

@clizbe I have my fork named "fork", and the remote named "upstream", as this is easier for me. The naming seems to me is just a user choice. So, as you've shown, you can even have two names for the remote, didn't know that before...

[clizbe]

I think the difference is that you keep your personal remote fork (gnawin/TEM) up to date and fetch/pull from there. Whereas I fetch from the main remote repo (TulipaEnergy/TEM) and my fork is completely behind, but I push my branches there before making a PR. They're about the same, it just depends if you pull your updates from your own fork or the main repo. If you pull from your own fork you have to keep it up to date as well. 🤔

But I could be totally wrong - I think upstream is where your default fetch is from.

[gnawin]

I think the difference is that you keep your personal remote fork (gnawin/TEM) up to date and fetch/pull from there. Whereas I fetch from the main remote repo (TulipaEnergy/TEM) and my fork is completely behind, but I push my branches there before making a PR. They're about the same, it just depends if you pull your updates from your own fork or the main repo. If you pull from your own fork you have to keep it up to date as well. 🤔

But I could be totally wrong - I think upstream is where your default fetch is from.

Yeah, it just depends on where you pull your updates from. In readme.dev, it says
git merge --ff-only origin/main. In my case, I just changed my remote name to upstream because I don't like origin, so my own workflow is git merge --ff-only upstream/main 😄 . So our workflows are the same, just with different names for the remote (meaning that my fork is also very much behind).