At work, we are trying to switch to Git, but are encountering some problems (let me state from the beginning I'm the only one at work who has some basic experience with Git, another coworker has worked with Subversion in the past, but that's it).
We envision things as follows:
- We have a main directory where stable projects are located and our project managers can review sites and debug if needed. This main directory (let's call it MAIN) is also the origin repository for all developers.
- All developers working on the project have a subdirectory on the server where we clone MAIN, work on our changes and push to MAIN again. We pull each others changes from there as well.
We tried doing this today, but quickly noticed it is not recommended to push to a non-bare repository master -> master. This makes sense to me when I read why. I found some solutions if you want to per se do master -> master pushing (to a non-bare repo), but they all require executing various commands on the origin (either resetting or merging from a different branch). The solution then is, as far as I can tell: convert MAIN into a bare repository. However, this would mean that our PMs are no longer able to view the project, as there is no working directory.
What would be the best approach to solve this? Do we set up a hook that automatically exports the bare MAIN repository so we can view the files?
Extra thing: MAIN will become a clone on it's own over time: we have a default template that's used for every project, I thought it would be good practice to clone MAIN from the default template and then add stuff onto it. Is this considered bad practice? Pushing back to the default template is not necessary, however we might want to pull bugfixes. Should we just start the bare MAIN repo and copy/paste the default template into it?
