What is the ideal Git workflow for our 2-person web team?

Question

We are looking to use GIT to help manage our web files as we have just hired a second developer.

We won't be using GitHub but we do have an NAS drive(shared drive) so our initial thoughts are some sort of plan like this:

• DVCS (Root)
  • master (NAS)
    • project 1
    • project 2
  • developer1 (NAS)
    • project 1
    • project 2
  • developer2 (NAS)
    • project 1
    • project 2
  • developer1 (local workstation)
    • project 1
    • project 2
  • developer2 (local workstation)
    • project 1
    • project 2

So basically each developer would clone the master project repository to their developer repository (quality control), then they would clone this developer repository to their local repository. They would make their changes/edits and then commit and push these changes back to their developer repository for a senior developer to approve. Once they do this would be then pushed to the master.

I am not sure if this is the correct approach or whether I should be using branches or i need a different workflow instead?

Answer 1

There's no "right" answer to this question. The right workflow is whatever works for you and your team.

Having said that, if you only have two developers, I'm not really sure why you feel you need more than one bare repository. The easiest thing to do in this case is:

1. Have one central repository on your NAS.

   • A master branch for integrating development code.
   • Feature branches where the developers work on topics to merge into master.
   • User-private branches where the developers can push stuff for backups or cherry-picking, but where rebasing or forced pushes can happen freely.
   • Stable branches for released code, if that fits your model. Some shops just need tags on master if they do continuous delivery.

2. Developers store clones on their workstations, rather than on a network drive.

   • Offers redundancy if the NAS loses data or goes offline.
   • Allows throw-away branches that aren't stored centrally or made part of the project history.

Small teams usually don't need the complexity of a pull-request model. Your mileage may vary.