You should be able to set up a CNAME for bitbucket.org in any domain you manage, but it may be more trouble than it's worth.
- It may cause a little bit of additional latency: the initial DNS lookup (for bitbucket.example.com) will trigger a second lookup (for bitbucket.org), and Bitbucket Cloud will then see the old host header (for HTTP) and issue a redirect to the correct one. (SSH doesn't care about host headers; as long as it gets an IP back from DNS, it'll connect to the right place and not get redirected.)
- The CNAME will also not affect the rest of the path, so it won't add the `/example` to the request (for, um, example).
- The CNAME will not change any ports specified. Bitbucket Server listens by default on ports 7990 and 7999, but Bitbucket Cloud uses standard ports 443 and 22 respectively for HTTPS and SSH (with the notable exception of altssh.bitbucket.org, which listens for SSH requests on port 443).
- The API is different. Bitbucket Server exposes a lot more high-level server management endpoints, but Bitbucket Cloud does not. (You probably have root on the systems where you run BB Server, but you are absolutely not getting that on BB Cloud.) There are also some syntactic differences in the API and its default paths.
- Finally, assuming the paths and ports and so forth are fine, Bitbucket's redirect will cause users to see a warning like `warning: redirecting to https://bitbucket.org/example/repo` on each push, pull, clone, or ls-remote operation that happens over HTTPS. This is harmless - most Git client software should handle the redirect without trouble - but because Git uses the term "warning" users may not respond calmly.
With all that in mind, and given Git's decentralized design, it may be best to announce a date for the authoritative version of a given repo to switch from BB Server to BB Cloud, and give people the proper new URL to use with `git remote set-url`.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.