Git и Mercurial - сравни и сравни

Есть несколько вещей, которые отличают Mercurial от Git, но есть другие вещи, которые делают их похожими. Оба проекта заимствуют идеи друг у друга. Например, команда hg bisect в Mercurial (ранее расширение bisect ) была вдохновлена ​​командой git bisect в Git, свободный формат, где каждый объект хранится в отдельном файле (эти файлы записываются один раз и никогда не изменяются), и упакованный формат, в котором многие объекты хранятся с дельта-сжатием в одном файл. Атомарность операций обеспечивается тем фактом, что ссылка на новый объект записывается (атомарно, с использованием трюка создания + переименования) после записи объекта.

Репозитории Git требуют периодического обслуживания с использованием git gc (для уменьшить дисковое пространство и повысить производительность), хотя в настоящее время Git делает это автоматически. (Этот метод обеспечивает лучшее сжатие репозиториев.)

Mercurial (насколько я понимаю) сохраняет историю файла в файловом журнале (вместе, я думаю, с дополнительными метаданными, такими как отслеживание переименования и некоторая вспомогательная информация); он использует плоскую структуру под названием manifest для хранения структуры каталогов и структуру под названием changelog , в которой хранится информация о наборах изменений (ревизиях), включая сообщение фиксации и ноль, один или два родительских элемента.

Mercurial использует журнал транзакций для обеспечения атомарности операций и полагается на усечение файлов для очистки после неудачной или прерванной операции. Журналы Revlogs предназначены только для добавления.

Глядя на структуру репозитория в Git по сравнению с Mercurial, можно увидеть, что Git больше похож на объектную базу данных (или файловую систему с адресной информацией), а Mercurial больше похож на традиционную реляционную базу данных с фиксированным полем.

Различия:
^{В Git древовидные объекты образуют иерархическую структуру; в Mercurial manifest файл имеет плоскую структуру . В Git blob объектное хранилище одна версия содержимого файла; в Mercurial filelog хранится вся история одного файла (если не учитывать здесь какие-либо сложности с переименованием). Это означает, что есть разные области операций, в которых Git будет быстрее Mercurial, все остальное считается равным (например, слияние или отображение истории проекта), а также области, в которых Mercurial будет быстрее, чем Git (например, применение патчей или отображение история одного файла). Эта проблема может не иметь значения для конечного пользователя.}

Из-за структуры с фиксированными записями в структуре Mercurial changelog коммиты в Mercurial могут иметь только до двух родителей ; коммиты в Git могут иметь более двух родителей (так называемое «слияние осьминога»). Хотя вы можете (теоретически) заменить слияние осьминога серией двух родительских слияний, это может вызвать сложности при преобразовании между репозиториями Mercurial и Git.

Насколько я знаю, Mercurial не имеет эквивалента с аннотациями. теги (объекты тегов) из Git. Особым случаем аннотированных тегов являются подписанные теги (с подписью PGP / GPG); эквивалент в Mercurial может быть выполнен с помощью GpgExtension , расширение которого распространяется вместе с Mercurial. Вы не можете пометить объект без фиксации в Mercurial, как вы можете в Git, но я думаю, что это не очень важно (некоторые репозитории git используют помеченный blob-объект для распространения открытого ключа PGP для проверки подписанных тегов ).

Ссылки: ветки и теги

В Git ссылки (ветки, ветки удаленного отслеживания и теги) находятся за пределами DAG коммитов (как и должно быть). Ссылки в пространстве имен refs / Heads / ( локальные ветви ) указывают на коммиты и обычно обновляются с помощью «git commit»; они указывают на верхушку ветки, поэтому такое название. Ссылки в пространстве имен refs / remotes / / ( ветки удаленного отслеживания ) указывают на фиксацию, следуют ветвям в удаленном репозитории и являются обновляется "git fetch" или аналогичным. Ссылки в пространстве имен refs / tags / ( tags ) обычно указывают на коммиты (облегченные теги) или объекты тегов (аннотированные и подписанные теги) и не предназначены для изменения.

Теги

В Mercurial вы можете дать постоянное имя ревизии, используя тег ; Теги хранятся аналогично шаблонам игнорирования. Это означает, что глобально видимые теги хранятся в файле с контролируемой версией .hgtags в вашем репозитории. Это имеет два последствия: во-первых, Mercurial должен использовать специальные правила для этого файла, чтобы получить текущий список всех тегов и обновить такой файл (например, он читает самую последнюю зафиксированную ревизию файла, а не текущую версию); во-вторых, вы должны внести изменения в этот файл, чтобы новый тег был виден другим пользователям / другим репозиториям (насколько я понимаю).

