Почему Git лучше, чем X

Самая, возможно, убедительная особенность Git, выделяющая ее из остальных СУВ, это модель ветвления. Она полностью отличается от всех остальных, которые я сравниваю здесь, большинство из которых рекомендуют, что лучшая ветка, это копия репозитория в новом каталоге.

Git работает иначе. Она позволяет вам иметь множество локальных веток, абсолютно независящих друг от друга, а создание, слияние и удаление этих линий разработки занимает секунды.

Это означает, что вы можете делать вещи, подобные этим:

• Создать ветку, чтобы попробовать новую идею, выполнить несколько коммитов, переключиться обратно, откуда начали экпериментировать, принять патч, снова переключиться туда, где выполняли эксперименты, и затем объединить все вместе.
• Иметь ветку, которая всегда содержит то, что пойдет на продакшн, другую, чтобы объединять наработки для тестирования и несколько небольших, для ежедневной работы.
• Создавать отдельные ветки для каждой новой возможности, над которой работаете, а также беспрепятственно переключаться между ними туда и обратно, а затем удалить каждую ветку после того, как изменения попадут в основную линию разработки.
• Создать ветку для экспериментов, понять, что это не будет работать и просто удалить их, отказавшись от изменений — и никто другой это не увидит (даже если вы в это время выложили другие ветки).

Важно, когда вы выкладываете изменения в удаленный репозиторий, туда не попадут все ваши ветки. Вы можете выложить только одну из них, а не все сразу. Это, как правило, освобождает людей, которые пробуют новые идеи, от постоянного планирования как и когда они будут выполнять слияние или делится с остальными.

Вы можете отыскать пути, как сделать подобное в других системах, однако это намного сложнее и подвержено ошибкам. Git делает этот процесс невероятно простым и меняет подход к работе разработчиков, после знакомства с ней.

В основном это касается всех распределенных СУВ, но по моему опыту, Git в большей степени. Кроме 'fetch', 'pull' и 'push', остальные команды взаимодействуют ни с чем другим, кроме вашего жесткого диска.

Это не единственное, что делает большинство операций, которые вы, возможно, тоже используете, более быстрыми и c возможностью работать в оффлайн-режиме. Возможно, это не звучит, как нечто такое, но я всегда поражаюсь тому, как часто я работаю оффлайн. Возможность создать ветку, выполнить слияние или коммит и просматривать историю вашего проекта пока вы находитесь в самолете или поезде, позволяет быть очень продуктивным.

Даже в Mercurial, команды вроде 'incoming' и 'outgoing' взаимодействуют с сервером, в то время как с Git вы можете получить ('fetch') все данные с сервера перед тем, как перейти в оффлайн-режим, и выполнять сравнения, слияния и логирования данных на сервере, но еще не в ваших локальных ветках.

Это значит, что очень просто иметь копии не только ваших веток, но и всех остальных, существующих в вашем репозитории без беспорядка в ваших материалах.

Git очень быстрая. Все, даже очень продвинутые пользователи других систем, отдают ей предпочтение в этом. В Git, все операции выполняются локально, давая ей небольшое преимущество над Svn и Perforce, обеим из которых требуется подключение к сети для определенных операций. Так или иначе, даже сравнивая с распеределенными СУВ, которые выполняют операции локально, Git быстрее.

Отчасти это потому, что она создавалась для работы на ядром Linux, а значит, что нужно было справляться с большими репозиториями с первого дня. Как дополнение, она написана на C, что сокращает накладные расходы выполнения языков высокого уровня. Другая причина высокой скрости Git заключается в том, что создатели сделали это целью проекта приложения.

Ниже приведены сравнительные тесты, которые я выполнил с тремя копиями исходного кода проекта Django, с помощью трех различных СУВ: Git, Mercurial и Bazaar. Также я протестировал кое-что из этого в Svn, но поверьте мне, она медленнее — возьмите показатели Bazaar и добавьте к ним задержки сети...

В итоге, везде, кроме добавления новых файлов, Git оказалась быстрее (В том числе очень большие коммиты, где Hg показала похожие результаты, но коммит, который я тестировал был настолько большим, что вам, скорее всего, не придется выполнять такой — обычные же коммиты быстрее в Git).

"Холодные" и "горячие" показатели ветвлений являются первым и вторым разом создания ветки в репозитории — второе создание работает с дисковых кэшем.

Необхдимо заметить, что хотя показатели 'add' являются более медленными, операция выполнялась для большого количества файлов, более 2000. Для большей части того, что совершается ежедневно, операции добавления будут занимать доли секунды. Остальные операции, испытанные здесь (за исключением больших коммитов), лучше отражают то, что вы будете периодически.

Эти показатели не так трудно повторить, просто создайте клон проекта Django с помощью каждой из систем, выполнив следующие команды.

• git clone git://github.com/brosner/django.git dj-git
• hg clone http://hg.dpaste.com/django/trunk dj-hg
• bzr branch lp:django dj-bzr
• svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn

Git идеальна для экономии дискового пространства. Ваш каталог Git (как правило) едва будет больше, чем Svn — в некоторых случаях даже меньше (видимо много занимают .svn каталоги).

