Proper git workflow scheme with multiple developers working on same task

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!

I think still nobody actually answered the original question of how to collaborate in topic branches maintaining a clean history.

The proper answer is sorry, you can't have all that together. You only can groom your private local history, after you publish something for others you should work on top of that.

The best you could do in your particular case where server dev doesn't care about client dev changes is to locally fork client branches from dev/feature ones and rebase that part on top of server work just before finishing the feature —or relax your constraints and switch to a different workflow, as you did ;)

We have a principal repository and each developer has a fork of that.

A branch is created principal/some_project, the same branch name is then created on each developers' fork, fork/some_project.

(We use smartgit and we also have a policy that remotes are named 'principal' and 'fork' rather than 'origin' and 'upstream' which just confuse new users).

Each developer also has a local branch named some_project.

The developers local branch some_project tracks the remote branch principal/some_project.

Developers do their local work on branch some_project and push-to to their fork/some_project, from time to time they create pull requests, this is how each developer's work gets merged into principal/some_project.

This way developers are free to pull/rebase locally and push to their forks - this is pretty much the standard fork workflow. This way they get other developers' commits and may from time to time have to resolve the odd conflict.

This is fine and all that's needed now is a way to merge in ongoing updates that appear in principal/master (for example urgent fixes or other projects that are delivered before some_project is finished).

To acomplish this we designate a 'branch lead' their role is to locally merge updates from master into some_project using merge (not pull, rebase) in SmartGit. This too may sometimes generate conflicts and these must be resolved. Once this is done that developer (the branch lead) force pushes to their fork/some_project branch then creates a pull request to merge into principal/some_project.

Once that pull request is merged, all of the new commits that were on principal/master are now present on the principal/some_project branch (and nothing was rebased).

Therefore the next time each developer is on some_project and pulls (recall, their tracked branch is principal/some_project) they'll get all of the updates which will include the stuff merged from principal/master.

This may sound long winded but it's actually fairly simple and robust (every developer could also just merge locally from principal/master but it's neater if one person does that, the rest of the team live in a simple world much like the single developer workflow).

which will make it impossible for him to rebase or change commits, that are already published.

This depends on your audience. "Server dev" can push the "basic structure" to Bitbucket so that "client dev" will have access to it. Yes this does potentially mean that others will have access to these "temporary" commits.

However this would only be an issue if another user branched from one of these commits before they were rebased. On a smaller project/smaller userbase these temporary commits might never be noticed even before the rebase occured, hence negating the risk.

The decision is yours if the risk of someone branching from these temporary commits is too great. If so then you would need to perhaps create a second private Bitbucket repo for these private changes. Another option would be to do merge commits instead of rebasing, but this is also not ideal.

The rules to remember are:

• Have 1 master and 1 develop branch
• Have feature branches spawn off of develop branch
• Every time you have version ready for QA to test, merge into develop
• Have release branches spawn off of develop branch
• Make bugfixes into release branches
• When you have version ready for QA to test, merge into develop
• When you have version ready for PRODUCTION, merge into master, and create a tag for it

Following diagram is the bull's eye strategy followed in teams across the world (Credit: taken from here):