Mercurial также поддерживает локальные теги , хранящиеся в hg / localtags , которые не видны другим (и, конечно, не могут быть переданы)

В тегах Git фиксированные (постоянные) именованные ссылки на другие объекты (обычно объекты тегов, которые, в свою очередь, указывают на фиксации), хранящиеся в refs / tags / пространство имен. По умолчанию при получении или отправке набора ревизий git автоматически извлекает или подталкивает теги, которые указывают на извлекаемые или отправляемые ревизии. Тем не менее, вы можете контролировать в некоторой степени , какие теги извлекаются или передаются.

Git обрабатывает легкие теги (указывающие непосредственно на коммиты) и аннотированные теги (указывающие на объекты тегов, которые содержат сообщение тега, которое необязательно включает подпись PGP, которая, в свою очередь, указывает на фиксацию) немного по-другому, например, по умолчанию оно учитывает только аннотированные теги при описании фиксации с помощью «git describe».

Git не имеет строгого эквивалента локальных тегов в Mercurial. Тем не менее, лучшие практики git рекомендуют настроить отдельный публичный голый репозиторий, в который вы отправляете готовые изменения и из которого другие клонируют и извлекают. Это означает, что теги (и ветки), которые вы не отправляете, являются частными для вашего репозитория. С другой стороны, вы также можете использовать пространство имен, отличное от голов , удаленных или тегов , например local-tags для локальных тегов.

^{Личное мнение: На мой взгляд, теги должны находиться вне графа ревизий, поскольку они являются внешними по отношению к нему (они являются указателями на граф ревизий). Теги должны быть без версий, но с возможностью передачи. Выбор Mercurial использования механизма, подобного механизму игнорирования файлов, означает, что он либо должен обрабатывать . hgtags специально (файл в дереве может быть перенесен, но обычно он версируется), или имеют теги, которые являются только локальными ( .hg / localtags не версионируется, но не может быть передан).}

Ветви

В Git локальная ветвь (конец ветки или заголовок ветки) - это именованная ссылка на фиксацию, из которой можно создавать новые коммиты. Ветвь также может означать активную линию разработки, то есть все коммиты доступны из конца ветки. Локальные ветки находятся в пространстве имен refs / Heads / , поэтому, например, полное имя ветки 'master' - 'refs / Heads / master'.

Текущая ветка в Git (то есть извлеченная ветка и ветка куда пойдет новый коммит) - это ветка, на которую ссылается HEAD ref. Можно иметь HEAD, указывающий непосредственно на фиксацию, а не символическую ссылку; такая ситуация нахождения в анонимной безымянной ветке называется отдельной HEAD («git branch» показывает, что вы находитесь в '(без ветки)').

В Mercurial есть анонимные ветки (главы веток) , и можно использовать закладки (через расширение закладок ). Такие ветки закладок являются чисто локальными, и эти имена (до версии 1.6) нельзя было передать с помощью Mercurial. Вы можете использовать rsync или scp для копирования файла .hg / bookmarks в удаленный репозиторий. Вы также можете использовать hg id -r , чтобы получить идентификатор редакции текущей подсказки закладки.

Начиная с версии 1.6 закладки можно нажимать / тянуть. На странице BookmarksExtension есть раздел о Работа с удаленными репозиториями . Разница в том, что в Mercurial имена закладок являются глобальными , в то время как определение «удаленного» в Git описывает также сопоставление имен веток из имен в удаленном репозитории именам локальных удаленное отслеживание веток; например, refs / Head / *: refs / remotes / origin / * сопоставление означает, что можно найти состояние ветки 'master' ('refs / heads / master') в удаленном репозитории в 'origin / master 'ветка удаленного отслеживания (' refs / remotes / origin / master ').

Mercurial также имеет так называемые именованные ветки , где имя ветки встроено в совершить (в наборе изменений). Такое имя является глобальным (передается при выборке). Эти названия веток постоянно записываются как часть метаданных набора изменений. В современном Mercurial вы можете закрыть «именованную ветку» и прекратить запись имени ветки. В этом механизме подсказки ветвей вычисляются на лету.

"Именованные ветки" Mercurial, на мой взгляд, должны называться метками фиксации , потому что это то, чем они являются. Бывают ситуации, когда «именованная ветка» может иметь несколько подсказок (несколько бездетных коммитов), а также может состоять из нескольких непересекающихся частей графа ревизий.

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

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

Ветви в продвижении

Mercurial по умолчанию выталкивает все головы . Если вы хотите отправить одну ветвь ( single head ), вы должны указать версию конца ветки, которую вы хотите отправить. Вы можете указать вершину ветки по номеру ревизии (локальная для репозитория), по идентификатору ревизии, по имени закладки (локально для репозитория, не передается) или по встроенному имени ветки (с именем ветка).

