Pushing to prod PR#410 onward

[validbeck]

Internal Notes for Reviewers

• Styled screenshots & cleaned up current screenshots #420
• Added currency field type to inventory field docs #423
• Preview of Generate with AI docs sections #419

[github-actions]

A PR preview is available: Preview URL

[validbeck]

@nrichers No merge conflicts this time but the history between prod & staging still retains changes from previous to merge: prod...staging

Is this working as intended?

[nrichers]

@nrichers No merge conflicts this time but the history between prod & staging still retains changes from previous to merge: prod...staging

Is this working as intended?

How did you merge your previous PR into prod? If you squash merged, I think this might be working as designed. The commits from the previous PR would have been squashed down, leaving only a single commit.

Note that nowhere in our release process do we require you to compare branches to make sure that commits that were merged into main and staging are also present in the PR to merge into prod. I know this sounds counterintuitive, but trying to make comparing git histories part of the release process is not the way to go.

If you really are curious, I would recommend experimenting — it's good to learn more about how git merges work, but I would create another prod-test branch and try out the different options that are available:

[validbeck]

If you squash merged, I think this might be working as designed.

Ah yes, that's what I did. No squash would fix this then? I will try that next time and see what happens. Just want to make sure I understand what's happening under the hood.

[nrichers]

Ah yes, that's what I did. No squash would fix this then? I will try that next time and see what happens. Just want to make sure I understand what's happening under the hood.

"Fix" would imply something is broken — it isn't. You CAN squash merge but it will behave differently than if you created, say, a merge commit. If you squash, the next time you go to merge, GitHub will look at the commit history in staging and prod and see that there are commit SHAs in staging that aren't enumerated in prod, so it's going to add them to the list for reference. It has no effect on the changes that get merged in, though, you're still safely merging one branch into another.

Note also that if you change the merge method for one PR in your browser, you might have to remember change it back for the next PR, or you're going to add merge commits to our history in main. Again, not something that needs to be fixed, just something to remember.

For reference, we use --merge to create a merge commit whenever we merge main into staging. I did this to preserve the commit history, but if the histories end up becoming an ongoing issue, I might suggest we squash merge into staging and sidestep the issue altogether. You can always run a git diff on branches instead if you want to know if there are file differences.