I would like to know, How does Git handles authentication? Is windows domain based authentication supported?

I have one doubt for Git i.e. if every dev. copies the whole repository locally, how come Git is faster then SVN? What about disk usage for large projects?

Personally I think, It would be hard for Windows based shop to make a switch to Git as of today due to lack of integration with 3rd party tools like Trac, GUI clients like Tortoise SVN, Subclipse etc (But anyways like you said that’s beyond the scope of your article).

First, for personal projects (and I have several), having a Version Control System would be better than periodically re-naming working files as something like “myproject-III.py”, which is my current practice.

Second, even as a sole developer for a backend website, there were times in which I was in the middle of some sort of substantial change, and my employer would say “There’s a bug somewhere here. Could you fix it?” Well, yes and no: I’m sure it will be easy to fix (and it often was), but now I’ll have to update the “Live” version with that bugfix…except that “Testing” is in the middle of this big change, and is not at all ready to deploy…furthermore, I have to make sure that the change I just made is applied to both “Testing” and “Live”. I tried to add a third version for this, called “Debugging”, but that introduced even more complexities!

Third, it would seem that having a centralized VCS would be overkill for this, and for my personal use. The reason my employer is using SVN is because he has a couple of developers on the main website as well.

Overall, I will likely be using Git for personal use! And it would seem that I’m going to wish that my employer would use Git as well.

however, git hooks are my single most favorite thing about git; examples:

1) pre-commit hook on developer repos to check for syntax errors in *.php files. awesome.
2) commit-msg hook on developer repos to force conformance of commit messages to a defined spec.
3) post-update hook on developer repos to link updates/squashes to a custom ticketing system and close the ticket if we like.
4) we use a series of hooks to let us sync/push changes to staging_master to ALL DISTRIBUTED WEBSERVERS INSTANTLY. we also use a callback system so ensure that all servers get the update, then a time is pushed, and all servers update AT THE SAME SECOND. before this we would “svn update” on each server manually; we use our SCM as a means to “launch” changes.
5) we do the same thing as #4 but with the production copy to make changes sitting on staging sync with production, once staging has been confirmed to be working as expected.
6) not a hook, but each developer gets a full working tree and never interferes with another developer. they can go to dev_name.dev.example.com, to test their personal copy, stage.dev.example.com, to test the staged (master) development copy (merged work from various devs), stage.example.com, to see the staged production copy and so on.
7) we use a “hub” copy on each production server that acts as a buffer to the real, checked out copy that people see when they access the website (git says to never push/pull to a repo that has a working copy). this is pretty cool see #8.
post-commit hook to guarantee that committed (key word COMMITTED) changes made to ANY live server get immediately pushed to the master copy on the dev server, AND instantly (relatively) reflected to ALL OTHER PRODUCTION SERVERS. sounds a little dangerous, heh and maybe it is, but it keeps everything in sync and allows for last second, sh!t is down dirty little changes. should never happen, and it hasnt yet, but still cool.

all this lets us, the devs, work as a group but not affect/break/slow/confuse each others progress on whatever. also, another cool thing is we track each others repos, so if one dev has problems/bugs/whatever, ANY of us can diff his branch against ours if we want, or checkout their branch(es) and help them solve the problem from our own machine, WITHOUT EVER TOUCHING MASTER.

we can develop, test, and launch without ever leaving the development machine.

as others have said, git’s power is the fact that it’s less of an SCM itself, and more a tool for letting YOU define what an SCM means to the workflow and structure of your company.

one thing that i did not see surface was ANY mention of git hooks. this, along with branching, merging, and simple backups, are the killer features in git for us. git can use any executable file as a hook, be Python/PHP/Ruby/C++/Bash/whatever.

my team of 5 develops for a small company whose primary income is a member driven website, and the primary language is PHP. before, with svn, we were all continuously stepping on each other by editing various layers of the software stack. we did not deal with branching/merging in svn as its too cumbersome, period, and we all work from a CLI/SSH interface to distributed webservers. i remember several instances where layers below me or another dev were broken by a different developer, and i/he wasted 20+ minutes trying to figure out what was wrong with my code. this is where local topic branching is key; as i can always be fairly certain that the code in trunk/master/head/whatever is clean and not stupidly broken from the changes others are making right now on their own feature x/y/z.

We use Subversion at work, although have been toying with the idea of using Git. As mentioned though I think I prefer quick and small commits to the server where the data is more secure. We work in a very Agile setup, so if anything does get broken, it gets fixed straight away.

Also tools such as TortoiseSvn are much more mature than TortoiseGit. And VisualSVN, there is no VisualGit equivalent.

However I do like Git. I use it at home now, and will continue to do so, and possibly one day will apply it at work. Switching source control system is a lot of pain though, and at the moment Git doesn’t offer us any huges improvements.

It can’t do all the things of git yet, but works well overall.

It is also nice that the checked out directories only have one .git directory, instead of a .svn directory in every subdir, making it very easy to copy Git-tracked trees. Git is pretty transparent in its working.

Caveats: I use command line tools only, no GUI, no IDE, so YMMV.