多开发人员Git工作流程，保持干净的历史记录

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 (eg 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 (aka 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

Answer 2

我认为没有理由说这个工作流程对你不起作用：强调公众可能是因为对于一个公共项目来说，保持一个干净，不可改变的历史更为重要。

Answer 3

A couple of disadvatages:

The blessed repo will rather quickly (depending on how many developers and features) be cluttered with many branches. It's more clean if it only contains eg master and develop, than master, develop, featureA, featureB, featureC .. etc. However you can always clean up the repo by deleting them on the remote (git push origin :featureA) but it adds extra clean up work.

Also, when people fetch from the blessed repo their repos will contain remote references to all those branches and when you remove the remote branches, they will have to "git remote prune origin" off and on to clean up references that are no longer valid, which also adds extra work.