@HollyTorpey_LSA I haven't tried this with a distributed or partnered collaboration yet. It wasn't an option when we first started doing this, however, I think it should be possible. I will have to give it a try this summer!
For us, most of the data on the portable Enterprise server is imagery or reference layers that are not being updated. Things we don't have to worry about syncing or copying back.
For the hosted feature layers we are actively editing in the field, we usually connect to the portable server with Pro, and copy those layers into one or more local File Geodatabases. Then, when we are back on the Internet, we use python to manage updating the permanent server with the content of those databases. (Make sure when sharing/overwriting from Pro to your permanent Online/Enterprise destination that you have editor tracking enabled on the FGDB, and remember to check the box to "Preserve editor tracking info".)
In many cases, our "authoritative" copy of the data becomes the one we take into the field. No one is editing those layers on the permanent server while folks are away. That makes it easy to truncate the tables and push the new data into its place, as we are not worried about syncing under those circumstances.
When we have had to support editing in both the field and office, we have gone the route of adding a Microsoft SQL server to the laptop and using Enterprise Geodatabases as registered Data Stores to back the feature layers. We then used two-way database replication with disconnected check-ins/check-outs to keep things in sync.
This approach is also helpful if you periodically have someone going back to civilization. They can take a copy of the replica off-site, connect to the Internet, sync the changes, and bring back updates from the office.
Note that peer-to-peer syncing can become time-consuming when you have more than a few folks in the field, given the number of individual syncs required to get everyone up-to-date.