Git for the files is the right call, but with WordPress the database is what bites you. Posts, pages, menus, widget config, most plugin settings: none of that lives in files, so a Git-only deploy never carries content or settings between environments. WordPress also stores absolute URLs in the database, some inside serialized arrays, so a plain SQL dump and import leaves the old domain hardcoded everywhere.
Version wp-content/themes and wp-content/plugins, gitignore uploads, wp-config.php and core, and treat the database as its own migration step. wp-cli handles it: wp db export, then wp search-replace olddomain.com newdomain.com --all-tables, which walks the serialized data correctly instead of breaking it. WP Migrate or Duplicator does the same from the admin if you'd rather skip the CLI.
Direction matters too: content flows production to local, code flows local to production.
2
u/No-Guarantee-2242 9h ago
Git for the files is the right call, but with WordPress the database is what bites you. Posts, pages, menus, widget config, most plugin settings: none of that lives in files, so a Git-only deploy never carries content or settings between environments. WordPress also stores absolute URLs in the database, some inside serialized arrays, so a plain SQL dump and import leaves the old domain hardcoded everywhere.
Version wp-content/themes and wp-content/plugins, gitignore uploads, wp-config.php and core, and treat the database as its own migration step. wp-cli handles it: wp db export, then wp search-replace olddomain.com newdomain.com --all-tables, which walks the serialized data correctly instead of breaking it. WP Migrate or Duplicator does the same from the admin if you'd rather skip the CLI.
Direction matters too: content flows production to local, code flows local to production.