I agree it’s a good idea to have the same code for all sites, and effectively “one branch” in that sense - copying code or cherry-picking commits to keep sites up to date is a lot of work.
I still think it’s worth considering using branches to control deployment, even then. In my experience it’s likely you’ll want the ability to deploy to just one site or the other sometimes. Here’s how that might look:
All the code for both (or all, in the future) websites lives on the “master” branch. All PRs are made to master, all new code is sent to master when it’s ready.
You also have branches to track deployment. For example those might be named “release-phm” and “release-btm”.
When you want to deploy the changes you have on master to phm, you would do:
git branch -f release-phm master
to point the release-phm branch at the latest master, and thus indicate to Travis that you want to deploy it. This is a lot less work than cherry picking, but you still retain control over which sites to deploy at which time.
Of course this is just my two cents, if you want just the one branch to deploy both (all) sites that’s do-able