Что касается Я понимаю, что если вы нажмете ряд ревизий, которые содержат коммиты, помеченные как находящиеся в какой-то «именованной ветке» на языке Mercurial, у вас будет эта «именованная ветка» в репозитории, в который вы нажимаете. Это означает, что имена таких встроенных ветвей («именованные ветки») являются глобальными (по отношению к клонам данного репозитория / проекта).

По умолчанию (с учетом push.default ] переменная конфигурации) "git push" или "git push < remote >" Git будет отправлять соответствующие ветки , то есть только те локальные ветки, эквивалент которых уже присутствует в удаленном репозитории, который вы нажимаете в. Вы можете использовать параметр - all для git-push ("git push --all"), чтобы протолкнуть все ветви , вы можете использовать "git push < remote ]> < branch > ", чтобы отправить заданную единственную ветку , и вы можете использовать" git push < remote > HEAD " для отправки текущей ветви .

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

Ветви при извлечении

Примечание: здесь я использую терминологию Git, где «выборка» означает загрузку изменений из удаленного репозитория без интеграции этих изменений с локальной работой. Это то, что делают « git fetch » и « hg pull ».

Если я правильно понимаю, по умолчанию Mercurial извлекает все головы из удаленного репозитория , но вы можете указать ветку для выборки через « hg pull --rev » или « hg pull # », чтобы получить ] одиночная ветвь . Вы можете указать < rev> с использованием идентификатора ревизии, имени «именованной ветки» (ветка, встроенная в журнал изменений) или имени закладки. Однако имя закладки (по крайней мере, в настоящее время) не передается. Все ревизии "именованных ветвей", которые вы получаете, подлежат переносу. «hg pull» хранит кончики полученных веток как анонимные, безымянные заголовки.

В Git по умолчанию (для пульта «origin», созданного с помощью «git clone», и для пультов, созданных с помощью «git remote add») » git fetch "(или" git fetch ") получает все ветки из удаленного репозитория (из пространства имен refs / Head / ), и сохраняет их в пространстве имен refs / remotes / . Это означает, например, что ветка с именем 'master' (полное имя: 'refs / Heads / master' ) в удаленном 'origin' будет сохраняться (сохраняться) как 'origin / master' ветка удаленного отслеживания (полное имя: 'refs / remotes / origin / master').

Вы можете получить одиночная ветвь в Git с помощью git fetch - Git будет хранить запрошенные ветки в FETCH_HEAD, что похоже на безымянные главы Mercurial.

Те. являются лишь примерами по умолчанию мощного синтаксиса refspec Git: с помощью refspecs вы можете указать и / или настроить, какие ветки нужно извлекать и где их хранить. Например, по умолчанию случай «получить все ветки» представлен подстановочным знаком «+ refs / heads / *: refs / remotes / origin / *» refspec, а «выборка одной ветки» - это сокращение для «refs / Heads / :» . Refspecs используются для сопоставления имен веток (refs) в удаленном репозитории с именами локальных refs. Но вам не нужно знать (много) о спецификациях ссылок, чтобы эффективно работать с Git (в основном благодаря команде "git remote").

^{Личное мнение: Я лично считаю, что "именованные ветки" ( с именами ветвей, встроенными в метаданные набора изменений) в Mercurial - это неправильный дизайн с его глобальным пространством имен, особенно для распределенной системы контроля версий. Например, возьмем случай, когда и Алиса, и Боб имеют «именованную ветку» с именем «for-joe» в своих репозиториях, ветки, которые не имеют ничего общего. Однако в репозитории Джо эти две ветки будут неправильно рассматриваться как одна ветвь. Итак, вы каким-то образом придумали соглашение, защищающее от конфликтов имен веток. Это не проблема с Git, где в репозитории Джо ветвь «for-joe» от Алисы будет «alice / for-joe», а от Боба - «bob / for-joe». См. Также Разделение имени ветки от идентичности ветки Проблема, поднятая в Mercurial wiki.}

«Ветви закладок» Mercurial в настоящее время не имеют встроенного механизма распространения.

Различия:
Эта область является одной из основных. основные различия между Mercurial и Git, как сказали Джеймс Вудьятт и Стив Лош в своих ответах. Mercurial по умолчанию использует анонимные облегченные строки кода, которые в его терминологии называются «головами». Git использует облегченные именованные ветки с инъективным отображением для сопоставления имен ветвей в удаленном репозитории с именами ветвей удаленного отслеживания. Git "силы" Суффикс ~ n параметра ревизии означает n-й предок коммита в прямой строке первого родителя. Эти суффиксы можно комбинировать, чтобы сформировать спецификатор ревизии по пути от символьной ссылки, например, 'pu ~ 3 ^ 2 ~ 3'

