Rebasing feature branches on rebased shared branches

These steps describe how to rebase your feature branch onto the latest version of a shared branch that itself has been rebased since you branched off. In this example, the branches are as follows:

Branch Name	Description
master	Upstream branch of both, where work is expected to eventually flow.
redocly-migration	Shared branch where work is being staged prior to a major release/revision. This branch was originally branched off master, then eventually rebased.
migrate-validator-domain-verify	Feature branch with your individual work, which was branched from redocly-migration before that branch was rebased. The goal is to create a PR that can be merged cleanly into the new redocly-migration branch in preparation for a larger review and release.

1. Fetch the latest from the XRPLF remote

   git fetch XRPLF
   

   Note, the XRPLF remote might have a different name on your machine such as origin, ripple, or something else instead of XRPLF. If you're not sure, git remote -v should show you which of your remotes points to which repos.

2. Switch to the shared branch if you aren't on it already.

   git switch redocly-migration
   

3. If you had previously checked out the branch, your local version is now "diverged" from the version on GitHub. Reset your instance of the shared branch to match the rebased remote version:

   git reset --hard XRPLF/redocly-migration
   

   As before, the XRPLF remote may have a different name on your machine such as origin.

4. Install the latest dependencies with npm. (This is best done now so you can resolve css conflicts later.)

   npm i
   

5. Check out your working branch.

   git switch migrate-validator-domain-verify
   

   Change the branch name based on your specific feature branch.

6. Start an interactive rebase on the updated shared branch

   git rebase -i redocly-migration
   

   In the editor, you should see a "to-do list" of commits for the rebase. Some commits will be ones that have been removed or squashed on the shared branch. Change pick to drop (or d for short) in the to-do list for anything that's not specific to your feature branch:

   drop 713241020d Comment out template frontmatter for Redocly compatibility
   drop 35ec03cc58 Move assets/ to static/ for Redocly compat
   drop 3edc788c92 Fix template script
   drop 1a71b230c4 Make page show up at /dev-tools/xrp-faucets
   drop 7f9542ecc2 Use React for modal form
   drop 826a1e531c Revert "Use React for modal form"
   drop 2ba8f78705 Revert "Make page show up at /dev-tools/xrp-faucets"
   drop ee0642e5be Revert "Fix template script"
   

   You can optionally take this as an opportunity to squash a bunch of your in-progress commits into a bigger, more complete commit, too.

7. Proceed with the rebase, resolving merge conflicts as they come up. A likely one is the css file (devportal2024-v1.css). If that comes up, the correct solution is to rebuild it.

   The command to build the new one should be run from the repo top:

   npm run build-css
   git add static/css/devportal2024-v1.css
   

   Only continue with the rebase after you've also resolved any other merge conflicts.

   git rebase --continue
   

8. Finally, when your rebase is done, check that the list of commits looks sensible.

   git log
   

9. Assuming it does, force-push your feature branch back to GitHub:

   git push -f XRPLF migrate-validator-domain-verify
   

   As before, you should adjust the remote name and feature branch name according to your specific case.