Tips on setting up Source Control Management

Hi guys,

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:

http://beanstalkapp.com

https://github.com/features/projects

While the Linode guide is useful. I don't just want to blindly act on the instructions found here:

http://library.linode.com/linux-tools/v … ontrol/git">http://library.linode.com/linux-tools/version-control/git

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! :D

5 Replies

One of my favourite workflows is to use git.

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

Thanks for the helpful advice :)

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.

I'd start off with one Linode and do the development on that box. This would include adding a git repo, and tracking all of your changes. Once you are satisfied with the application, add a new Linode to your account and used the "Clone" function from within the Linode Manager to clone the dev Linode to the new one.

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

Thanks for all the input guys.

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.

I highly suggest GitHub; it's what I use, and it keeps development focused on development as opposed to managing the source control server. This would at least allow you to get familiarized with git instead of having to learn client and server at the same time.

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 . It's a separate subject in itself obviously, but I don't recommend dealing with both at once; it might make it a nightmare to learn. All depends on what you prefer though. I don't consider the security to be improved by having it hosted locally. In fact, quite the opposite. You can also setup remote SSH keys to allow for direct connections to GitHub, and they have enterprise level security in use. I'm a huge fan.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct