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:

  • Can I Branch Off the Current Branch?
  • Git, Can't clone repo on windows
  • Git removing deleted files from tracking
  • Is there a good php git client with http support?
  • no git repository but all the git stuff is there
  • Git workflow when you cant push or pull
  • Development server

    • Main repository – development’s stable version
    • Developer repositories – development repositories, one for each developer

    Testing server

    • Main repository – stable testing version. modifications are pushed from the main development repository

    Production server

    • 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.

  • How do I blow away my attempt to resolve git conflicts
  • Best way to use npm and git?
  • Removing git repository objects entirely from all branches and tags and pushing changes to remote
  • How do OpenPGP-signed git commits affect commit size?
  • How Should I use SCM?
  • Moving autogenerated build files from one git repo to another git repo
  • 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.

    Development server

    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

    Git Baby is a git and github fan, let's start git clone.