Git: diferenças entre revisões

6 bytes adicionados ,  10 de novembro de 2012
; Manipulação eficiente de projetos extensos: Torvalds descreveu o Git como sendo veloz e escalável,<ref>{{cite mailing list | author=Linus Torvalds |url=http://marc.info/?l=git&m=116128307511686 |title=Re: VCS comparison table |date=2006-10-19 |mailinglist=git}}</ref> e testes de performance realizados pela [[Mozilla]] apontaram que o Git é uma [[ordem de magnitude]] mais rápido que alguns sistemas de controle de versão. Obter o histórico das revisões salvos em repositórios locais resulta ser duas ordens de magnitude mais rápido que obtê-los de um servidor remoto.<ref>{{Cite journal |author=jst | url=http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html | title=bzr/hg/git performance |journal=Jst's Blog |last=Stenback |first=Johnny |date=2006-11-30 |accessdate=2008-02-20}}, benchmarking "git diff" against "bzr diff", and finding the former 100x faster in some cases.</ref><ref>{{cite web | author=Roland Dreier |url=http://digitalvampire.org/blog/index.php/2006/11/16/oh-what-a-relief-it-is/ |title=Oh what a relief it is |date=2006-11-13}}, observing that "git log" is 100x faster than "svn log" because the latter has to contact a remote server.</ref> Um detalhe interessante é que o Git não fica mais lento com o aumento do histórico do projeto.<ref>{{Cite book |author=Robert Fendt |url=http://ldn.linuxfoundation.org/article/dvcs-roundup-one-system-rule-them-all-part-2 |title=DVCS Round-Up: One System to Rule Them All?—Part 2 |publisher=Linux Foundation |last=Fendy |first=Robert |date=2009-01-21 |quote=One aspect that really sets Git apart is its speed. …dependence on repository size is very, very weak. For all facts and purposes, Git shows nearly a flat-line behavior when it comes to the dependence of its performance on the number of files and/or revisions in the repository, a feat no other VCS in this review can duplicate (although Mercurial does come quite close). |accessdate=2009-06-25}}</ref>
; Autenticação criptográfica do histórico: O histórico do Git é salvo de uma maneira que o nome de uma determinada revisão (um "commit", ou entrega, nos termos do Git) depende de todo o histórico de desenvolvimento que leva até este commit. Uma vez publicado, não é possível mudar as versões antigas sem passar despercebido. A estrutura é similar à uma [[Árvore (estrutura de dados)|árvore]] [[hash]] ([[hash tree]]), mas com dados adicionais nos nós e nas folhas.<ref>{{cite web | url=http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#trust | title=Git User's Manual - Git Concepts - Trust | date=2006-10-18 }}</ref> (o [[Mercurial]] e o [[Monotone]] também possuem esta propriedade.)
; Modelo baseado em ferramentas: O Git foi modelado como um conjunto de programas escrito em [[Linguagem C|C]], e numerosos [[Shell script|scripts em shell]] que encapsulam estes programas.<ref>{{cite mailing list | mailinglist=git | author=Linus Torvalds | url=http://marc.info/?l=git&m=116118369005954 | title=Re: VCS comparison table | accessdate=2009-04-10 }}, describing Git's script-oriented design</ref> Embora muitos destes scripts foramtenham sido reescritos em C, como parte de um esforço de portar o Git para o Windows, o modelo básico continua, sendo fácil agrupar seus componentes.<ref>{{cite web | author=iabervon | url=http://lwn.net/Articles/165202/ | title=Git rocks! | date=2005-12-22 }}, praising Git's scriptability</ref>
; Estratégias de mescla (merge) conectáveis: Como parte de desenho em ferramentas, o Git tem um conjunto bem definido de modelos de uma mescla incompleta, e possuí vários algoritimos para completá-las, culminando em comunicar o usuário que é incapaz de completar o merge automaticamente, sendo necessária uma edição manual.
; O [[Coletor de lixo|lixo]] se acumula se não for limpo: Abortar operações ou desfazer mudanças irá deixar objetos sem valor pendentes no banco de dados. Existe porém uma pequena fração desejável de objetos no sempre crescente histórico, mas [[Coletor de lixo|liberar o espaço]] usando <code>git gc --prune</code> pode ser uma operação lenta.<ref>{{cite web | url=http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#ensuring-reliability | title= Git User's Manual | date=2007-08-05 }}</ref>
105

edições