Collaborative web development
9 comments
I'd definitely use version control.
There's no reason you can't make quick updates with version control. You'll each have a copy of the whole site (maybe with test databases) on your dev machines, and should be able to make the update, test it on your dev machine, then commit the changes to the repository.
There's no reason you can't make quick updates with version control. You'll each have a copy of the whole site (maybe with test databases) on your dev machines, and should be able to make the update, test it on your dev machine, then commit the changes to the repository.
What one of my friends says is that he usually makes some change directly on the code on the server, click CTRL-S and I can just refresh the page to see what he did.
With Git, for example, you modify the code on your machine, then save it, that you have to commit and push. Or am I wrong?
With Git, for example, you modify the code on your machine, then save it, that you have to commit and push. Or am I wrong?
You're correct. But you should be able to test the code on your machine and make sure it's correct before committing it.
Your development machine should be able to run the same code as your server.
Making changes to the public site is a very bad practice. What if your code has errors in it?
Version control also keeps everyone up to date. Before making a change to the site you'll download the most up to date version from the repository, that way your local copy has everyones changes, with comments about what they've done.
Your development machine should be able to run the same code as your server.
Making changes to the public site is a very bad practice. What if your code has errors in it?
Version control also keeps everyone up to date. Before making a change to the site you'll download the most up to date version from the repository, that way your local copy has everyones changes, with comments about what they've done.
Of course I'm not thinking about making changes to the public site. At the moment there is no public site, so I'm just thinking about a good development practice. I think that when the site will be public we may have a development copy of it on the server itself. I think we need to try it in practice, because we also have many doubts about resolving conflicts and merging.
It's simple. Use version control (I use git) and a VPN, where your friend can connect to your local webserver running your working copy to see your current state, but the live server stays clean and can be updated from git later.
you dont have to do that.
my standard process is so:
have my checked out code mounted via nfs etc on the dev server.
make changes.
install.
if it works correctly, check it in.
we have a very flexible build system that allows for anything from the entire system to being installed down to just a single file.
my standard process is so:
have my checked out code mounted via nfs etc on the dev server.
make changes.
install.
if it works correctly, check it in.
we have a very flexible build system that allows for anything from the entire system to being installed down to just a single file.
Typically, a dedicated box on your local network serving up an SVN system works.
Do you suggest SVN over Git?
Do you want centralized or decentralized version control, do you plan on doing a lot of branching, and are offline commits important?
We would like to use some version control system, but we are not sure that this would be a good idea for web development. I know about Git and I thought we could use Gitosis to make a repository on our server, but we think that this may slow down our work.
Often, when we have to adjust some code, or some graphics, we quickly modify something, save and refresh to see what happens. How can we accomplish this with Git/Gitosis?
How do you usually work in team and mantain code?