realbasic-nug
[Top] [All Lists]

Re: git for version control

To: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Subject: Re: git for version control
From: Peter De Berdt <peter.de.berdt@pandora.be>
Date: Thu, 30 Oct 2008 10:59:09 +0100
Authentication-results: mx.google.com; spf=neutral (google.com: 74.124.194.228 is neither permitted nor denied by best guess record for domain of realbasic-nug-bounces@lists.realsoftware.com) smtp.mail=realbasic-nug-bounces@lists.realsoftware.com
Delivered-to: listarchive@realsoftware.com
In-reply-to: <8B7E82C8-EA6D-4157-94EE-0F6A1AC76D6D@declareSub.com>
References: <8B7E82C8-EA6D-4157-94EE-0F6A1AC76D6D@declareSub.com>
Reply-to: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Sender: realbasic-nug-bounces@lists.realsoftware.com

On 29 Oct 2008, at 18:49, Charles Yeomans wrote:

Has anyone tried using git for version control? I'm taking a look at it.

I've already posted a few times about it on this list (it should be in the archives) and it's simply a lot better than CVS and SVN (and even better than Perforce, but some ppl just want enterprise support). The only versioning system that comes close IMHO is Mercurial, but Linus Torvalds based it on Mercurial, so no surprise there.

What I particularly like about git is:
- Distributed: using gitosis or github you can still have a "central repository", but you always work on a local repository and push the changes to the remote one. This has several advantages: you can still commit while being offline, you can work on a feature and only push when it is stable, it's a lot quicker to revert to a previous commit, your local repo is a backup in itself in case your central repo goes down - Clean: no more .svn folders in every single directory of your project (always fun when you delete a folder from SVN not using svn delete, but just deleting it from the terminal), just one single .git folder in the root of your project. All config files are short and easily readable and editable. Ignoring files/folders is a simple matter of editing the .gitignore file and you're set, no propset blabla anymore - Branching the way it should be: branching in svn has always been a bit of a pain, it is possible, but it's hell trying to merge reliably both ways. These days I happily start a new branch for an experimental feature (git branch my-experimental-feature), work on it (git checkout my-experimental-feature), get a phonecall for a bug, fix it in the master branch (git checkout master), go back to my experimental one, work a bit more, realize I need that fix from the master branch (git rebase), finish the feature, go back to the master branch and merge it (git checkout master && git merge my-experimental-feature). It's hard to explain how easy it is and how quickly I create a new branch to try something out now, but once you try it out, you'll know what I mean. As I said, it could be done in subversion, but the way you had to do it was so cumbersome all of our developers generally avoided doing it in the first place. When we switched to git, there was a bit of mumbling for the first two days, then we saw nothing but happy faces.


Best regards

Peter De Berdt

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>