I've cloned the existing www.DOMAINHERE.com to a staging site staging.DOMAINHERE.com and made changes to the staging site such as its theme, its templates, its template parts, its blocks (added customized block templates), etc...
I'm trying to push the changes to the LIVE site, but I'm not sure exactly which database tables to include without it breaking the site. The LIVE version of the site has new posts that I do not want to overwrite.
Here's a list of all the tables I currently have on the staging site (ignore "VM4414:2" and the file sizes as I just copied them via the browser console):
VM4414:2 wp_bv_fw_requests - 16.00 KB
VM4414:2 wp_bv_ip_store - 272.00 KB
VM4414:2 wp_bv_lp_requests - 16.00 KB
VM4414:2 wp_commentmeta - 48.00 KB
VM4414:2 wp_comments - 96.00 KB
VM4414:2 wp_links - 32.00 KB
VM4414:2 wp_options - 160.00 KB
VM4414:2 wp_postmeta - 48.00 KB
VM4414:2 wp_posts - 80.00 KB
VM4414:2 wp_term_relationships - 32.00 KB
VM4414:2 wp_term_taxonomy - 48.00 KB
VM4414:2 wp_termmeta - 48.00 KB
VM4414:2 wp_terms - 48.00 KB
VM4414:2 wp_usermeta - 48.00 KB
VM4414:2 wp_users - 64.00 KB
VM4414:2 wpha_bwg_album - 2.26 KB
VM4414:2 wpha_bwg_album_gallery - 2.07 KB
VM4414:2 wpha_bwg_file_paths - 45.39 KB
VM4414:2 wpha_bwg_gallery - 3.00 KB
VM4414:2 wpha_bwg_image - 27.31 KB
VM4414:2 wpha_bwg_image_comment - 1.00 KB
VM4414:2 wpha_bwg_image_rate - 1.00 KB
VM4414:2 wpha_bwg_image_tag - 25.63 KB
VM4414:2 wpha_bwg_shortcode - 24.72 KB
VM4414:2 wpha_bwg_theme - 39.62 KB
VM4414:2 wpha_commentmeta - 79.62 KB
VM4414:2 wpha_comments - 30.07 KB
VM4414:2 wpha_links - 1.00 KB
VM4414:2 wpha_nf3_action_meta - 16.00 KB
VM4414:2 wpha_nf3_actions - 16.00 KB
VM4414:2 wpha_nf3_chunks - 16.00 KB
VM4414:2 wpha_nf3_field_meta - 64.00 KB
VM4414:2 wpha_nf3_fields - 16.00 KB
VM4414:2 wpha_nf3_form_meta - 16.00 KB
VM4414:2 wpha_nf3_forms - 16.00 KB
VM4414:2 wpha_nf3_object_meta - 64.00 KB
VM4414:2 wpha_nf3_objects - 16.00 KB
VM4414:2 wpha_nf3_relationships - 16.00 KB
VM4414:2 wpha_nf3_upgrades - 16.00 KB
VM4414:2 wpha_ngg_album - 1.00 KB
VM4414:2 wpha_ngg_gallery - 3.46 KB
VM4414:2 wpha_ngg_pictures - 64.82 KB
VM4414:2 wpha_options - 2.58 MB
VM4414:2 wpha_postmeta - 980.18 KB
VM4414:2 wpha_posts - 3.11 MB
VM4414:2 wpha_redirection_404 - 112.00 KB
VM4414:2 wpha_redirection_groups - 48.00 KB
VM4414:2 wpha_redirection_items - 112.00 KB
VM4414:2 wpha_redirection_logs - 64.00 KB
VM4414:2 wpha_smush_dir_images - 77.49 KB
VM4414:2 wpha_ssp_stats - 144.00 KB
VM4414:2 wpha_term_relationships - 26.05 KB
VM4414:2 wpha_term_taxonomy - 30.32 KB
VM4414:2 wpha_termmeta - 10.06 KB
VM4414:2 wpha_terms - 44.99 KB
VM4414:2 wpha_usermeta - 49.59 KB
VM4414:2 wpha_users - 8.27 KB
VM4414:2 wpha_wpstg_queue - 16.00 KB
VM4414:2 wpha_yoast_indexable - 672.00 KB
VM4414:2 wpha_yoast_indexable_hierarchy - 96.00 KB
VM4414:2 wpha_yoast_migrations - 32.00 KB
VM4414:2 wpha_yoast_primary_term - 48.00 KB
VM4414:2 wpha_yoast_seo_links - 142.93 KB
VM4414:2 wpha_yoast_seo_meta - 15.56 KB
Sad to say, there's no clean and guaranteed-trouble-free way to do what you want. WordPress's database code creates unique id numbers for rows in its tables: Post ids, metadata ids, option ids, and so forth. When you clone a site (to create a staging site) the two sites start operating independently and you're sure to have duplicate ids.
If you're a really skilful WordPress developer / operator you may be able to get this to work. But it will be a lot of work and require a lot of testing. So, you'll have the same problem as you do now, where the production site gets ahead of the staging site while you're testing.
If this were my project I'd do one of these things.
This could be much more convenient, but sadly it is not.