How are you structuring your Git repository workflow?

Question

We've seen and watched the videos on how large distributed teams are using Git, but what about those of us who aren't distributed and who work in the office with the rest of our team? How should we be structuring our repository(ies) and our workflow?

Think about the traditional office which has been using Subversion or CVS as the single point of authority. Certainly these teams could each maintain their own Git repository and push/pull between each other as necessary, which would quickly turn into a nightmare in many situations. Or, they could each maintain their own repository and sync with a single repository that's known as the "master" for the team. Or, there could be any combination of workflows with the possibilities a DVCS opens up.

How does your team work? What have you found to be a useful workflow?

Answer 1

I like the way the Yahoo! User Interface (YUI) team appears to be working. I am not at Yahoo, nor am I on that team, but their git commit logs reveal a lot about their process.

The YUI team maintains a central repository where everyone on the team has commit access. Periodically after commits to this repository (it might be after every push, but I don't think so), the build system fires, rebuilds YUI and pushes a newly tagged commit to github, where the community can fork the code and work on it.

I am in favor of the central repository that represents the "official" status of the project. Certainly, if I want to share code with a co-worker, I can arrange for them to pull a branch from me, and we can collaborate that way.

The "master" repository offers other advantages as well, such as ease of continuous integration, as the push/pull triggers can be configured on the 'master' repository to fire off the unit tests and build system. It also ensures that everyone knows where the most recent 'known good' version of the repository is, so that if the project needs to be built, published, or tested, there can be reasonable assurances that the 'master' repository is ready for that.

Git will support almost any workflow you can think of, but even among a small team, you don't want there to be a question about where the 'official' repository is. The maintenance nightmare that could lead to, particularly as you approach a release, would be unpleasant.

Answer 2

take a look at nice blog http://nvie.com/git-model and comments