I have not used any version control system yet, but shopping around I
found these links on git:
Directly from the horse's mouth:
http://www.youtube.com/watch?v=4XpnKHJAok8
(by Linus Torvalds)
There is also a follow-up on Git
http://www.youtube.com/watch?v=8dhZ9BXQgc4
by Randal Schwartz
/Lennart
On 10/30/08, Trausti Thor Johannsson <tj@quarksbar.net> wrote:
> 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>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|