Recently released BitBucket Server and BitBucket Data Center 4.9 bring the possibility of defining a strategy for disaster recovery, setting a preferred merge strategy, and more.
Disaster recovery is supported in BitBucket Data Center by replicating a BitBucket Server primary instance to a “cold standby” instance which can be located in a different geographic area. In a typical deployment of BitBucket for disaster recovery, a number of BitBucket nodes are kept in “cold” state, while the shared file server and database are kept in “warm” state so replication can be carried through. In case of disaster, all requests can be redirected to the standby instance, thus minimizing downtime.
BitBucket Server 4.9 also allows teams to enforce their preferred strategy for merging pull requests by defining a default option. Prior to this, BitBucket automatically decided which strategy was best for a merge, e.g., by allowing fast-forward merges or forcing explicit merges. New in version 4.9, admins can define a default merge strategy as well as which alternative strategies are available at merge time. For example, if a team wants to keep a clean branch history at the expense of losing details about individual commits, they could select the squash on merge strategy, thus merging all commits in the PR into a single commit. If preference is for a linear history, a team can select a default fast-forward strategy. Squash and fast-forward strategies can also be combined together.
Additionally, BitBucket Server and BitBucket Data Center 4.9 add a way to import external repositories into a new one. Code can be pulled in from BitBucket Cloud, GitHub.com, GitHub Enterprise, and from any other HTTP-based Git server.