Следующие цифры были взяты из клонирований проекта Django в каждом из полуофициальных зеркал Git, с одинакой точки в истории.

В отличие от других систем, Git имеет нечто, что называется "подготовка к коммиту" или "индекс". Это промежуточная стадия, на которой вы формируете коммит таким, каким хотите его видеть, перед тем как его выполнить.

Подготовка к коммиту классная штука, и что ставит Git отдельно от других, это возможность просто подготовить некоторые файлы, как вы закончите с ними, и выполнить коммит только их, а не всех изменений, или выводить списком в командной строке при выполнении коммита.

Данная возомжность позволяет подготавливать только части измененного файла. Прошло несколько дней после внесения двух несвязанных изменений в файле, перед тем, как вы поняли, что забыли выполнить коммит одного из них. Итак, вы можете подготовить необходимые изменения для текущего коммита, а другие для следующего. Эта возможность масштабируется до любого количества различных изменений, которое вам потребуется.

Конечно же, Git позволяет игонорировать такую возможность. Если вам не нужен такого рода контроль — просто "прилепите" '-a' к команде 'commit' для того, чтобы подготовить все модификации всех файлов.

Одна из классных возможностей любой распределенной СУВ, в том числе и Git, это распределенность. А значит, что вместо выполнения "checkout" текущего последнего состояния исходного кода, вы полностью клонируете (clone) репозиторий.

Получается, что даже если вы используете централизованую схему рабочего процесса, каждый пользователь имеет по сути полную резервную копию основного сервера, и сможет заменить его в случае аварии или повреждений. В Git не существует единой точки отказа, если только репозиторий не единственный.

Это сильно не замедлит работу. В среднем, команда 'checkout' Svn только немного быстрее, чем у других РСУВ. Среди тестируемых РСУВ, Git самая быстрая.

Одна из замечательных особенностей Git заключается в том, что из-за ее распределенного характера и отличной системы ветвлений, вы можете легко реализовать практически любую схему рабочего процесса, которую только можете представить.

Очень распространенной схемой Git, особенно для людей перешедших с централизованных систем, является централизованная схема. Git не будет позволять выкладывать изменения, если кто-то выложил свои, с момента последнего получения данных с сервера (fetch), но несмотря на это, централизованная модель, где все разработчики выкладывают свои изменения на тот же сервер, работает на ура.

Еще одна распространенна схема Git, в которой присутствует менеджер — человек, который выполняет коммит в 'священный' репозиторий. Заключается в следующем: изменения выкладываются в независимые репозитории менеджера и поступает запрос на него, чтобы он получил ваши изменения. Такую модель разработки, вы часто видите в open source проектах или GitHub-репозитариях.

Для более масштабных проектов, вы можете отправить ваших разработчиков по пути, по которому идет ядро Linux, где люди отвечают за отдельную подсистему проекта ('лейтенанты') и выполняют слияния всех изменений этой подстистемы. Затем, другой человек ('диктатор') может собрать воедино изменения, выполненные его лейтенантами, и выложить их в 'священный' репозиторий, который затем снова клонируют все остальные.

Кроме того, Git очень гибкая в этом вопросе, так что вы можете экспериментировать и выбрать свою схему, наиболее правильную для вас.

Возможно я кажусь предвзятым, учитывая, что я работаю на GitHub, но я в любом случае добавил этот раздел, т.к. множество людей говорят, что GitHub стал причиной их перехода на Git.

GitHub для большинства людей стал причиной начать пользоваться Git, потому что он скорее социальная сеть для программистов, чем просто хостинг. Люди находят других разработчиков или проекты, которые близки им по роду деятельности, могут легко ответвляться ('fork'), предлагать решения, создавая очень динамичное окружение вокруг Git и проектов, где ей пользуются.

Существуют и другие сервисы, причем как для Git так и для других СУВ, но всего несколько имеют социальную направленность, и ниодного с такой базой пользователей. В данном аспекте GitHub просто потрясает, а вместе с перечисленными выше возможностями, работа с Git и GitHub является отличной комбинацией для быстрой разработки open source проектов.

Таким сообществом не обладает ниодна другая СУВ.

Однако, так было не всегда - раньше, Git была не полноценной СУВ, а скорее кучей различных утилит, позволявших реализовать работу распределенной СУВ. Сегодня же, набор команд и обучение в Git довольно похожи на другие СУВ, и даже лучше некоторых.

Поскольку сложно доказать это без каких-либо исследований, я просто покажу разницу между справкой Mercurial и Git. Я выделил схожие команды обоеих систем. В Hg, если выполнить 'hg help' вы получите список примерно из 40-ка команд.

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...

До Git версии 1.6, все команды выполнялись самостоятельно, что путало пользователей. И хотя она по-прежнему распознает их, появилась одна единственная команда 'git'. Таким образом, если вы посмотрите на Mercurial и Git, то Git имеет похожий набор команд и справочную систему и есть лишь небольшая разница на начальном этапе с точки зрения пользовательского интерфейса.

В наши дни уже довольно сложно утверждать, что изучить Mercurial или Bazaar легче, чем Git.