It’s been one year since we decided to switch to Git from Visual Source Safe. We’ve had up to 6 developers using Git with our .NET Visual Studio solution which consists of 31 project and 3000+ source files(C#, F#, ascx, etc…). Git is an amazing piece of software. If you are not using it, stop what you are doing, download it, and start learning it. I’ve used Perforce, MKS, Mercurial, and CVS/SVN, but it would be very sad for me to go back to using something other than Git.
Before I get more into Git, I want to get one thing straight: Source Safe is not source control software. At best, it’s a fat random byte generation layer on top of the file system or network stack. Calling it source control is the “biggest scam perpetrated on the American public since One Hour Martinizing”.
Git does not have the notion of a central repository built into it, it is distributed. You work directly on a repository. Usually this is your own local repository. You commit changes locally. You have all your history and branches locally. Branches can be shared across repositories by pushing and pulling. Git comes with its own network protocol for doing this, but there are other protocols that can be used like SSH. By starting with this distributed architecture, the very notion of having your own repository means you are working in your own seperate branch (a local branch can be tracked to a branch in a remote repository). The result: branching is EASY. It’s built in. It’s part of everything you do.
Just because it’s distrubited doesn’t mean you can’t work with a repository that is considered the “central” or master repo. This is what we do. We all cloned from the master repo. Our master branch is “tracked” to the master branch in the master repo. We work locally, commit, and push our changes to the central repo (you might have to pull first before doing a push if you’ve changed files that someone else has). We create other branches and push them to the master branch so that they are available to other developers when they do a pull. Merging is done on pulls automatically. Everything just works.
I’m not going to give you a course on Git here, there are other good sources for that, but I will give you some starter tips:
- Get the msys Git for windows. Cygwin is evil.
- Get git extensions. It adds git functionality to file explorer and Visual Studio.
- Git, by default, considers all the bytes within all the files in the file system tree starting at the top level repository directory part of the repository. Any bytes in that file tree are fair game. This behavior can be changed. See below.
- Don’t think of the repositories as files and directories. Think a big byte blog. Changes that happen are not happening in files, they are happening somewhere in this big ball of bytes.
- Tags, branches, and commits are all the same thing: references to some point in the repository. Branches have a different work flow.
-
For visual studio projects, we use a .gitignore file with these contents:
*.pdb
*.dll
*.exe
*.suo
*.scc
*.vspscc
*.user
*.cache
*.log
*.rdl.data
bin/
obj/ - For merging:
1. Download p4merge.
2. Create a batch file called p4diff.bat with the following contents and put it in the c:\windows dir:p4merge %2 %5
3. Add the following to the end of your .gitconfig file under c:\Documents and Settings\Username
[mergetool "p4merge"]
cmd = p4merge $BASE $REMOTE $LOCAL
[merge]
tool = p4merge
[diff]
external = p4diff.batNow, when you call git mergetool p4merge will be used.
Why is this better than Perforce or SVN? Where I work we have some very large sites. Hosting multiple repos from multiple sites in their entirety would not be feasible. How would Git be used in this case?
What is ‘large’, exactly?
In a git repo that tracks gcc:
[gcc (trunk)]$ du -hs .git/
573M .git/
[gcc (trunk)]$ du -hs –exclude .git
540M .
This repo goes back to 1988! Git has fit over 20 years of development (over 96k commits) into a space that is just 1.06x the size of the working tree!
If a factor of 2x the working dir is too much for your developers to handle, you might want to get bigger hard drives. Or, you could have them do a ’shallow clone’ and just grab a slice of the repo in history.
In any case, disk space is so cheap these days that it’s easy to justify the tremendous speed boost of a DVCS like git.
I worked as an intern at Microsoft over the summer, and actually got the chance to meet the man behind Source Safe. It was made as a start up by him and anyone else he could convince to join him. Microsoft later bought it because they liked it (it was pretty good for the time). It hasn’t really been updated since then of course. He has since come up with something called Team Foundation Server. If you’re going to compare Git to what MS uses for Source Control, talk about TFS, not Source Safe.
When I spoke to him, I happened to mention that I had sworn an oath to find and kill the man who made the Source Safe API. Turns out, he made that part of it himself.
“When I spoke to him, I happened to mention that I had sworn an oath to find and kill the man who made the Source Safe API. Turns out, he made that part of it himself.”
So where’d you hide the body?
Git is terrible software. It doesn’t integrate well with the VS build process and its lack of a central server means it is impossible to back up code. I’ll stick to VSS, thanks. Once again the “open source” folks forget that there are other uses for software than just hobby style development.
Wayne,
Have you seen the latest Android commercials? Is that a hobby project? We back up our repository daily. We are also able to build and put code into production on a regular basis. Also, Git is the only piece of open source software we use, I wouldn’t consider myself “open source” folk.
Three things:
1) Since when was software’s usefulness dependent on how well it works with a single IDE?
2) Have you ever used a distributed VCS before? It’s not that you don’t have servers, it’s that every client *can* double as a server (though they don’t necessarily have to). This actually has several benefits. First of all, it means you make commits locally. If you’re in the middle of a big group project, you’ll want to keep committing even if you temporarily break something. With a local repository, you can do that. Second, if your central server goes down, everyone is left on their own with a centralized VCS. On a distributive system, you can keep working under a source control, and then just push to the main server when everything’s fixed. It’s never complete chaos with DVCS. There’s almost always a single central server that used when everything works. Since everyone is downloading from this main server, that means that everyone has a backup of the entire tree. You want to back up a git repository, all you need to do is check it out.
3) The Linux Kernel, Facebook, Yahoo, Ruby on Rails, Android, Fedora, and Perl are not hobby projects. All of them use Git. Neither are Python, Firefox, Symbian, OpenSolaris, and OpenOffice (Mercurial) or Ubuntu and MySQL (bazaar).
>> 1) Since when was software’s usefulness dependent
>> on how well it works with a single IDE?
It matters when that IDE is what 95+% of actual developers use.
Do not feed the trolls, people.
It always amazes me that people use meaningless statics to try to obfuscate the fact that they have no facts… how did you come by the statistic that 95+% of ‘actual developers’ use. what hat did you pull that 95% from?
(plus what are the other so called -5%? virtual developers?)
no. 95% of X, makes the remainder 5% of X.
[citation needed]
its lack of a central server means it is impossible to back up code
Waouh. Just Waouh. Either troll a launching attempt, or you just don’t know what you are talking about…
I’ve worked on a dozen projects with perforce, visual source safe, subversion, and even Alien Brain. Visual source safe is a joke – it’s terrible software. It’s impossible to version software with it. It’s impossible to say what state the repository/your source code is in because it doesn’t use atomic check-ins! If you have to produce an automated build, what do you key it on? There’s no such thing as a changeset/changelist/commit! Everyone just checks their changes in and VSS shoves the whole mess into it’s database one file patch at a time! Your 20 file check-in and my 20 file check-in get interleaved and any automated build process is going to choke if it tries to sync to the repository at that point in time. I can’t believe that anyone actually uses this toy and calls what they do something other than ‘hobby style development’.
Alien Brain, back when I used it, had no concept of atomic check-ins, ergo Alien Brain was just as much a toy as Visual Source Safe was. NXN might have fixed this since then.
You don’t understand git and distributed source control ( “its lack of a central server means it is impossible to back up code” – I’m laughing right now ). Fair enough. Go look up subversion or perforce in wikipedia right now. Subversion is free and perforce includes commercial support, whichever suits your tastes/needs. Use one of these. Seriously.
“lack of a central server means it is impossible to back up code.” – false, everybody and anyone with a clone of the repository has a backup. This is probably better then your backup plan since it is multiplied infinitely.
What advantages do you find over Mercurial?
That’s also what I’d like to know.
Trivial branch, less painful merges.
Ability to reorder changes at your local repo (don’t do that on an remote repo though).
A tag system that doesn’t seem grafted on.
Those are the few that came into mind.
A bit of trivia; when Microsoft was about to release Visual C++ 1.0, they were also planning to ship a VCS called “Microsoft Delta”. At the very last minute Delta was pulled and made to disappear. Shortly afterwards, Microsoft bought One Tree Software, the makers of SourceSafe, and proceeded to turn it into the abomination we know today.
Delta was ready to ship, boxes and all, so the problem must have been critical and unfixable. I’ve never been able to find out what went so wrong.
“lack of a central server means it is impossible to back up code”
Most projects that use git have a central server. Even if they didn’t, having a central server doesn’t preclude backing up code.
Some of the projects that use git are Google Android, OLPC, and the linux kernel (which powers the $5.3 billion-in-revenue-per-year linux server market). These are hardly ‘hobby’ development projects.
It should also be noted that many people see the lack of a central server better than a traditional backup system, simply because if your backup farm dies a horrible death due to incompetence/maliciousness/tac nuke all your developers still have a (presumably) recent copy of what the “master server” would contain anyways. Working copies from centralized repos do not have all this information stored, typically.
If you want a central git server, then set one up and nominate it as your central git server. There’s nothing in git that prevents you from using the classic ‘everyone checks into a central repository’ model.
Backing up is ridiculously easy: git push –mirror to a backup repository. Done.
Clearly there are features that VSS and friends have that git doesn’t (fine grained access control springs to mind) but thinking that it’s only suitable for ‘hobby-style development’ is unthinking prejudice in my opinion.
I get the feeling I’m feeding a troll, but this:
> lack of a central server means it is impossible to back up code.
is just complete and utter nonsense, and this should be obvious. I’ll spell it out for you, though: your team does still keep a central code repository. Any code not merged into the central repository is the equivalent of code not checked in to a central repository in a centralized VCS.
What advantage do you see of git over mercurial? I use mercurial. I’ve never used git.
Easier to understand and use(commands). Much faster. Better GUI tools. Less buggy.
of course, I haven’t used git a lot, but for someone like me I found Mercurial a lot more intuitive than Git. but I guess it’s just personal preference. speed-wise they don’t really seem all that different.
I really liked tortoiseHG, but that’s not the only GUI tool for Mercurial, there’s a lot more.
GIT and Hg had the same functionality I needed, but ended up using Hg because I felt more comfortable using it.
From what I’ve heard, git is faster, makes smaller repositories (the git files themselves take up less space), and it’s a little bit easier to learn the commands. Mercurial’s big advantage is that it’s much easier to hook into and extend, in part because Python is designed for that sort of thing.
Hg is much more user-friendly than git (at least at was when I chose Hg — but git’s usability has improved since, however). At the time, people likened Hg to an Apple, and git to Linux — more powerful, but more difficult.
People never did clearly express what was better in git.
I do prefer Hg to svn, but it is a little limiting in dealing with large repositories, especially in a corporate environment where files are shared among multiple projects. You can’t check out folders in repositories. You get the whole repository, which isn’t really reasonable. To the best of my knowledge, hacks like super-repositories aside, git had all the same problems.
I’ve been planning to switch, but I wanted to figure out why.
I’ve never really bought into the python argument very much. Git’s structure as a tool set controlled by a wrapper tool is a lot more powerful than people give it credit for, many of the original “tools” were just perl scripts that wrapped other git tools.
The obvious (and possibly important to you) advantage in git’s camp is that because they’re tools that leverage the commandline, they can be controlled by any environment that can work with that (which is pretty much everything).
As someone who migrated a team to DVCS, we evaluated mercurial, but at the time, you couldn’t delete branches for some reason; this was a deal breaker as we usually had many things going on at once, and all those stale branches would have proven a management nightmare.
It seems you misunderstood what named branches are (there are no equivalent in git), you can’t delete it because it’s a marker *inside* the changeset.
You probably wanted to use anonymous branches (possibly with a bookmark) instead.
http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/ explains very well what it is about.
Wayne, Git is a pretty nice software and a precursor of its type. I don’t know why it should play nice with propietary software process nor what does it exactly means, but probably it can be done, it is open source after all.
You can also configure Git with a central repository if you want to. As a programmer you need to do better research before talking.
To be fair, git is only source control tool. Something like MKS is so much more, Source control, bug tracking (it’s much more than that, it’s complete workflow tracking, for all kinds of artifacts, from defects, work items, test items, documentation items or anything else your organization needs) to requirements management and test management with complete tracability and linking of all of these artifacts. It is possible to link and track business requirement to source code change packages, all defects posted against the implementation of that requirement, and all customer requests for changes etc.
It works with DB vendor of your choice and your corporate LDAP server etc. It has command line, web UI, and fat client interfaces for each of these product areas and it integrates with major IDEs and editors of your choice.
It is highly customizable and you can write your own integrations into it as well.
MKS manages your entire software development life cycle. Small shops may think they don’t need all this, but I can’t see myself working in this day and age without a tool like that.
So, you see it’s not really fair to compare something like git to MKS Integrity Suite.
He didn’t actualy compair git to MKS, he simply stated that he used it and would rather use git than MKS.
It’s very possible that they use other resources to fill in the gaps.
The “major” open source ticket trackers have direct git support: Trac and Redmine can even hook into git, resolving and/or otherwise updating tickets directly from a commit log entry.
I strongly suggest you look into these two systems, as they’re both trivial to configure, don’t require much resources, and don’t limit you to a specific source control system. They’re both driven via web browser and have very rich interfaces.
If we were talking about CASE tools, you may have a point, but git has a very basic approval system which is already in use by the linux kernel team, I can’t imagine going to a full CASE system with git would be much more involved.
Git is good, the only issue i have with it right now is lack of a tool like VisualSVN to interact with it. Right now we work with Team Foundation Server which is good, great version control. It’s a bit overkill right now as we don’t use any of the work item features or what not with it, and not sure how to turn those off yet.
If anyone takes anything away from this, take this: ditch visual source safe. If you are a MS shop and have to stay with them, then TFS is a great version control program.
If you are someone using subversion, then you should very much take a serious look at Git.
[...] Git and Microsoft Development: A Success Storylexparse.com [...]
We’ve been using Microsoft TFS 2010 Beta2 (Team Foundation Server) and we are really liking the gated checkin feature and the branch virtualization feature.
I’ve been hearing more and more about GIT and while I’d like to use distributed TFS Basics installed on each Dev’s machine I’d like to understand why everyone finds GIT to be so awesome.
Git is command line driven and doesn’t have a nice ui, it doesn’t integrate with the windows file system, and I don’t have checkin policies, correct? or am i wrong?
Check out the features TFS gives us: http://msdn.microsoft.com/en-us/library/bb385832(VS.100).aspx
Where can i see why I might want to move to GIT?
Wayne, every person who checks out a copy is a complete backup. Your desgnated central repo goes down you designate another if necessary – hence the distributed nature.
If someone is intestested to know how Git stands against SVN – http://git.or.cz/gitwiki/GitSvnComparsion
[...] Git and Microsoft Development: A Success Story (36): A success story of Git on Windows development, and why other tools are not as [...]