É totalmente indiscutível que todo projeto de software independente do seu tamanho ou complexidade, necessita hoje de um sistema para versionamento de código. Isso não é mais uma questão de escolha. No momento em que se inicia um projeto de software, mesmo que este esteja sendo manipulado por apenas um desenvolvedor, o controle de versões passa a não ser uma tarefa de teor trivial, ou algo que se possa considerar opcional.

Daí é que surge o grande problema da maioria dos projetos de software: qual VCS utilizar? Grande parte dos desenvolvedores se vê hoje mal acostumados com a utilização e manipulação do CVS, Subversion ou mesmo o SourceSafe da Microsoft. É bem verdade que alguns deles atendem aos requisitos de determinados projetos de forma aceitável, nem sempre satisfatória, mas felizmente hoje podemos contar com ferramentas que oferecem funcionalidades bem mais evoluídas nesse âmbito.

O Linus Torvalds, por exemplo, sofria desse mal: como controlar uma gama enorme de colaborações provenientes de todo o mundo? Nos primórdios a maneira de controle dos códigos se constituía num processo manual, onde se testava e implantava manualmente retalhos de código, mas isso com o passar do tempo tendia a se tornar impraticável, por questões que envolviam o grande esforço de trabalho dos envolvidos no projeto. Quando ele sentiu a necessidade de empregar um sistema para controlar os códigos do núcleo Linux, decidiu de pronto não utilizar nem o CVS, nem o Subversion, por limitações já descritas. Então optou pelo Bitkeeper, que apesar de ser comercial, se enquadrava perfeitamente as necessidades do projeto. No entanto, como explicar e principalmente motivar a comunidade de um software livre a utilizar um aplicativo comercial? Perante essas dificuldades, decidiu então desenvolver seu próprio sistema para controle de versões, optando pelo modelo distribuído, daí nasceu o Git.

Citação: "Ser distribuído significa que você não tem uma localização central que se mantém a par de seus dados, um único lugar, mais importante que qualquer outro lugar. Este modelo centralizado não funciona..."
Linus Torvalds - Palestra ministrada sobre o Git no Tech Talk Google.

Nos sistemas de controle distribuídos (item quatro), cada colaborador do projeto obtém em sua máquina local um clone completo do repositório principal. O que difere o Git das demais ferramentas, é justamente a grande escala de otimização desse repositório. Um dos exemplos clássicos dessa otimização, é o que acontece com alguns projetos, onde a última revisão de código é apenas um pouco maior que todo o código armazenado no repositório, incluindo atualizações e modificações.

A grande jogada está na estrutura desse sistema, onde todo o repositório encontra-se armazenado localmente, como isso o desenvolvedor não tem nenhum problema com permissões de escrita. Está tudo armazenado localmente na sua estação de trabalho. Alem da possibilidade de trabalhar no desenvolvimento do projeto em modo offline, sem necessitar de um acesso a rede nem internet, gerando assim maior comodidade e mobilidade aos colaboradores.

No Git cada desenvolvedor tem o repositório completo em sua estação de trabalho, que também é conhecido como "repositório central", mas que na verdade é apenas um dos clones que foi eleito como "repositório principal" e que caso sofra uma perda irreversível, deve ser substituído por qualquer um desses outros repositórios. Isso mantém viva a arquitetura distribuída do desenvolvimento do software, onde se garante que qualquer um dos repositórios clonados possa ser eleito como "repositório principal".

O que acontece é que ao invés de se fazer um "checkout" e copiar o topo do projeto, o Git permite fazer um "clone" e obter uma cópia completa do repositório. Fazendo com que cada desenvolvedor tenha todo o repositório em sua máquina local e possibilitando a sua substituição caso haja alguma perda de informação.