some notes about distributed workflows in Git

hustnzj 的个人博客 / 2 / 0 / 创建于 1年前 / 更新于 1年前

Notes

The biggest drawback of centralized workflow is to allow everyone to push to an “official” repo. It means that for anyone to contribute content, they need access to the entire project. This will wind up a mess in a large project.
The replacement of centralized workflow is distributed workflow: Everyone push the changes to their own public repo. Then you can pull their bug fix into your private repository to ensure it doesn’t contain any undeclared code. If you approve their contributions, all you have to do is merge them into a local branch and push it to the main repository. You’ve become an integrator, in addition to an ordinary developer.
Never blindly merge content from a third-party contributor. Before merging, you can use git log HEAD..<someone-name>/<batch-name> --stat to verify the difference between the local checkout-out branch and the remote corresponding branch.
For any collaborating developer, all they have to know is that the “official” master branch moved forward, prompting they to synchronize their private repo.
For any collaborating developer, if they needs to incorporate their topic branch into their master branch, they shouldn’t merge directly from his own topic branch because we could have edited his contribution before publishing it or included other contributions along with it. Instead, he’ll pull from the “official” master.
If any collaborating developer had updated master directly from his local topic branch, it could have would up out-of-sync from the main project. For this reason, the integrator workflow requires that everyone pull from a single, official repository, while they all push to their own public repositories:

In this way, additions from one contributor can be approved, integrated, and made available to everyone without interrupting anyone’s independent developments.
Using the integrator workflow, our private development process largely remains the same and just access to a few more remote repositories. While this setup forces us to keep track of more remotes, it also makes it much, much easier to work with a large number of developers. You’ll never have to worry about security using an integrator workflow because you’ll still be the only one with access to the “official” repository.Should the lead developer stop maintaining the “official” repository, any of the other participants could take over by simply designating their public repository as the new “official” project. This is part of what makes Git a distributed version control system: there is no single central repository that Git forces everyone to rely upon.