Git first steps – setting up repositories
I work in a small development office, with 7 programmers, and we’re currently implementing Git version control — we had no version control system before. Better late than never, right?
Having said that, we’re thinking about implementing the following structure:
- Main repository – development’s stable version
- Developer repositories – development repositories, one for each developer
- Main repository – stable testing version. modifications are pushed from the main development repository
- Main repository – modifications are pushed from the main testing repository
Is this structure appropriate or am I missing the point of distributed version control systems? Can someone throw me some pointers or practical examples?
I appreciate all of your feedback, guys – things are clearer now. I understand that a structure like developer repos (local), development (bare) repo, testing repo and production repo would be a more logical choice and I can even see why some consider the development repo an unnecessary step.
I guess we’ll do some tests and see which structure we like the most.
3 Solutions collect form web for “Git first steps – setting up repositories”
This is more or less about it. These are somethings you should note though:
- Make the “Main repository” on development server a bare repository.
- The developers don’t need to have a repository for themselves on the server, but they have a copy of the main repository locally on their own computers.
- Every developer should fetch/merge from the main development repository and resolve conflicts before pushing back.
- Don’t push to the test and production servers. From those repositories, fetch and merge from development and test servers respectively. This is because those repositories are not bare, and may in fact have commits of their own.
- Have one guy (or one of the developers) responsible for fetching changes from the test/production servers, merge them with the current stable and push them to the main repository. This way, bug fixes in the test server are merged back in the development.
Here’s what I’d suggest:
- Have a bare repository on some of your servers. It’s the repo that everybody would be pushing at/pulling from ; you won’t work in it. You can see it as the server on a centralized SCM.
- There’s no need to have a development server. Each developer will have his own copy of the repositories on his local computer.
- In the testing server, there will be copies of the repos. You usually won’t have to push from it since all you work is done from your computers.
- The same thing applies for the production server.
Concerning the way you’ll use Git, aka workflows, I suggest a basic one I have explained in this answer.
Main repository – development’s stable version
Developer repositories – development repositories, one for each developer
I don’t think each developer need their own repo on the server. They just need clone the repo to their own computer.
Also, not all developers should have the access to push to main repo. Only the team lead should have push access to main repo