I started down a similar path about 9 month ago when I started at the Salesforce.com Foundation and was tasked with building the continuous integration architecture for the next major version of the Nonprofit Starter Pack. We're now at the release phase of the development process and have confronted a lot of the questions you pose.
Before diving in on the specific questions, I wanted to point to a few resources from our project which might help:
I created the following documentation a few months about about our process and setup. It's evolved quite a bit since then and I intend to update the docs over the next month or so to reflect the new process:
http://developer.salesforcefoundation.org/CumulusCI/
There's also this webinar with more detail on the process and (hopefully) a better explanation of the diagram in the documentation:
http://www.youtube.com/watch?v=Cm42ZF5MrLA
You can also see the whole process in operation along with all the build scripts we use:
https://github.com/SalesforceFoundation/Cumulus
http://ci.salesforcefoundation.org
Are you already using Git and which experience and best practices can you share?
We use mostly a variant of GitHub Flow rather than git-flow. We use one master branch (which we name "dev") and feature branches for all development. Pull requests in GitHub are how a feature branch gets into dev. We use a script to copy the merged code from dev into all open feature branches after it passes build. This keeps feature branches up to date with the dev branch.
Our project is open source so we have our internal developers work in the main org repository but anyone can fork the project, create a feature branch, and submit a pull request back to us.
Are you using separate repositories or branches for Patches / patch orgs?
Our main goal is to have such a frequent release cadence that we hardly ever need to worry about patch orgs. If you're releasing a new version every 2 weeks, patches are the exception.
If we need to create a patch, we use a patch org and a branch dedicated to the patch. We then create a pull request to merge the hotfix changes from the patch back into the main dev branch.
Are you using feature branches?
Yes. We do all development in feature branches. We also test every commit to any feature branch with a complete deployment to a shared feature org. One challenge of this approach has been to ensure the org is cleaned out as different feature branches can contain different metadata.
How mature is the eGit tooling in the Force.com IDE (=Eclipse)?
Some of our team members have been using eGit and are quite happy with it. I still do my development in vim, command line git, and ant though so others might have more to say here.
Any positive or negative experiences with Github as private repository provider?
We started our project with a private repository which eventually became public. I can't think of any issues I've run into with the private repository or GitHub. All in all, we designed a good bit of our process around some of their features on top of git (pull requests, commit status api, etc).
How to you bridge the gap between Eclipse having a seperate project per patch and Git working with potential switchable branches.
This varies mostly by project and developer preference. A developer who is more comfortable with git branching will likely be more comfortable working in one project. My experience is more with switching between feature branches rather than patches though.
All our devs do all their development against their own DE orgs using whatever tools they want. When they are comfortable with their changes, they push them to the feature branch in GitHub where their code gets tested by the build system. The push is essentially the only defined interface between the developer's local environment and process and the rest of the team.
Could you get merging and diffing work between trunk and branches
Pull requests have been incredibly reliable to merge feature branches into our dev branch.
One thing that has helped a lot is using an automated script to push dev changes back into all open feature branches. Consider this scenario:
Developer A is working on branch feature/1. They complete their work, submit a pull request to merge branch feature/1 into branch dev, and the request is accepted. At this point, the dev branch contains feature/1.
At the same time, Developer B has been working on branch feature/2. When they created feature/2, it was in sync with dev but is now out of sync as dev has new changes.
When Developer B goes to push changes to GitHub, they are not notified that there have been changes to dev which they need to incorporate into their branch. Their push is tested against dev + feature/2 but does not include changes from feature/1. The longer running the feature branch becomes, the more changes it becomes out of sync with.
By automating this process, #3 changes to Developer B goes to push changes to GitHub but the push fails telling them there are remote changes in their branch which they need to first pull. If there are any conflicts, the developer merges them with their changes locally and pushes the merged code. Their commits then get tested against dev + feature/1 + feature/2
Do you also store your git repository in the eclipse workspace project folder (although this is not recommended)?
We store the local cloned repository in the eclipse workspace and have not noticed any issues from it.