Также существуют спецификаторы ревизии, включающие reflog, не упомянутые здесь. В Git каждый объект, будь то фиксация, тег, дерево или большой двоичный объект, имеет свой идентификатор SHA-1; существует специальный синтаксис, например, 'next: Documentation' или 'next: README' для ссылки на дерево (каталог) или blob (содержимое файла) в указанной ревизии.

Mercurial также имеет много способов именования наборов изменений (описанных, например, в hg man-странице):

• Простое целое число рассматривается как номер версии. Необходимо помнить, что номера ревизий локальны для данного репозитория ; в другом репозитории они могут быть другими.
• Отрицательные целые числа рассматриваются как последовательные смещения от вершины, где -1 обозначает вершину, -2 обозначает ревизию до подсказки и так далее. Они также являются локальными в репозитории.
• Уникальный идентификатор версии (40-значная шестнадцатеричная строка) или его уникальный префикс.
• Имя тега (символическое имя, связанное с данной версией) или закладка имя (с расширением: символическое имя, связанное с данной головкой, локальное для репозитория) или «именованная ветка» (метка фиксации; ревизия, указанная в «именованной ветке», является подсказкой (бездетная фиксация) всех фиксаций с данной меткой фиксации, с наибольшим номером ревизии, если таких советов несколько)
• Зарезервированное имя «tip» - это специальный тег, который всегда идентифицирует самую последнюю ревизию.
• Зарезервированное имя «null» указывает на нулевую ревизию.
• ] Зарезервированное имя "." указывает родительский рабочий каталог.

Различия
Как вы можете видеть, сравнивая приведенные выше списки, Mercurial предлагает номера ревизий, локальные для репозитория, а Git - нет. С другой стороны, Mercurial предлагает относительные смещения только от «вершины» (текущая ветвь), которые являются локальными для репозитория (по крайней мере, без ParentrevspecExtension ), тогда как Git позволяет указать любую фиксацию, следующую за любой подсказкой.

Самая последняя ревизия называется HEAD в Git и "tip" в Mercurial; в Git нет нулевой ревизии. И у Mercurial, и у Git может быть много root (может быть несколько коммитов без родителей; обычно это результат объединения ранее отдельных проектов).

См. Также: Много разных спецификаторов ревизий статья в блоге Элайджи (newren's).

^{Личное мнение: Я думаю, что номера ревизий переоценены (по крайней мере, для распределенной разработки и / или нелинейной / ветвистой истории). Во-первых, для распределенной системы управления версиями они должны быть либо локальными по отношению к репозиторию, либо требовать особого обращения с некоторым репозиторием как с центральным органом нумерации. Во-вторых, более крупные проекты с более длинной историей могут иметь количество ревизий в 5-значном диапазоне, поэтому они предлагают лишь небольшое преимущество перед сокращенными до 6-7 символьными идентификаторами ревизий. и подразумевают строгий порядок, в то время как ревизии упорядочены лишь частично (здесь я имею в виду, что ревизии n и n + 1 не обязательно должны быть родительскими и дочерними). ​​}

Диапазоны ревизий

В Git диапазоны ревизий топологические . Обычно встречается синтаксис A..B , который для линейной истории означает диапазон ревизий, начинающийся с A (но исключая A) и заканчивающийся на B (т.е. диапазон открыт снизу ), является сокращение («синтаксический сахар») для ^ AB , которое для команд обхода истории означает все коммиты, доступные из B, за исключением тех, которые доступны из A. Это означает, что поведение A..B ] диапазон полностью предсказуем (и весьма полезен), даже если A не является предком B: A..B означает диапазон ревизий от общего предка A и B (база слияния) до ревизии B.

В Mercurial диапазоны ревизий основаны на диапазоне номеров ревизий . Диапазон указывается с использованием синтаксиса A: B , и в отличие от Git диапазон действует как закрытый интервал . Также диапазон B: A - это диапазон A: B в обратном порядке, чего нет в Git (но см. Ниже примечание о синтаксисе A ... B ). Но такая простота имеет свою цену: диапазон изменений A: B имеет смысл, только если A является предком B или наоборот, т.е. с линейной историей; в противном случае (я полагаю, что) диапазон непредсказуем, и результат является локальным для репозитория (поскольку номера ревизий являются локальными для репозитория).

