Undo multiple commits at once (#201). Say that you trashed a post and then deleted it. To fully undo these two actions, you can now select both of them using checkboxes and restore the post in one go.

Environment tracking (#609, #459). VersionPress 3.0 tracks where a change originated, for example, in staging, production or Bob's PC. Environment names are customizable and displayed using a visual hint in the UI.

Other UI improvements. For example, the main table now displays an avatar of users who made the changes (#853) and there have been some improvements to the full diff view.

Custom merge driver was implemented to handle some tricky scenarios. The two specific improvements are:

Date modified field are now handled correctly (#588). Before VersionPress 3.0, post_modified and post_modified_gmt fields were ignored because tracking them created a lot of merge conflicts and we thought we could compute the values from Git history anyway. Unfortunately, that was not true for posts created before VersionPress was installed. VersionPress 3.0 tracks date modified's in a repo and avoids merge conflicts at the same time.

Changes on adjacent lines no longer create conflicts (#719). For example, if Alice updated post_title and Bob updated post_content, merging their work no longer creates a conflict.

Shortcodes with IDs work across environments (#654). Shortcodes like [gallery ids="2,3,4"] will now update these ID correctly across environments. New *-shortcodes.yml file format was developed to support that.

Frequent DB writes no longer create excessive number of commits (#512). Things like view counters, Akismet spam count etc. are now committed once in an hour (configurable) or before actions like cloning or merging. This avoids floods of not very useful commits.

Configurable entity ignoring and, specifically, better spam comment handling (#511). Some entities just should not be part of the repository, e.g., transient options or spam comments. Previously, some of this was hardcoded (e.g., transient options) or not handled very well (e.g., spam comments). VersionPress 3.0 introduces a better, extensible ignoring mechanism that will be user-configurable in the future.

Ignoring of specific database columns (#902). Similarly to ignoring entities (database rows), VersionPress can also ignore database columns. These columns are either plain ignored (for example, VersionPress doesn't care about option_id, only option_name) or ignored with a reference to a PHP function that computes the values (for example, post's comment_count is computed dynamically).

Initial support for custom directory layouts (#565). WordPress location, wp-content, plugins or uploads directories can now be customized. The support is initial, for example, the structure needs to be defined before VersionPress is activated, more complex setups like Bedrock are not fully supported yet, etc., but it's a good start.

Data updates via query() are now understood (#510). Previously, VersionPress handled data updates via the insert(), update() and delete() methods which are quite straightforward to support and cover 99 % of the changes. However, that last 1 % was missing, and VersionPress 3.0 adds it by also supporting the query() method.

Common (shared) config (#630). Most things in wp-config.php are environment-specific, for example, database connection, so VersionPress gitignored this file since 1.0-beta2. However, some config values should be shared, like the custom folder constants WP_CONTENT_DIR or WP_PLUGIN_DIR. So VersionPress 3.0 adds a config file called wp-config.common.php which is committed into the repository and require'd from the standard wp-config.php file.

General reliability improvements. We've improved how VersionPress stores and parses the internal data formats and added some more tests around that. VersionPress 3.0 should cover anything and everything that vanilla WordPress 4.5 does, in a reliable fashion.

Better update method that keeps the same INI files and VPIDs across VersionPress releases was added (#906). This makes inspecting history much easier. Note that this will only become useful after 3.0, for instance, when updating to 4.0. Right now, we're only shipping the necessary underlying code. There's also a convenience WP-CLI command wp vp update available (PR #931).