Proper git workflow scheme with multiple developer

Question

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?

Answer 1

I can't really speak to the merits of the methods described in your post, but I can describe how we solved collaborative coding in the workflow we use at work.

The workflow we use is one of many branches. Our structure is thus:

Master is golden; only the merge master touches it (more on this in a bit).

There is a dev branch, taken initially from master, that all devs work off. Instead of having a branch per developer, we make feature, or ticket, branches from dev.

For every discreet feature (bug, enhancement, etc.), a new local branch is made from dev. Developers don't have to work on the same branch, since each feature branch is scoped to only what that single developer is working on. This is where git's cheap branching comes in handy.

Once the feature is ready, it's merged locally back into dev and pushed up to the cloud (Bitbucket, Github, etc.). Everyone keeps in sync by pulling on dev often.

We are on a weekly release schedule, so every week, after QA has approved the dev branch, a release branch is made with the date in the name. That is the branch used in production, replacing last week's release branch.

Once the release branch is verified by QA in production, the release branch is merged back into master (and dev, just to be safe). This is the only time we touch master, ensuring that it is as clean as possible.

This works well for us with a team of 12. Hopefully it's been helpful. Good luck!