Reputation: 239
I'm in the process of moving from svn to git, and I'm wondering how to manage our local development webservers along with the new git system.
Right now, a developer can have multiple checkouts of the development branch. Each of those checkout directories are mapped to the webserver with various virtual hosts.
For instance, developer bob may have 3 checkouts of dev for various tickets. Each of those checkouts have their own virtual host bob.dev1.localhost, bob.dev2.localhost, and bob.dev3.localhost.
When they're done with a ticket, they'll mark down on the ticket the host the changes reside on and move the ticket over to QA. That seems relatively straight forward.
Now, with git, having multiple checkout directories doesn't make sense. The dev can just branch the development branch and work on a clean slate, and just checkout a different branch whenever they need to change gears.
Is there a way to have the local dev websevers point to specific local git checkouts? For instance the developer makes a new branch, makes their changes, and then passes the branch name as part of host, and then whenever someone hits the webserver, the local branch is checked out if it's not already, and we can pass QA Urls specific to tickets? For example bob.branch1.localhost, bob.branch2.localhost.
If none of this makes any sense, I wouldn't be surprised. If you have any suggestions on how to do this based on your own development workflow, I'd love to hear it.
Upvotes: 0
Views: 91
Reputation: 60235
The usual team workflow I'm familiar with is to get work ready to publish in a personal repo, and then push it to a shared, bare repo that manages only published, official commits. Repos can be shared intra-team extremely casually on a shared filesystem and almost as casually over a VPN. There's no reason to publish developers' wip repos, a dvcs permits applying the vcs toolkit to much more experimental work.
Upvotes: 1