2

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?

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
Rob Fyffe
  • 719
  • 1
  • 8
  • 22
  • I answered a *similar* question at this [Q&A](http://stackoverflow.com/a/10322161/236871), take a look, you'll probably find it interesting – KurzedMetal Jun 19 '12 at 15:28

1 Answers1

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.

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
  • Ok I got a system that works for me now, but your response was very helpful. Thanks – Rob Fyffe Jul 10 '12 at 13:48
  • @Robert Glad I was able to help! Don't be afraid to post your own solution as an answer, too--it may help others with a similar question in the future. – Todd A. Jacobs Jul 10 '12 at 14:11