Tips on setting up Source Control Management
I would really appreciate it, if someone could give me some helpful pointers on setting up my own version control system.
I'm using a server with Ubuntu 10.04 LTS with a LAMP (+mongoDB) environment and I'd like to set up a complete version control system across 2 servers.
Essentially, 1 server will act as a DEV server while the other will be LIVE.
I've looked at Git and Beanstalk.., and to be honest, I'm not entirely sure where to start.
Links:
While the Linode guide is useful. I don't just want to blindly act on the instructions found here:
Because, I'd like to know what other experienced users have done first.
Once I have a fully working version control system, i'll be using eclipse on a windows platform + coda from a mac for my dev activities.
Any pointers on getting started would be greatly appreciated!
5 Replies
I have a folder on the server (say /srv/git/site.com) which contains a bare git repository, this is where you push to. Then the site would be in say /srv/sites/site.com which would be a normal git repository which would use /srv/git/site.com as the remote and pull from that.
Why is this useful?
Say you have a special promotion for a week and create a separate git branch for it say called promo, and your live site branch is called live then you can do.
git push origin live locally to send the code to the /srv/git/site.com then in /srv/sites/site.com run git fetch && git checkout -b promo origin/promo to make the new promotion code live, then when it's over you simply run git checkout live in /srv/sites/site.com
Another handy feature is it's very easy to rollback changes (assuming there's no database changes or other weirdness outside of the repository) you simply run git checkout
I was actually thinking of purchasing a separate Linode as the primary dev server and deploying code to the live server.
I've used tortoise svn and eclipse for all my dev work at various agencies, but I have little to know knowledge on how to achieve my ideal dev environment.
"Clone"
I'd name the new one prod, or production, or whichever you prefer. This would make the new Linode your production box, and the environment should be an exact duplicate of the dev system. Of course, you'd want to update the hostname and stuff to separate it from the dev box. You'd also want to delete the git repo that was cloned over as well, so you don't get them confused and end up with code in different places.
If you want to give git a go, I recommend going over this: Github tryGit
Your work flow would initially be something like this:
Develop code, test code, push to git repository to track changes. Rinse, repeat.
When code is production ready, clone the development Linode and remove any development specific stuff (git repo, change hostname, etc.)
Now, you'd develop code, test code, push to git repository to track changes, then pull the changes down on the production box using "git pull"
Hope this helps!
-Tim
I'll go-ahead with your suggestions and install this on the 1 linode server for now.
Hopefully, this shouldn't be too much of a hassle to setup.
I'll be using beanstalkapp.com as it has some rather sweet features.
Thanks a bunch, and hopefully we can do business in future.
The gist with Git is that you define remote origin points to pull/push code from and branch revisions from. It can be used just knowing a few simple commands like git