The pragmatic Programmer has an excellent book on using git. Would like to
have a better conflict catching chapter, but hey, it is good.
http://pragprog.com/titles/tsgit/pragmatic-version-control-using-git
Trausti
On Thu, Oct 30, 2008 at 10:59 AM, Peter De Berdt
<peter.de.berdt@pandora.be>wrote:
>
> 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>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|