A multi-developer Git workflow, maintaining a clean history

Question

Sandofsky advocates being very strict about your 'main' repo's history, keeping it clean without cluttering it with branches and checkpoint commits.

You should never merge a private branch directly into a public branch with a vanilla merge. First, clean up your branch with tools like reset, rebase, squash merges, and commit amending.

Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable.

This appeals to me, and I was planning on implementing a workflow where my colleagues each have their own remote repository to push to, and do a pull requests when they've finalized work on a branch and cleaned up the commit history. Subsequently I (the 'integration manager') merge those clean commits into the general development branch.

I guess this approach means that the blessed repo will not have any branches other than the master and develop branch. Feature branches will only exist in your local repository -- if collaboration on a branch is needed, this can happen by pushed the branch to the remote repository of one of the collaborating employees.

However, the Pro Git book describes this as a workflow for "public small projects". Does this mean it's better to use a different workflow in our case, like pushing the finished branches to the blessed repo instead of to a personal repository?

To be clear: I'm not out to add unecessary complexity or overhead. My goal is to establish a workflow where me and my colleagues can work asynchronously, I can review their work when they're done, and bounce it back with comments or merge it into the code base if all is well.

---

Edit: Apparantly the question asked was not clear, so I'll try to summarize it:

Would there be a disadvantage in having my colleagues push their branches directly to our blessed repository (e.g. would it 'pollute' its history in some way)?

Answer 1

I believe Gitolite's "personal" branches may suit your needs very well. It is like having a personal area (a.k.a. namespace) where each developer can (even forcibly) push. On the contrary, master is read-only for all developer but an integrator.

If Alice's .git/config contains the following configuration:

[remote "origin"]
        url = git@server:project
        push = +refs/heads/*:refs/heads/personal/alice/*
        fetch = +refs/heads/master:refs/remotes/origin/master
        fetch = refs/heads/personal/alice/*:refs/remotes/origin/me/*
        fetch = +refs/heads/personal/bob/*:refs/remotes/origin/bob/*

then Alice would see

• her branches on the server as origin/me/branch, and
• Bob's branches as origin/bob/branch.

This way, Alice can:

• work on her branches and pull/push them to the server
• start a new branch off of master
• start a new branch off of Bob's branches
• make a backup of her work by simply pushing on the server.

Gitolite can be configured such that Alice cannot write on Bob's personal space and vice-versa:

@users = alice bob
@integrators = john
@repos = repo1 repo2

repo @repos
    RW+                         = @integrators
    RW+     personal/USER/      = @users