I'm a team leader in our web development company, and I'd like to implement Git workflow in our team. Reading documentation and articles I've found the following structure good for us:

We have a repository in a Bitbucket. **Master** branch is considered to contain stable code only. Every dev must create his own branch and implement features/bugfixes in his **own** branch. Once he decides, that his code is ready, he creates a nice branch history (using rebase, amend, cherry-pick etc.) and pushes it to Bitbucket, where creates a pull request to master branch. QA verifies functionality and approves (or disapproves) it, then I'm verifying code and if it is ok, I merge his work into master (by fast-forward or rebasing for better commits history).

But this scheme is good only in a case, when single developer works on a branch. In our case we almost always have two developers for one branch, since one developer is working on *server-side* (PHP), and another - *client-side* (HTML/CSS/JS). How these two should collaborate in a way, that commit history in master stays clean?

Server dev creates basic structure of HTML files and client dev needs to get this structure. Logically would be for server dev to create a branch, and for client dev to create his own branch, based on server dev branch. But this means, that server dev needs to *publish* his branch in Bitbucket, which will make it *impossible for him to rebase or change commits*, that are already published.

Another option is to wait, until server dev finishes his work, publishes branch with nice commits history and forgets about it, and only after that client dev starts to work in this branch, but this will cause time delays, which is even worse.

How do you handle such a collaboration in your workflows?