Proper Git repo structure/workflow

Question

I'm new to git in terms of setting up a proper structure and workflow and wanted to know what some git experts thought regarding a workflow and structure.

I work at an agency and came from a different agency that was a Microsoft shop using TFS. The TFS structure that was used was like below at a high level:

> - Client Name 
>    - Website Project
>       - A project adding features to the existing website    
>    - A Different Website Project
>       - A project adding features to the existing website    -
>    - Banner Ad's
>    - A different type of project (such as a Kiosk project, etc.)
> - Client Name
> - Client Name

I thought this was a good approach as far as a structure but realize TFS is much different than git.

I'd like to do something similar in terms of structure using Git and GitHub if it's doable. If not, what would anyone suggest as an improved structure/workflow?

Would the proper way (with Git) to have a separate repo for each Client or each project? Is there a way we could use 1 repo and structure it similar to the TFS example structure above? If so is the structure above similar to git or would anyone suggest a better approach?

At the moment we have myself and another developer but will be growing to 4-8 developers. Just looking for comments and suggestions from the experts to form some ideas based on cost and how to go about doing it the right way so something is in place. Thank you!

Answer 1

You'd most likely want one repo per deployable codebase.

So, this would tend to be thought of as a "project", however in your TFS example if both of those first two projects are adding features to the same "existing websites", those should be all in one repo, managed with branches:

http://git-scm.com/book/en/Git-Branching

Clients can be setup as an "Organization" in GitHub, with repos associated and access controlled at that level.