Первоначально Git был создан Линусом Торвальдсом в 2005 году для разработки ядра Linux , при этом другие разработчики ядра внесли свой вклад в его первоначальную разработку. [13] С 2005 года Джунио Хамано является основным сопровождающим. Как и в большинстве других распределенных систем контроля версий и в отличие от большинства клиент-серверных систем, каждый каталог Git на каждом компьютере представляет собой полноценный репозиторий с полной историей и возможностями полного отслеживания версий, независимо от доступа к сети или центрального сервера . [14] Git — это бесплатное программное обеспечение с открытым исходным кодом , распространяемое только под лицензией GPL-2.0 .
С момента своего создания Git стала самой популярной распределенной системой контроля версий: по состоянию на 2022 год почти 95% разработчиков назвали ее своей основной системой контроля версий. [15] Существует множество популярных предложений служб репозитория Git, включая GitHub , SourceForge . , Bitbucket и GitLab . [16] [17] [18] [19] [20]
Торвальдсу нужна была распределенная система, которую он мог бы использовать, как BitKeeper, но ни одна из доступных бесплатных систем не отвечала его потребностям. Он привел пример системы управления исходным кодом, требующей 30 секунд для применения исправления и обновления всех связанных метаданных, и отметил, что это не соответствует потребностям разработки ядра Linux, где для синхронизации с другими сопровождающими может потребоваться 250 таких действий за раз. один раз. В качестве критерия проектирования он указал, что установка исправлений должна занимать не более трех секунд, и добавил еще три цели: [10]
Возьмите систему параллельных версий (CVS) как пример того, чего не следует делать; если сомневаетесь, примите прямо противоположное решение. [12]
Поддержка распределенного рабочего процесса, подобного BitKeeper . [12]
Включите очень сильные меры защиты от коррупции, как случайной, так и злонамеренной. [11]
Эти критерии исключали все системы контроля версий, использовавшиеся в то время, поэтому сразу после выпуска разработки ядра Linux 2.6.12-rc2 Торвальдс решил написать свою собственную. [12]
Разработка Git началась 3 апреля 2005 года. [24] Торвальдс объявил о проекте 6 апреля и на следующий день стал самостоятельным хостингом . [24] [25] Первое слияние нескольких филиалов произошло 18 апреля. [26] Торвальдс достиг своих целей; 29 апреля зарождающийся Git протестировал запись исправлений в дерево ядра Linux со скоростью 6,7 исправлений в секунду. [27] 16 июня Git выпустил ядро 2.6.12. [28]
26 июля 2005 года Торвальдс передал техническое обслуживание Юнио Хамано, который внес основной вклад в проект. [29] Хамано отвечал за выпуск версии 1.0 21 декабря 2005 года. [30]
Именование
Торвальдс саркастически пошутил по поводу имени git (что на британском английском сленге означает «неприятный человек»): «Я эгоистичный ублюдок и называю все свои проекты в честь себя. Сначала « Linux », теперь «git». [31] [32] На странице руководства Git описывается как «тупой трекер контента». [33]
«git» может означать что угодно, в зависимости от вашего настроения.
Случайная трехбуквенная комбинация, которая легко произносится и фактически не используется какой-либо распространенной командой UNIX. Тот факт, что это неправильное произношение слова «get», может иметь значение, а может и не иметь значения.
Глупый. Презренный и презренный. Простой. Выбирайте из словаря сленга.
«Глобальный информационный трекер»: у вас хорошее настроение, и это действительно работает на вас. Ангелы поют, и свет внезапно наполняет комнату.
«Чертов идиотский грузовик с дерьмом»: когда оно ломается.
В исходном коде Git программа называется «адским информационным менеджером».
Характеристики
Дизайн Git представляет собой синтез опыта Торвальдса в работе с Linux при поддержке большого проекта распределенной разработки, а также его глубоких знаний о производительности файловой системы, полученных в ходе того же проекта, и острой необходимости создать работающую систему в короткие сроки. Эти влияния привели к следующим вариантам реализации: [13]
Сильная поддержка нелинейного развития
Git поддерживает быстрое ветвление и слияние и включает специальные инструменты для визуализации и навигации по истории нелинейной разработки. В Git основное предположение заключается в том, что изменение будет объединяться чаще, чем оно записано, поскольку оно передается различным рецензентам. В Git ветки очень легкие: ветка — это всего лишь ссылка на один коммит.
Распределенная разработка
Подобно Darcs , BitKeeper , Mercurial , Bazaar и Monotone , Git предоставляет каждому разработчику локальную копию полной истории разработки, а изменения копируются из одного такого репозитория в другой. Эти изменения импортируются как добавленные ветки разработки и могут быть объединены так же, как и ветки, разработанные локально. [35]
Совместимость с существующими системами и протоколами
Торвальдс описал Git как очень быстрый и масштабируемый [37] , а тесты производительности, проведенные Mozilla [38], показали, что он на порядок быстрее различает большие репозитории, чем Mercurial и GNU Bazaar ; получение истории версий из локально хранящегося репозитория может быть в сто раз быстрее, чем получение ее с удаленного сервера. [39]
Криптографическая аутентификация истории
История Git хранится таким образом, что идентификатор конкретной версии ( коммита в терминах Git) зависит от полной истории разработки, приведшей к этому коммиту. После публикации невозможно изменить старые версии незаметно. Структура аналогична дереву Меркла , но с добавлением данных в узлах и листьях. [40] ( Таким свойством также обладают Mercurial и Monotone .)
Проектирование на основе набора инструментов
Git был разработан как набор программ, написанных на C , и нескольких сценариев оболочки, которые предоставляют оболочки для этих программ. [41] Хотя большинство этих сценариев с тех пор было переписано на C для обеспечения скорости и переносимости, дизайн остался прежним, и компоненты можно легко объединить. [42]
Подключаемые стратегии слияния
В рамках своего набора инструментов Git имеет четко определенную модель неполного слияния и несколько алгоритмов для его завершения, кульминацией которых является сообщение пользователю о том, что он не может завершить слияние автоматически и что необходимо редактирование вручную. [43]
Прерывание операций или откат изменений приведут к тому, что в базе данных останутся бесполезные висячие объекты. Как правило, это лишь небольшая часть постоянно растущей истории разыскиваемых объектов. Git автоматически выполнит сбор мусора , когда в репозитории будет создано достаточно свободных объектов. Сборку мусора можно вызвать явно с помощью git gc. [44] [45]
Периодическая явная упаковка объектов
Git хранит каждый вновь созданный объект в отдельном файле. Несмотря на индивидуальное сжатие, он занимает много места и неэффективен. Это решается использованием пакетов , которые хранят большое количество объектов, дельта-сжатых между собой, в одном файле (или сетевом потоке байтов), называемом пакетным файлом . Пакеты сжимаются с использованием эвристики , согласно которой файлы с одинаковыми именами, вероятно, похожи, без зависимости от этого правильности. Для каждого файла пакета создается соответствующий индексный файл, в котором указывается смещение каждого объекта в файле пакета. Вновь созданные объекты (с новой добавленной историей) по-прежнему хранятся как отдельные объекты, и для поддержания эффективности использования пространства необходима периодическая переупаковка. Процесс упаковки репозитория может оказаться очень затратным в вычислительном отношении. Позволяя объектам существовать в репозитории в свободном, но быстро генерируемом формате, Git позволяет отложить дорогостоящую операцию упаковки на более позднее время, когда время имеет меньшее значение, например, на конец рабочего дня. Git выполняет периодическую переупаковку автоматически, но возможна и ручная переупаковка с помощью git gcкоманды. [46] Для обеспечения целостности данных и пакетный файл, и его индекс содержат внутри контрольную сумму SHA-1 [47] , а имя файла пакетного файла также содержит контрольную сумму SHA-1. Чтобы проверить целостность репозитория, выполните git fsckкоманду. [48] [49]
Еще одним свойством Git является то, что он делает снимки деревьев каталогов файлов. Самые ранние системы отслеживания версий исходного кода, система контроля исходного кода (SCCS) и система контроля версий (RCS), работали с отдельными файлами и подчеркивали экономию места, которую можно получить за счет чередующихся дельт (SCCS) или дельта-кодирования (RCS). (в основном схожие) версии. Более поздние системы контроля версий поддерживали идею о том, что файл имеет идентичность в нескольких версиях проекта. Однако Торвальдс отверг эту концепцию. [50] Следовательно, Git не записывает явным образом отношения версий файлов ни на каком уровне ниже дерева исходного кода.
Эти неявные отношения ревизии имеют некоторые существенные последствия:
Изучение истории изменений одного файла немного дороже, чем изучение всего проекта. [51] Чтобы получить историю изменений, влияющих на данный файл, Git должен просмотреть глобальную историю, а затем определить, изменило ли каждое изменение этот файл. Однако этот метод изучения истории позволяет Git с одинаковой эффективностью создавать единую историю, показывающую изменения в произвольном наборе файлов. Например, очень распространенным случаем является наличие подкаталога исходного дерева и связанного с ним файла глобального заголовка.
Переименования обрабатываются неявно, а не явно. Распространенной жалобой на CVS является то, что он использует имя файла для идентификации его истории изменений, поэтому перемещение или переименование файла невозможно без прерывания его истории или переименования истории, что делает историю неточной. Большинство систем контроля версий после CVS решают эту проблему, присваивая файлу уникальное долгоживущее имя (аналогично номеру индексного дескриптора ), которое выдерживает переименование. Git не записывает такой идентификатор, и это считается преимуществом. [52] [53] Файлы исходного кода иногда разделяются, объединяются или просто переименовываются, [54] и запись этого как простого переименования заморозит неточное описание того, что произошло в (неизменяемой) истории. Git решает эту проблему, обнаруживая переименования при просмотре истории снимков, а не записывая их при создании снимка. [55] (Короче говоря, для данного файла в ревизии N файл с тем же именем в ревизии N - 1 является его предком по умолчанию. Однако, когда в ревизии N - 1 нет файла с таким же именем , Git ищет файл он существовал только в версии N - 1 и очень похож на новый файл.) Однако он требует более интенсивной работы ЦП каждый раз при просмотре истории, и доступно несколько вариантов настройки эвристики. Этот механизм не всегда работает; иногда файл, переименованный с изменениями в том же коммите, воспринимается как удаление старого файла и создание нового файла. Разработчики могут обойти это ограничение, зафиксировав переименование и изменения отдельно.
Git реализует несколько стратегий слияния; во время слияния можно выбрать стратегию не по умолчанию: [56]
рекурсивный : используется по умолчанию при извлечении или объединении одной ветки и является вариантом алгоритма трехстороннего слияния.
Если существует более одного общего предка, который можно использовать для трехстороннего слияния, создается объединенное дерево общих предков и используется в качестве эталонного дерева для трехстороннего слияния. Сообщается, что это приводит к меньшему количеству конфликтов слияния, не вызывая неправильных слияний, согласно тестам, выполненным на предыдущих коммитах слияния, взятых из истории разработки ядра Linux 2.6. Кроме того, это может обнаруживать и обрабатывать слияния, связанные с переименованиями.
— Линус Торвальдс [57]
осьминог : это значение по умолчанию при объединении более двух голов.
Структуры данных
Примитивы Git по своей сути не являются системой управления исходным кодом . Торвальдс объясняет: [58]
Во многих отношениях вы можете рассматривать git просто как файловую систему — она адресуется по содержимому и имеет понятие управления версиями, но на самом деле я разработал ее, исходя из проблемы с точки зрения специалиста по файловой системе (эй, ядра — это то, что я делаю) , и у меня фактически нет абсолютно никакого интереса к созданию традиционной SCM-системы.
На основе этого первоначального подхода к проектированию Git разработал полный набор функций, ожидаемых от традиционного SCM, [59] причем функции в основном создаются по мере необходимости, а затем со временем уточняются и расширяются.
Некоторые потоки данных и уровни хранения в системе контроля версий Git
Git имеет две структуры данных : изменяемый индекс (также называемый этапом или кешем ), который кэширует информацию о рабочем каталоге и следующей ревизии, которую необходимо зафиксировать; и неизменяемая объектная база данных , допускающая только добавление .
Индекс служит точкой соединения между объектной базой данных и рабочим деревом.
Хранилище объектов содержит пять типов объектов: [60] [48]
Blob — это содержимое файла . У больших двоичных объектов нет правильного имени файла, меток времени или других метаданных (внутреннее имя большого двоичного объекта представляет собой хэш его содержимого [61] ). В git каждый BLOB-объект представляет собой версию файла, в котором содержатся данные файла. [62]
Объект дерева является эквивалентом каталога. Он содержит список имен файлов, [63] каждое из которых содержит несколько битов типа и ссылку на объект blob или дерево, которым является этот файл, символическую ссылку или содержимое каталога. Эти объекты представляют собой снимок исходного дерева. (В целом это дерево Меркла , что означает, что достаточно только одного хеша для корневого дерева, который фактически используется в коммитах для точного определения точного состояния целых древовидных структур любого количества подкаталогов и файлов.)
Объект фиксации связывает древовидные объекты вместе в историю. Он содержит имя объекта дерева (исходного каталога верхнего уровня), метку времени, сообщение журнала и имена нуля или более родительских объектов фиксации. [64]
Объект - тег — это контейнер, который содержит ссылку на другой объект и может содержать добавленные метаданные, связанные с другим объектом. Чаще всего он используется для хранения цифровой подписи объекта фиксации, соответствующей конкретной версии данных, отслеживаемых Git. [65]
Объект Packfile собирает различные другие объекты в пакет, сжатый с помощью zlib, для компактности и простоты транспортировки по сетевым протоколам. [66]
Каждый объект идентифицируется хэшем SHA-1 его содержимого. Git вычисляет хэш и использует это значение в качестве имени объекта. Объект помещается в каталог, соответствующий первым двум символам его хеша. Остальная часть хэша используется в качестве имени файла для этого объекта.
Git хранит каждую редакцию файла как уникальный объект. Отношения между большими двоичными объектами можно найти, исследуя дерево и объекты фиксации. Вновь добавленные объекты сохраняются целиком с использованием сжатия zlib . Это может быстро занять большой объем дискового пространства, поэтому объекты можно объединять в пакеты , которые используют дельта-сжатие для экономии места, сохраняя большие двоичные объекты по мере их изменений относительно других больших двоичных объектов.
Кроме того, git хранит метки, называемые refs (сокращение от ссылок), для обозначения местоположений различных коммитов. Они хранятся в справочной базе данных и составляют соответственно: [67]
Заголовки (ветви) : именованные ссылки, которые автоматически переходят к новому коммиту, когда поверх них делается коммит.
HEAD : зарезервированный заголовок, который будет сравниваться с рабочим деревом для создания фиксации.
Теги : похожи на ссылки на ветки, но привязаны к конкретному коммиту. Используется для обозначения важных моментов в истории.
Рекомендации
Каждый объект в базе данных Git, на который нет ссылки, можно очистить с помощью команды сборки мусора или автоматически. На объект может ссылаться другой объект или явная ссылка. Git знает разные типы ссылок. Команды для создания, перемещения и удаления ссылок различаются. git show-refперечисляет все ссылки. Некоторые типы:
heads : относится к объекту локально,
Remotes : относится к объекту, который существует в удаленном репозитории,
stash : относится к объекту, который еще не зафиксирован,
мета : например, конфигурация в пустом репозитории, права пользователя; пространство имен refs/meta/config было введено ретроспективно, используется Герритом , [ 68]
теги : см. выше.
Реализации
gitg — это графический интерфейс, использующий GTK+ .
Git (основная реализация на C) в основном разработан для Linux , хотя он также поддерживает большинство основных операционных систем, включая BSD ( DragonFly BSD , FreeBSD , NetBSD и OpenBSD ), Solaris , macOS и Windows . [69] [70]
Первый порт Git для Windows представлял собой в первую очередь среду эмуляции Linux, на которой размещена версия Linux. При установке Git в Windows создается каталог Program Files с аналогичным названием, содержащий порт Mingw-w64 из коллекции компиляторов GNU , Perl 5, MSYS2 (который сам по себе является ответвлением Cygwin , Unix-подобной среды эмуляции для Windows) и различные другие порты или эмуляции Windows. утилит и библиотек Linux. В настоящее время собственные сборки Git для Windows распространяются в виде 32- и 64-битных установщиков. [71] На официальном сайте git в настоящее время поддерживается сборка Git для Windows, по-прежнему использующая среду MSYS2. [72]
Реализация Git в формате JGit — это чистая программная библиотека Java , предназначенная для встраивания в любое приложение Java. JGit используется в инструменте проверки кода Gerrit и в EGit, клиенте Git для Eclipse IDE. [73]
Go-git — это реализация Git с открытым исходным кодом , написанная на чистом Go . [74] В настоящее время он используется для поддержки проектов в качестве SQL- интерфейса для репозиториев кода Git [75] и обеспечения шифрования для Git. [76]
Реализация Git в Далвиче — это чистый программный компонент Python для Python 2.7, 3.4 и 3.5. [77]
Реализация Git в libgit2 — это программная библиотека ANSI C без каких-либо других зависимостей, которую можно построить на нескольких платформах, включая Windows, Linux, macOS и BSD. [78] Он имеет привязки для многих языков программирования, включая Ruby , Python и Haskell . [79] [80] [81]
JS-Git — это реализация JavaScript подмножества Git. [82]
Поскольку Git — это распределенная система контроля версий, ее можно использовать в качестве сервера «из коробки». Он поставляется со встроенной командой git daemon, которая запускает простой TCP-сервер, работающий по протоколу Git. [83] [84] Выделенные HTTP-серверы Git помогают (помимо других функций) путем добавления контроля доступа, отображения содержимого репозитория Git через веб-интерфейсы и управления несколькими репозиториями. Уже существующие репозитории Git можно клонировать и предоставлять к ним общий доступ для использования другими в качестве централизованного репозитория. Доступ к нему также можно получить через удаленную оболочку, просто установив программное обеспечение Git и разрешив пользователю войти в систему. [85] Серверы Git обычно прослушивают TCP-порт 9418. [86]
Открытый источник
Размещение сервера Git с использованием двоичного файла Git. [87]
Gerrit — сервер Git, настраиваемый для поддержки проверок кода и предоставления доступа через ssh, интегрированный Apache MINA или OpenSSH или интегрированный веб-сервер Jetty. Gerrit обеспечивает интеграцию клиентских сертификатов LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https. В Gerrit 3.0 все конфигурации будут храниться в виде репозиториев Git, и для запуска не потребуется база данных. В ядре Gerrit реализована функция запроса на включение, но для нее отсутствует графический интерфейс.
Phabricator — спин-офф Facebook. Поскольку Facebook в основном использует Mercurial , поддержка Git не так заметна. [88]
Внешние проекты, такие как gitolite, [89] которые предоставляют сценарии поверх программного обеспечения Git для обеспечения детального контроля доступа.
Существует несколько других решений FLOSS для самостоятельного хостинга, включая Gogs [90] и Gitea , ответвление Gogs, оба разработаны на языке Go с лицензией MIT .
Git-сервер как услуга
Существует множество предложений репозиториев Git в качестве услуги. Наиболее популярные — GitHub , SourceForge , Bitbucket и GitLab . [91] [17] [18] [19] [20]
Принятие
Фонд Eclipse Foundation сообщил в своем ежегодном опросе сообщества, что по состоянию на май 2014 года Git в настоящее время является наиболее широко используемым инструментом управления исходным кодом: 42,9% профессиональных разработчиков программного обеспечения сообщили, что они используют Git в качестве основной системы управления исходным кодом [92]. по сравнению с 36,3% в 2013 г., 32% в 2012 г.; или для ответов Git без учета использования GitHub : 33,3% в 2014 г., 30,3% в 2013 г., 27,6% в 2012 г. и 12,8% в 2011 г. [93] Каталог открытого исходного кода Black Duck Open Hub сообщает об аналогичном распространении среди проектов с открытым исходным кодом. [94]
Stack Overflow включил контроль версий в свой ежегодный опрос разработчиков [95] в 2015 году (16 694 ответа), [96] 2017 году (30 730 ответов), [97] 2018 году (74 298 ответов) [98] и 2022 году (71 379 ответов). [15] Git был подавляющим фаворитом среди опрошенных разработчиков в этих опросах: в 2022 году этот показатель составил 93,9%.
Системы контроля версий, используемые ответившими разработчиками:
Британский веб-сайт вакансий в области ИТ itjobswatch.co.uk сообщает, что по состоянию на конец сентября 2016 года 29,27% постоянных вакансий в области разработки программного обеспечения в Великобритании упоминали Git, [ 99] опережая 12,17% для Microsoft Team Foundation Server , [100] 10,60% для Subversion , [101] 1,30% для Mercurial , [102] и 0,48% для Visual SourceSafe . [103]
Расширения
Существует множество расширений Git , например Git LFS, который начинался как расширение Git в сообществе GitHub и теперь широко используется другими репозиториями. Расширения обычно разрабатываются и поддерживаются разными людьми независимо друг от друга, но в какой-то момент в будущем широко используемое расширение может быть объединено с Git.
Другие расширения Git с открытым исходным кодом включают:
git-annex — распределенная система синхронизации файлов на основе Git.
git-flow, набор расширений Git для обеспечения высокоуровневых операций с хранилищем для модели ветвления Винсента Дриссена.
git-machete, организатор репозитория и инструмент для автоматизации операций перебазирования, слияния, извлечения и отправки.
Microsoft разработала расширение Virtual File System для Git (VFS for Git; ранее Git Virtual File System или GVFS) для управления размером дерева исходного кода Windows в рамках миграции с Perforce в 2017 году . VFS для Git позволяет клонированным репозиториям использовать заполнители, содержимое которых загружается только после доступа к файлу. [104]
Конвенции
Git не накладывает особых ограничений на то, как его следует использовать, но для организации историй приняты некоторые соглашения, особенно те, которые требуют сотрудничества многих участников.
Основная ветка создается по умолчанию с помощью git init [62] [105] и часто используется как ветка, в которую объединяются другие изменения. [106] Соответственно, имя вышестоящего удаленного узла по умолчанию — origin [107] , поэтому имя удаленной ветки по умолчанию — origin/master . Использование master в качестве имени ветки по умолчанию не всегда верно; репозитории, созданные в GitHub и GitLab, инициализируются с основной веткой вместо master , [108] [109] , хотя пользователь может изменить значение по умолчанию.
Отправленные коммиты обычно не следует перезаписывать, а следует откатить [110] (поверх делается коммит, который отменяет изменения предыдущего коммита). Это предотвращает недействительность общих новых коммитов, основанных на общих коммитах, поскольку коммит, на котором они основаны, не существует на удаленном компьютере. Если коммиты содержат конфиденциальную информацию, их следует удалить, что предполагает более сложную процедуру перезаписи истории.
Рабочий процесс git-flow [111] и соглашения об именах часто принимаются для того, чтобы различать нестабильные истории конкретных функций (feature/*), нестабильные общие истории (разработка), готовые к производству истории (основные) и аварийные исправления для выпущенных продуктов (исправления).
Запросы на включение не являются функцией git, но обычно предоставляются облачными службами git. Запрос на включение — это запрос одного пользователя на объединение ветки своего репозитория с другим репозиторием, имеющим ту же историю (называемым вышестоящим удаленным). [112] [113] Основная функция запроса на включение не отличается от функции администратора репозитория, извлекающего изменения из другого удаленного хранилища (репозитория, который является источником запроса на включение). Однако сам запрос на включение представляет собой билет, управляемый хост-сервером, который инициирует сценарии для выполнения этих действий; это не особенность git SCM.
Безопасность
Git не предоставляет механизмов контроля доступа, но был разработан для работы с другими инструментами, специализирующимися на управлении доступом. [114]
17 декабря 2014 года был обнаружен эксплойт, затрагивающий версии клиента Git для Windows и macOS . Злоумышленник может выполнить произвольный код на целевом компьютере с установленным Git, создав вредоносное дерево Git (каталог) с именем .git (каталог в репозиториях Git, в котором хранятся все данные репозитория) в другом регистре (например, .GIT). или .Git, необходимый, поскольку Git не позволяет вручную создавать версию .git , написанную только строчными буквами ) с вредоносными файлами в подкаталоге .git/hooks (папка с исполняемыми файлами, которые запускает Git) в репозитории, созданном злоумышленником. или в репозитории, который злоумышленник может изменить. Если пользователь Windows или Mac извлекает (загружает) версию репозитория с вредоносным каталогом, а затем переключается на этот каталог, каталог .git будет перезаписан (из-за нечувствительности к регистру в файловых системах Windows и Mac) и могут быть запущены вредоносные исполняемые файлы в .git/hooks , что приведет к выполнению команд злоумышленника. Злоумышленник также может изменить файл конфигурации .git/config , что позволяет злоумышленнику создавать вредоносные псевдонимы Git (псевдонимы для команд Git или внешних команд) или изменять существующие псевдонимы для выполнения вредоносных команд при запуске. Уязвимость была исправлена в версии Git 2.2.1, выпущенной 17 декабря 2014 года, о которой было объявлено на следующий день. [115] [116]
Версия Git 2.6.1, выпущенная 29 сентября 2015 года, содержала исправление для уязвимости безопасности ( CVE — 2015-7545) [117] , которая позволяла выполнять произвольный код. [118] Эту уязвимость можно было использовать, если злоумышленник мог убедить жертву клонировать определенный URL-адрес, поскольку произвольные команды были встроены в сам URL-адрес. [119] Злоумышленник мог использовать эксплойт посредством атаки «человек посередине», если соединение было незашифрованным, [119] поскольку он мог перенаправить пользователя на URL-адрес по своему выбору. Рекурсивные клоны также были уязвимы, поскольку позволяли контроллеру репозитория указывать произвольные URL-адреса через файл gitmodules. [119]
Git использует внутри себя хэши SHA-1 . Линус Торвальдс ответил, что хэш в основном предназначен для защиты от случайного повреждения, а безопасность, которую обеспечивает криптографически безопасный хэш, была всего лишь случайным побочным эффектом, поскольку основная безопасность подписывалась где -то еще. [120] [121] После демонстрации атаки SHAttered на git в 2017 году git был модифицирован для использования варианта SHA-1, устойчивого к этой атаке. План перехода хэш-функции пишется с февраля 2020 года. [122]
Товарный знак
«Git» является зарегистрированным товарным знаком компании Software Freedom Conservancy под номером US500000085961336 с 3 февраля 2015 г.
^ GPL-2.0 - только с 11 апреля 2005 г. Некоторые части находятся под совместимыми лицензиями, такими как LGPLv2.1 . [6]
^ abcdefghijklmnopqrs Не указан в качестве опции в этом опросе.
Цитаты
^ «Первоначальная версия «git», адского информационного менеджера» . Гитхаб . 8 апреля 2005 г. Архивировано из оригинала 16 ноября 2015 г. Проверено 20 декабря 2015 г.
^ "График фиксации" . Гитхаб . 8 июня 2016 г. Архивировано из оригинала 20 января 2016 г. . Проверено 19 декабря 2015 г.
↑ Джунио С. Хамано (14 февраля 2024 г.). «[АНОНС] Git v2.43.2» . Проверено 15 февраля 2024 г.
^ "Сайт Git" . Архивировано из оригинала 9 июня 2022 года . Проверено 9 июня 2022 г.
^ "Зеркало исходного кода Git" . Гитхаб . Архивировано из оригинала 3 июня 2022 года . Проверено 9 июня 2022 г.
^ «Лицензия Git LGPL на github.com» . Гитхаб . 20 мая 2011 года. Архивировано из оригинала 11 апреля 2016 года . Проверено 12 октября 2014 г.
^ «Лицензия Git GPL на github.com» . Гитхаб . 18 января 2010 г. Архивировано из оригинала 11 апреля 2016 г. Проверено 12 октября 2014 г.
^ «Технический разговор: Линус Торвальдс на git (в 00:01:30)» . Архивировано из оригинала 20 декабря 2015 года . Проверено 20 июля 2014 г. - через YouTube.
^ Чакон и Штрауб 2014, стр. 29–31.
^ аб Торвальдс, Линус (7 апреля 2005 г.). «Re: Сага о Kernel SCM». linux-kernel (список рассылки). Архивировано из оригинала 1 июля 2019 года . Проверено 3 февраля 2017 г.«Поэтому я пишу несколько сценариев, чтобы попытаться отслеживать ситуацию намного быстрее».
^ аб Торвальдс, Линус (10 июня 2007 г.). «Re: фатально: серьезное раздутое несоответствие». git (список рассылки).
^ abcd Линус Торвальдс (3 мая 2007 г.). Google tech talk: Линус Торвальдс о git. Событие происходит в 02:30. Архивировано из оригинала 28 мая 2007 года . Проверено 16 мая 2007 г.
^ ab «Краткая история Git». Pro Git (2-е изд.). Апресс. 2014. Архивировано из оригинала 25 декабря 2015 года . Проверено 26 декабря 2015 г.
↑ Чакон, Скотт (24 декабря 2014 г.). Pro Git (2-е изд.). Нью-Йорк, штат Нью-Йорк: Апресс . стр. 29–30. ISBN978-1-4842-0077-3. Архивировано из оригинала 25 декабря 2015 года.
^ ab «Опрос разработчиков Stack Overflow, 2022 г.» . Переполнение стека . Проверено 4 августа 2022 г.
^ Криль, Пол (28 сентября 2016 г.). «Корпоративные войны репо: GitHub против GitLab против Bitbucket». Инфомир . Проверено 2 февраля 2020 г.
^ ab «Конкурентный анализ github.com, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 31 марта 2013 года . Проверено 2 февраля 2020 г.
^ ab «Конкурентный анализ sourceforge.net, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 20 октября 2020 года . Проверено 2 февраля 2020 г.
^ ab «Конкурентный анализ Bitbucket.org, маркетинговый комплекс и трафик». Алекса . Архивировано из оригинала 23 июня 2017 года . Проверено 2 февраля 2020 г.
^ ab «Конкурентный анализ gitlab.com, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 30 ноября 2017 года . Проверено 2 февраля 2020 г.
↑ Браун, Зак (27 июля 2018 г.). «История происхождения Git». Linux-журнал . Linux-журнал. Архивировано из оригинала 13 апреля 2020 года . Проверено 28 мая 2020 г.
^ «BitKeeper и Linux: конец пути?». Linux.com . 11 апреля 2005 года . Проверено 18 мая 2023 г.
↑ Макаллистер, Нил (2 мая 2005 г.). «Ошибка BitKeeper Линуса Торвальдса». Инфомир . Архивировано из оригинала 26 августа 2015 года . Проверено 8 сентября 2015 г.
^ аб Торвальдс, Линус (27 февраля 2007 г.). «Re: Общая информация: Когда git стал самостоятельным хостом?». git (список рассылки).
↑ Торвальдс, Линус (6 апреля 2005 г.). «Сага о Kernel SCM». linux-kernel (список рассылки).
↑ Торвальдс, Линус (17 апреля 2005 г.). «Первое настоящее слияние ядра git!». git (список рассылки).
↑ Макколл, Мэтт (29 апреля 2005 г.). «Mercurial 0.4b против теста git patchbomb». git (список рассылки).
↑ Торвальдс, Линус (17 июня 2005 г.). «Линукс 2.6.12». git-commits-head (список рассылки).
↑ Торвальдс, Линус (27 июля 2005 г.). «Знакомьтесь, новый сопровождающий». git (список рассылки).
↑ Хамано, Джунио К. (21 декабря 2005 г.). «Анонс: Git 1.0.0». git (список рассылки).
^ «GitFaq: Почему такое название «Git»?». Git.or.cz. Архивировано из оригинала 23 июля 2012 года . Проверено 14 июля 2012 г.
^ «После разногласий Торвальдс начинает работу над« git »» . Мир ПК . 14 июля 2012 г. Архивировано из оригинала 1 февраля 2011 г. Торвальдс, похоже, осознавал, что его решение отказаться от BitKeeper также будет спорным. Когда его спросили, почему он назвал новое программное обеспечение «мерзавцем», что на британском сленге означает «гнилой человек», он ответил. «Я эгоистичный ублюдок, поэтому все свои проекты называю в свою честь. Сначала Linux, теперь git».
^ "Страница руководства git(1)" . Архивировано из оригинала 21 июня 2012 года . Проверено 21 июля 2012 года .
^ «Первоначальная версия 'git', адского информационного менеджера · git/git@e83c516» . Гитхаб . Архивировано из оригинала 8 октября 2017 года . Проверено 21 января 2016 г.
^ «Git – Распределенные рабочие процессы» . Гит . Архивировано из оригинала 22 октября 2014 года . Проверено 15 июня 2020 г.
↑ Гунджал, Сиддхеш (19 июля 2019 г.). «Что такое инструмент контроля версий? Изучите Git и GitHub». Середина . Проверено 25 октября 2020 г.
↑ Торвальдс, Линус (19 октября 2006 г.). «Re: Сравнительная таблица VCS». git (список рассылки).
^ Блог Jst о Mozillazine "производительность bzr/hg/git". Архивировано из оригинала 29 мая 2010 года . Проверено 12 февраля 2015 г.
↑ Драйер, Роланд (13 ноября 2006 г.). «О, какое это облегчение». Архивировано из оригинала 16 января 2009 года., заметив, что «git log» работает в 100 раз быстрее, чем «svn log», поскольку последний должен связаться с удаленным сервером.
^ «Доверие». Концепции Git . Руководство пользователя Git. 18 октября 2006 г. Архивировано из оригинала 22 февраля 2017 г.
^ Торвальдс, Линус. «Re: Сравнительная таблица VCS». git (список рассылки) . Проверено 10 апреля 2009 г., описывающий скрипт-ориентированный дизайн Git
^ Ябервон (22 декабря 2005 г.). «Гит рулит!». Архивировано из оригинала 14 сентября 2016 года., хваля возможности Git по написанию сценариев.
^ "Git - Git SCM Wiki" . git.wiki.kernel.org . Проверено 25 октября 2020 г.
^ Чакон и Штрауб 2014.
^ «Руководство пользователя Git». 10 марта 2020 г. Архивировано из оригинала 10 мая 2020 г.
^ Чакон и Штрауб 2014, с. 499.
^ Чакон и Штрауб, 2014, стр. 33–34.
^ ab «Git – Packfiles». Гит .
^ Чакон и Штрауб 2014, с. 568.
↑ Торвальдс, Линус (10 апреля 2005 г.). «Re: больше обновлений git». linux-kernel (список рассылки).
↑ Хайбле, Бруно (11 февраля 2007 г.). «как ускорить «git log»?». git (список рассылки).
↑ Торвальдс, Линус (1 марта 2006 г.). «Re: нечистые переименования/отслеживание истории». git (список рассылки).
↑ Хамано, Джунио К. (24 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils». git (список рассылки).
↑ Хамано, Джунио К. (23 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils». git (список рассылки).
↑ Торвальдс, Линус (28 ноября 2006 г.). «Re: git и bzr». git (список рассылки)., при использовании git-blameдля отображения кода, перемещаемого между исходными файлами.
↑ Торвальдс, Линус (18 июля 2007 г.). «git-merge(1)». Архивировано из оригинала 16 июля 2016 года.
↑ Торвальдс, Линус (18 июля 2007 г.). «КриссКроссСлияние». Архивировано из оригинала 13 января 2006 года.
↑ Торвальдс, Линус (10 апреля 2005 г.). «Re: больше обновлений git...» linux-kernel (список рассылки).
↑ Торвальдс, Линус (23 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils». git (список рассылки). Архивировано из оригинала 22 марта 2021 года . Проверено 3 февраля 2017 г.
^ «Git – Объекты Git». Гит .
^ Некоторые внутренности git
^ ab Chacon & Straub 2014, стр. 81–83.
^ Чакон и Штрауб, 2014, стр. 485–488.
^ Чакон и Штрауб, 2014, стр. 488–490.
^ Чакон и Штрауб, 2014, стр. 495–496.
^ Чакон и Штрауб 2014, стр. 497–501.
^ "Git - Ссылки на Git" . Гит .
^ «Формат файла конфигурации проекта» . Обзор кода Геррита . Архивировано из оригинала 3 декабря 2020 года . Проверено 2 февраля 2020 г.
^ «Загрузки». Архивировано из оригинала 8 мая 2012 года . Проверено 14 мая 2012 г.
^ «Версии пакетов git – Репология» . Архивировано из оригинала 19 января 2022 года . Проверено 30 ноября 2021 г.
^ "мсисГит". Гитхаб . Архивировано из оригинала 10 октября 2016 года . Проверено 20 сентября 2016 г.
^ «Git – Загрузка пакета» . Гит .(исходный код)
^ "ДжГит". Архивировано из оригинала 31 августа 2012 года . Проверено 24 августа 2012 г.
^ "Гит - давай-гит" . Гит . Проверено 19 апреля 2019 г.
^ «Интерфейс SQL для репозиториев Git, написанный на Go», github.com , получено 19 апреля 2019 г.
^ «Keybase запускает зашифрованный git» . keybase.io . Проверено 19 апреля 2019 г.
^ "Далвич". Архивировано из оригинала 29 мая 2012 года . Проверено 27 августа 2012 г.
^ "libgit2". Гитхаб . Архивировано из оригинала 11 апреля 2016 года . Проверено 24 августа 2012 г.
^ "Прочный". Гитхаб . Архивировано из оригинала 24 июля 2013 года . Проверено 24 августа 2012 г.
^ "Пигит2". Гитхаб . Архивировано из оригинала 5 августа 2015 года . Проверено 24 августа 2012 г.
^ "хлибгит2". Архивировано из оригинала 25 мая 2013 года . Проверено 30 апреля 2013 г.
^ «js-git: реализация Git на JavaScript» . Гитхаб . Архивировано из оригинала 7 августа 2013 года . Проверено 13 августа 2013 г.
^ Чакон и Штрауб, 2014, стр. 138–139.
^ "Git - Git Daemon" . Гит . Проверено 10 июля 2019 г.
^ 4.4 Git на сервере — настройка сервера. Архивировано 22 октября 2014 г. на Wayback Machine , Pro Git.
^ «1.4 Начало работы – установка Git» . Гит. Архивировано из оригинала 2 ноября 2013 года . Проверено 1 ноября 2013 г.
^ Чакон, Скотт; Штрауб, Бен (2014). «Git на сервере – Настройка сервера». Pro Git (2-е изд.). Апресс. ISBN978-1484200773.
^ Руководство пользователя Diffusion: Хостинг репозитория. Архивировано 20 сентября 2020 г. на Wayback Machine .
^ «Основные моменты Git 2.26» . Блог GitHub . 22 марта 2020 г. Архивировано из оригинала 22 марта 2021 г. . Проверено 25 ноября 2020 г. Возможно, вы помните, когда еще в 2018 году Git представил новую версию своего протокола сетевой выборки. Теперь этот протокол используется по умолчанию в версии 2.26, поэтому давайте освежим информацию о том, что это значит. Самая большая проблема старого протокола заключается в том, что сервер немедленно перечисляет все ветки, теги и другие ссылки в репозитории, прежде чем клиент сможет что-либо отправить. Для некоторых репозиториев это может означать отправку мегабайтов дополнительных данных, когда клиент действительно хочет знать только о главной ветке. Новый протокол начинается с запроса клиента и предоставляет клиенту возможность сообщить серверу, какие ссылки его интересуют. При выборе одной ветки будет запрашиваться только об этой ветке, в то время как большинство клонов будут запрашивать только о ветках и тегах. Это может показаться всем, но репозитории серверов могут хранить и другие ссылки (например, заголовок каждого запроса на включение, открытого в репозитории с момента его создания). Теперь скорость выборки из больших репозиториев увеличивается, особенно когда сама выборка невелика, что, условно говоря, делает стоимость первоначальной ссылочной рекламы более дорогой. И самое приятное то, что вам не нужно ничего делать! Благодаря продуманной конструкции любой клиент, поддерживающий новый протокол, может беспрепятственно работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним пользователям обнаружить любые ошибки.
^ «Результаты опроса сообщества Eclipse 2014 | Ян Скерретт» . Ianskerrett.wordpress.com. 23 июня 2014 года. Архивировано из оригинала 25 июня 2014 года . Проверено 23 июня 2014 г.
^ «Результаты опроса сообщества Eclipse 2012» . eclipse.org. Архивировано из оригинала 11 апреля 2016 года.
^ «Сравнить репозитории - Open Hub» . Архивировано из оригинала 7 сентября 2014 года.
^ «Ежегодный опрос разработчиков Stack Overflow» . Стек Биржа, Inc. Проверено 9 января 2020 г. Ежегодный опрос разработчиков Stack Overflow — это крупнейший и наиболее полный опрос людей, которые программируют по всему миру. Каждый год мы проводим опрос, охватывающий все: от любимых технологий разработчиков до их предпочтений в работе. В этом году мы уже девятый раз публикуем результаты ежегодного опроса разработчиков, и в начале этого года почти 90 000 разработчиков приняли участие в 20-минутном опросе.
^ «Опрос разработчиков Stack Overflow, 2015» . Переполнение стека. Архивировано из оригинала 4 мая 2019 года . Проверено 29 мая 2019 г.
^ «Опрос разработчиков Stack Overflow, 2017» . Переполнение стека. Архивировано из оригинала 29 мая 2019 года . Проверено 29 мая 2019 г.
^ «Опрос разработчиков Stack Overflow, 2018» . Переполнение стека. Архивировано из оригинала 30 мая 2019 года . Проверено 29 мая 2019 г.
^ «Работа в Git (программное обеспечение), средняя зарплата для навыков работы с распределенной системой контроля версий Git» . Itjobswatch.co.uk. Архивировано из оригинала 8 октября 2016 года . Проверено 30 сентября 2016 г.
^ «Работа на сервере Team Foundation Server, средняя зарплата для навыков Microsoft Team Foundation Server (TFS)» . Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Проверено 30 сентября 2016 г.
^ «Работа по подрывной деятельности, средняя зарплата для навыков Apache Subversion (SVN)» . Itjobswatch.co.uk. Архивировано из оригинала 25 октября 2016 года . Проверено 30 сентября 2016 г.
^ «Метуативные рабочие места, средняя зарплата для ртутных навыков» . Itjobswatch.co.uk. Архивировано из оригинала 23 сентября 2016 года . Проверено 30 сентября 2016 г.
^ «Работа VSS/SourceSafe, средняя зарплата для навыков Microsoft Visual SourceSafe (VSS)» . Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Проверено 30 сентября 2016 г.
^ «Переход Windows на Git почти завершен: 8500 коммитов и 1760 сборок каждый день» . Арс Техника . 24 мая 2017 года. Архивировано из оригинала 24 мая 2017 года . Проверено 24 мая 2017 г.
^ "git-инициализация". Гит . Архивировано из оригинала 15 марта 2022 года.
^ «Git - Коротко о ветках» . Гит . Архивировано из оригинала 20 декабря 2020 года . Проверено 15 июня 2020 г. Ветка «master» в Git не является специальной веткой. Это точно так же, как и любая другая отрасль. Единственная причина, по которой он есть почти в каждом репозитории, заключается в том, что команда git init создает его по умолчанию, и большинство людей не удосуживаются его изменить.
^ Чакон и Штрауб 2014, стр. 103–109.
^ github/renameming, GitHub, 4 декабря 2020 г. , получено 4 декабря 2020 г.
^ Имя ветки по умолчанию для новых репозиториев, которые теперь являются основными, GitLab, 22 июня 2021 г. , получено 22 июня 2021 г.
^ "Git Revert | Учебное пособие по Atlassian Git" . Атласиан . Возврат имеет два важных преимущества перед сбросом. Во-первых, он не меняет историю проекта, что делает его «безопасной» операцией для коммитов, которые уже были опубликованы в общем репозитории.
^ «Рабочий процесс Gitflow | Учебное пособие по Atlassian Git» . Атласиан . Проверено 15 июня 2020 г.
^ Чакон и Штрауб, 2014, стр. 170–174.
^ «Рабочий процесс разветвления | Учебное пособие по Atlassian Git» . Атласиан . Проверено 15 июня 2020 г.
^ «Контроль доступа к репозиторию Git» . Архивировано из оригинала 14 сентября 2016 года . Проверено 6 сентября 2016 г.
↑ Петтерсен, Тим (20 декабря 2014 г.). «Защита вашего сервера Git от CVE-2014-9390». Архивировано из оригинала 24 декабря 2014 года . Проверено 22 декабря 2014 г.
↑ Хамано, JC (18 декабря 2014 г.). «[Анонс] Git v2.2.1 (и обновления для старых версий обслуживания)». Группа новостей : gmane.linux.kernel. Архивировано из оригинала 19 декабря 2014 года . Проверено 22 декабря 2014 г.
^ «CVE-2015-7545». 15 декабря 2015 года. Архивировано из оригинала 26 декабря 2015 года . Проверено 26 декабря 2015 г.
^ "Git 2.6.1" . Гитхаб . 29 сентября 2015 года. Архивировано из оригинала 11 апреля 2016 года . Проверено 26 декабря 2015 г.
^ abc Блейк Беркхарт; и другие. (5 октября 2015 г.). «Re: Запрос CVE: git». Архивировано из оригинала 27 декабря 2015 года . Проверено 26 декабря 2015 г.
^ «хеш — насколько безопасны подписанные теги git? Только так же безопасно, как SHA-1, или как-то безопаснее?». Обмен стеками информационной безопасности. 22 сентября 2014 г. Архивировано из оригинала 24 июня 2016 г.
^ «Почему Git использует криптографическую хэш-функцию?». Переполнение стека. 1 марта 2015 г. Архивировано из оригинала 1 июля 2016 г.
^ «Git – Документация по переходу хэш-функций» . Гит .
Рекомендации
Чакон, Скотт (24 декабря 2014 г.). Pro Git (2-е изд.). Нью-Йорк, штат Нью-Йорк: Апресс . ISBN 978-1-4842-0077-3. Архивировано из оригинала 25 декабря 2015 года.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