Это исправлено в Mercurial 1.6, который имеет новый диапазон топологических ревизий , где «A..B» (или «A :: B») понимается как набор наборов изменений, которые являются потомками X и предками Y. Полагаю, это эквивалентно '--ancestry-path A..B' в Git.

Git также имеет обозначение A ... B для симметричной разницы ревизий; это означает AB - not $ (git merge-base AB) , что означает, что все коммиты достижимы из A или B, но за исключением всех коммитов, доступных из них обоих (достижимых из общих предков).

Renames

Mercurial использует отслеживание переименования для работы с переименованием файлов. Это означает, что информация о том, что файл был переименован, сохраняется во время фиксации; в Mercurial эта информация сохраняется в форме «расширенного сравнения» в метаданных filelog (файл revlog). Следствием этого является то, что вы должны использовать hg rename / hg mv ... или вам нужно не забыть запустить hg addremove для обнаружения переименования на основе сходства.

Git уникален среди систем управления версиями тем, что он использует определение переименования для работы с переименованием файлов. Это означает, что факт переименования файла обнаруживается в то время, когда это необходимо: при выполнении слияния или при отображении различий (если запрошено / настроено). Это имеет то преимущество, что алгоритм обнаружения переименований может быть улучшен и не замораживается во время фиксации.

И Git, и Mercurial требуют использования параметра - следуйте , чтобы следить за переименованием при отображении истории одного файла . Оба могут следовать за переименованием при отображении построчной истории файла в git blame / hg annotate .

В Git команда git blame может выполнять следить за движением кода, также перемещение (или копирование) кода из одного файла в другой, даже если перемещение кода не является частью полноценного переименования файла. Насколько мне известно, эта функция уникальна для Git (на момент написания, октябрь 2009 г.).

Сетевые протоколы

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

Mercurial поддерживает выборку и отправку через SSH и через протоколы HTTP. Для SSH требуется доступная учетная запись оболочки на конечном компьютере и установленная / доступная копия hg. Для доступа по протоколу HTTP требуется hg-serve или запущенный сценарий Mercurial CGI, а Mercurial должен быть установлен на сервере.

Git поддерживает два типа протоколов, используемых для доступа к удаленному репозиторию:

• «умные» протоколы , которые включают доступ через SSH и через специальный протокол git: // (от git-daemon ), требуется, чтобы на сервере был установлен git. Обмен в этих протоколах заключается в том, что клиент и сервер согласовывают общие объекты, а затем генерируют и отправляют пакетный файл. Современный Git включает поддержку «умного» протокола HTTP.
• «глупые» протоколы , которые включают HTTP и FTP (только для выборки) и HTTPS (для отправки через WebDAV), не требуют установки git на сервере, но они требуют, чтобы репозиторий содержал дополнительную информацию, сгенерированную git update-server-info (обычно запускается от ловушки). Обмен состоит из прохождения клиентом цепочки фиксации и загрузки отдельных объектов и файлов пакетов по мере необходимости. Обратной стороной является то, что он загружает больше, чем строго требуется (например, в крайнем случае, когда есть только один пакетный файл, он будет загружен целиком, даже при получении только нескольких ревизий), и что для завершения может потребоваться много соединений.

Расширение: возможность сценариев и расширения (плагины)

Mercurial реализован в Python , с некоторым основным кодом, написанным на C для повышения производительности. Он предоставляет API для написания расширений (плагинов) в качестве способа добавления дополнительных функций. Некоторые функции, такие как «закладки веток» или подписание ревизий, предоставляются в расширениях, распространяемых с Mercurial, и требуют его включения.

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

Git основан на форматах [репозитория] и [сетевых] протоколах и построен на их основе. Вместо языковых привязок есть (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git основан на форматах [репозитория] и [сетевых] протоколах и построен на их основе. Вместо языковых привязок есть (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git основан на форматах [репозитория] и [сетевых] протоколах и построен на их основе. Вместо языковых привязок есть (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git основан на форматах [репозитория] и [сетевых] протоколах и построен на их основе. Вместо языковых привязок есть (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git основан на форматах [репозитория] и [сетевых] протоколах и построен на их основе. Вместо языковых привязок существуют (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git опирается на форматы [репозитория] и [сетевые] протоколы и построен на них. Вместо языковых привязок существуют (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR

Git опирается на форматы [репозитория] и [сетевые] протоколы и построен на них. Вместо языковых привязок есть (частичные или полные) повторные реализации Git на других языках (некоторые из них являются частично повторными реализациями и частично оболочками для команд git): JGit (Java, используется EGit, подключаемый модуль Eclipse Git ), Grit (Ruby), Dulwich (Python), git # (C #).

TL; DR