GIT Patches - or - Push?

We are considering 2 ways for working with git in a new project :

1. Developers sends patches to maintainer ( which will probably end up being one of the developers ) , he apples those, test and integrate

2. Developers pushes their commits to the public "developers" branch ( branch for each sub module of the project ) , maintainer gets mail notification about the push, and can review\test\integrate.

The end result is the same - a based-on-latest branch that contains the developer commit.

So - my question is, which is better ? should I use in a non-open source project developers by a small group ? ( sounds w开发者_开发百科eird to me sending patches in mail to the guy sits next to me )

---

Why not submit pull requests and process those instead? That is what they do with the linux kernel.

The major problem with the public shared developers branch is getting stuff you don't want off the branch. You don't want to rebase a published shared branch and reverting all of the time is ugly. The major problem with normal patches is that the SHA don't match up between the sender and the receiver for the same patch (for good reasons). If I were developing a patch-mail system I would consider using git-bundles to get those SHA exact. Note this is a complicated way of doing a pull.

Another option is to use gitolite (to enforce who is and is not allowed to commit on the shared branches) and have developers work on "feature" branches (see http://nvie.com/posts/a-successful-git-branching-model/ and the associated gitflow command) and only let the trusted dev do the merge from the feature branch to the dev/master branch.

You could also look into gerrit and other git code review workflows.

---

The correct way is forking. That means that the developers clone the repository, do their work and after they finished they will somehow contact the project maintainer so that he can pull the new branch from the foreign repo.

Github supports this already in it's UI.