How do you keep up-to-date your fork with the NRN source preset?

[Vadorequest]

If you used one of the NRN presets to build your own app, then you might face the same questions as I do, "how do I keep it up-to-date with the preset".

I'm myself using a NRN preset for our own internal project at Unly. I use a rebase approach, where all the work I do from my Fork is applied on top of NRN. Here is my git history:

all the commits below Fix GHA - Use custom domain aliases configured in production yaml file instead of staging, when running the production workflow are from the NRN source preset branch.

This has pros/cons that are explained in: https://stackoverflow.com/questions/64483037/git-good-practices-to-keep-a-forked-project-up-to-date-with-its-source-origin-wh

And you? What's your strategy?

I believe we could share good practices and tips about that. For instance, I've configured my local git config with 2 remotes, one is the NRN source preset while the other is my own private github repository. This way, I can easily update my own Fork (and also cherry-pick/push commits to the source preset branch, but that's because I have write access there).

[samuelcastro]

The rebase strategy is great to keep the git history clean, I don't have written access to NRN but I do have on my own forked version, so I have 2 remotes one for my private project and another one my forked NRN where I rebase/merge changes from.

[Vadorequest]

Yeah, that's what I used to do too. But now I've decided to do it differently, as explained in https://stackoverflow.com/a/65066272/2391795

Basically, use merge, but do so inside a branch on the Fork, and then squash that PR to keep my Fork history clean.

[samuelcastro]

I see, usually I do git rebase -i HEAD~<number of commits> to rebase and squash.

[Vadorequest]

Yeah, it's very similar to the GitHub "squash" option when merging a PR.