Гит

Распределенная система управления версиями программного обеспечения

Git ( / ɡ ɪ t / ) ^[8] — это распределенная система контроля версий ^[9] , которая отслеживает версии файлов . Она часто используется для контроля исходного кода программистами, которые совместно разрабатывают программное обеспечение .

Цели разработки Git включают скорость, целостность данных и поддержку распределенных , нелинейных рабочих процессов — тысяч параллельных ветвей , работающих на разных компьютерах. ^{[10] [11] [12]}

Git был создан для использования при разработке ядра Linux Линусом Торвальдсом и другими разработчиками ядра. ^[13]

Как и большинство других распределенных систем управления версиями, и в отличие от большинства клиент-серверных систем, Git поддерживает локальную копию всего репозитория , также известного как репозиторий, с возможностями истории и отслеживания версий, независимо от доступа к сети или центрального сервера . Репозиторий хранится на каждом компьютере в стандартном каталоге с дополнительными скрытыми файлами для обеспечения возможностей управления версиями. ^[14] Git предоставляет функции для синхронизации изменений между репозиториями, которые разделяют историю; копируются (клонируются) друг из друга. Для совместной работы Git поддерживает синхронизацию с репозиториями на удаленных машинах. Хотя все репозитории (с одинаковой историей) являются одноранговыми, разработчики часто используют центральный сервер для размещения репозитория для хранения интегрированной копии.

Git — это бесплатное программное обеспечение с открытым исходным кодом, распространяемое только по лицензии GPL-2.0 .

Торговая марка «Git» зарегистрирована организацией Software Freedom Conservancy , что означает ее официальное признание и дальнейшее развитие в сообществе разработчиков ПО с открытым исходным кодом .

Сегодня Git является фактически стандартной системой контроля версий. Это самая популярная распределенная система контроля версий, и почти 95% разработчиков сообщают, что она является их основной системой контроля версий по состоянию на 2022 год. ^[15] Это наиболее широко используемый инструмент управления исходным кодом среди профессиональных разработчиков. Существуют предложения услуг репозитория Git, включая GitHub , SourceForge , Bitbucket и GitLab . ^{[16] [17] [18] [19] [20]}

История

Торвальдс начал разрабатывать Git в апреле 2005 года после того, как бесплатная лицензия на BitKeeper , фирменную систему управления исходным кодом (SCM), используемую для разработки ядра Linux с 2002 года, была отозвана для Linux. ^{[21] [22]} Владелец авторских прав на BitKeeper, Ларри МакВой , утверждал, что Эндрю Триджелл создал SourcePuller путем обратного проектирования протоколов BitKeeper . ^[23] Тот же инцидент также подстегнул создание Mercurial , другой системы управления версиями.

Торвальдс хотел иметь распределенную систему, которую он мог бы использовать, как 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]

В файле read-me исходного кода это поясняется более подробно: ^[34]

«git» может означать что угодно, в зависимости от вашего настроения.

• Случайная комбинация из трех букв, которая произносится и фактически не используется ни одной из обычных команд UNIX. Тот факт, что это неправильное произношение "get", может иметь значение, а может и нет.
• Глупый. Презренный и подлый. Простой. Выбирайте из словаря сленга.
• «Глобальный информационный трекер»: у вас хорошее настроение, и оно действительно работает на вас. Ангелы поют, и свет внезапно заполняет комнату.
• «Проклятый идиотский грузовик дерьма»: когда он ломается.

Исходный код Git называет программу «адским менеджером информации».

Характеристики

Дизайн

Дизайн Git представляет собой синтез опыта Торвальдса с Linux в поддержке большого распределенного проекта разработки, а также его глубоких знаний о производительности файловой системы, полученных в том же проекте, и срочной необходимости создать работающую систему в короткие сроки. Эти влияния привели к следующим вариантам реализации: ^[13]

Сильная поддержка нелинейного развития

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

Распределенная разработка

Подобно Darcs , BitKeeper , Mercurial , Bazaar и Monotone , Git предоставляет каждому разработчику локальную копию полной истории разработки, а изменения копируются из одного такого репозитория в другой. Эти изменения импортируются как добавленные ветви разработки и могут быть объединены таким же образом, как и локально разработанная ветвь. ^[35]

Совместимость с существующими системами и протоколами

Репозитории могут быть опубликованы через протокол Hypertext Transfer Protocol Secure (HTTPS), протокол Hypertext Transfer Protocol (HTTP), протокол File Transfer Protocol (FTP) или протокол Git либо через обычный сокет, либо через Secure Shell (ssh). Git также имеет эмуляцию сервера CVS, которая позволяет использовать существующие клиенты CVS и плагины IDE для доступа к репозиториям Git. Репозитории Subversion можно использовать напрямую с git-svn. ^[36]

Эффективная обработка крупных проектов

Торвальдс описал 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 хранит каждый вновь созданный объект как отдельный файл. Хотя он сжимается индивидуально, это занимает много места и неэффективно. Это решается с помощью пакетов , которые хранят большое количество объектов, сжатых дельта-компрессией между собой в одном файле (или сетевом потоке байтов), называемом packfile . Пакеты сжимаются с использованием эвристики , что файлы с одинаковым именем, вероятно, похожи, без зависимости от этого для корректности. Для каждого packfile создается соответствующий индексный файл, сообщающий смещение каждого объекта в packfile. Недавно созданные объекты (с недавно добавленной историей) по-прежнему хранятся как отдельные объекты, и для поддержания эффективности использования пространства требуется периодическая переупаковка. Процесс упаковки репозитория может быть очень затратным с точки зрения вычислений. Разрешая объектам существовать в репозитории в свободном, но быстро сгенерированном формате, Git позволяет отложить дорогостоящую операцию упаковки на более позднее время, когда время имеет меньшее значение, например, на конец рабочего дня. Git выполняет периодическую переупаковку автоматически, но ручная переупаковка также возможна с помощью команды git gc. ^[46] Для целостности данных и пакфайл, и его индекс имеют внутри контрольную сумму SHA-1 ^[47] , а имя файла пакфайла также содержит контрольную сумму SHA-1. Чтобы проверить целостность репозитория, выполните команду git fsck. ^{[48] [49]}

Еще одним свойством Git является то, что он делает снимки деревьев каталогов файлов. Самые ранние системы отслеживания версий исходного кода, Source Code Control System (SCCS) и Revision Control System (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 — это содержимое файла . Blob не имеют собственного имени файла, временных меток или других метаданных (внутреннее имя blob — это хэш его содержимого). В Git каждый blob — это версия файла, в которой находятся данные файла. ^[61]
• Объект дерева является эквивалентом каталога. Он содержит список имен файлов, ^[62] каждый с некоторыми битами типа и ссылкой на объект blob или дерева, который является этим файлом, символической ссылкой или содержимым каталога. Эти объекты являются снимком исходного дерева. (В целом это включает дерево Меркла , что означает, что достаточно только одного хеша для корневого дерева, который фактически используется в коммитах для точного указания точного состояния целых древовидных структур любого количества подкаталогов и файлов.)
• Объект коммита связывает объекты дерева вместе в историю. Он содержит имя объекта дерева (исходного каталога верхнего уровня), временную метку, сообщение журнала и имена нуля или более родительских объектов коммита. ^[63]
• Объект тега — это контейнер, который содержит ссылку на другой объект и может содержать дополнительные метаданные, связанные с другим объектом. Чаще всего он используется для хранения цифровой подписи объекта фиксации, соответствующего определенному выпуску данных, отслеживаемых Git. ^[64]
• Объект packfile собирает различные другие объекты в сжатый zlib пакет для компактности и простоты передачи по сетевым протоколам. ^[65]

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

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

Кроме того, Git хранит метки, называемые refs (сокращение от references), для указания местоположений различных коммитов. Они хранятся в справочной базе данных и соответственно: ^[66]

• Головы (ветви) : именованные ссылки, которые автоматически перемещаются в новый коммит, когда поверх них делается коммит.
• HEAD : зарезервированная голова, которая будет сравниваться с рабочим деревом для создания коммита.
• Теги : Как ссылки на ветки, но привязанные к определенному коммиту. Используются для обозначения важных моментов в истории.

Команды

Часто используемые команды для интерфейса командной строки Git включают в себя: ^{[67] [68]}

• git init, который используется для создания репозитория git.
• git clone [URL], который клонирует или дублирует репозиторий git из внешнего URL.
• git add [file], который добавляет файл в рабочий каталог git (файлы, которые будут зафиксированы).
• git commit -m [commit message], который фиксирует файлы из текущего рабочего каталога (теперь они становятся частью истории репозитория).

Файл .gitignore может быть создан в репозитории Git как простой текстовый файл . Файлы, перечисленные в файле .gitignore , не будут отслеживаться Git. ^{[69] : 3–4} Эта функция может использоваться для игнорирования файлов с ключами или паролями, различных посторонних файлов и больших файлов (которые GitHub откажется загружать). ^[70]

Ссылки Git

Каждый объект в базе данных Git, на который нет ссылок, может быть очищен с помощью команды сборки мусора или автоматически. На объект может ссылаться другой объект или явная ссылка. В Git есть разные типы ссылок. Команды для создания, перемещения и удаления ссылок различаются. git show-refперечисляет все ссылки. Вот некоторые типы:

• головы : относится к объекту локально,
• remotes : относится к объекту, который существует в удаленном репозитории,
• stash : относится к объекту, который еще не зафиксирован,
• meta : например , конфигурация в пустом репозитории, права пользователя; пространство имен refs/meta/config было введено ретроспективно, используется Gerrit , ^[71]
• теги : см. выше.

Реализации

gitg — это графический интерфейс, использующий GTK+ .

Git (основная реализация на языке C) в первую очередь разработана для Linux , хотя она также поддерживает большинство основных операционных систем, включая BSD ( DragonFly BSD , FreeBSD , NetBSD и OpenBSD ), Solaris , macOS и Windows . ^{[72] [73]}

Первый порт Git для Windows был в первую очередь фреймворком эмуляции Linux, на котором размещалась версия Linux. Установка Git под Windows создает каталог Program Files с похожим названием, содержащий порт Mingw-w64 GNU Compiler Collection , Perl 5, MSYS2 (который сам по себе является ответвлением Cygwin , среды эмуляции Unix для Windows) и различные другие порты Windows или эмуляции утилит и библиотек Linux. В настоящее время собственные сборки Git для Windows распространяются в виде 32- и 64-битных установщиков. ^[74] Официальный сайт git в настоящее время поддерживает сборку Git для Windows, по-прежнему использующую среду MSYS2. ^[75]

Реализация Git в JGit — это чистая библиотека программного обеспечения Java , разработанная для встраивания в любое приложение Java. JGit используется в инструменте проверки кода Gerrit и в EGit, клиенте Git для Eclipse IDE. ^[76]

Go-git — это реализация Git с открытым исходным кодом, написанная на чистом Go . ^[77] В настоящее время она используется для поддержки проектов в качестве интерфейса SQL для репозиториев кода Git ^[78] и обеспечивает шифрование для Git. ^[79]

Dulwich — это реализация Git, написанная на чистом Python с поддержкой CPython 3.6 и более поздних версий, а также Pypy. ^[80]

Реализация Git libgit2 — это программная библиотека ANSI C без других зависимостей, которая может быть собрана на нескольких платформах, включая Windows, Linux, macOS и BSD. ^[81] Она имеет привязки ко многим языкам программирования, включая Ruby , Python и Haskell . ^{[82] [83] [84]}

JS-Git — это реализация подмножества Git на JavaScript . ^[85]

GameOfTrees — это реализация Git с открытым исходным кодом для проекта OpenBSD. ^[86]

Git-сервер

Скриншот интерфейса Gitweb, показывающий разницу коммитов

Поскольку Git — это распределенная система управления версиями, ее можно использовать как сервер «из коробки». Она поставляется со встроенной командой git daemon, которая запускает простой TCP-сервер, работающий по протоколу Git. ^{[87] [88]} Выделенные HTTP-серверы Git помогают (помимо других функций) добавлять контроль доступа, отображать содержимое репозитория Git через веб-интерфейсы и управлять несколькими репозиториями. Уже существующие репозитории Git можно клонировать и делиться ими, чтобы другие могли использовать их как централизованный репозиторий. К нему также можно получить доступ через удаленную оболочку, просто установив программное обеспечение Git и разрешив пользователю войти в систему. ^[89] Серверы Git обычно прослушивают порт TCP 9418. ^[90]

С открытым исходным кодом

• Хостинг сервера Git с использованием Git Binary. ^[91]
• Gerrit — сервер Git, настраиваемый для поддержки проверок кода и предоставления доступа через ssh, интегрированный Apache MINA или OpenSSH или интегрированный веб-сервер Jetty . Gerrit обеспечивает интеграцию с LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, клиентскими сертификатами X509 https. С Gerrit 3.0 все конфигурации будут храниться в виде репозиториев Git, и для работы не требуется база данных. В ядре Gerrit реализована функция pull-request, но для нее отсутствует графический интерфейс.
• Phabricator , ответвление Facebook. Поскольку Facebook в основном использует Mercurial , поддержка Git не так заметна. ^[92]
• RhodeCode Community Edition (CE), поддерживающий Git, Mercurial и Subversion с лицензией AGPLv3 .
• Kallithea , поддерживающая Git и Mercurial , разработанная на Python по лицензии GPL .
• Внешние проекты, такие как gitolite, ^[93], которые предоставляют скрипты поверх программного обеспечения Git для обеспечения детального контроля доступа.
• Существует несколько других решений FLOSS для самостоятельного хостинга, включая Gogs, ^[94] Gitea , ответвление Gogs, а также Forgejo , который, в свою очередь, является ответвлением Gitea. Gogs, как и два вышеупомянутых его производных, разработаны с использованием языка Go . Все три решения доступны по лицензии MIT .

Git-сервер как услуга

Существует множество предложений репозиториев Git как сервиса. Наиболее популярными являются GitHub , SourceForge , Bitbucket и GitLab . ^{[95] [17] [18] [19] [20]}

Графические интерфейсы

Git, мощная система контроля версий, может быть пугающей из-за своего интерфейса командной строки. Клиенты Git GUI предлагают графический пользовательский интерфейс (GUI) для упрощения взаимодействия с репозиториями Git.

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

Git поставляется с графическим интерфейсом Tcl/Tk , который позволяет пользователям выполнять такие действия, как создание и изменение коммитов, создание и слияние ветвей, а также взаимодействие с удаленными репозиториями. ^[96]

В дополнение к официальному графическому интерфейсу пользователя существует множество сторонних интерфейсов, которые предоставляют функции, аналогичные официальному графическому интерфейсу пользователя, распространяемому с Git, например, GitHub Desktop, SourceTree и TortoiseGit. ^[97]

Клиенты GUI облегчают изучение и использование Git, повышая эффективность рабочего процесса и сокращая количество ошибок. Популярные варианты включают кроссплатформенный GitKraken Desktop (freemium) и Sourcetree (бесплатно/платно) или платформенно-зависимые варианты, такие как GitHub Desktop (бесплатно) для Windows/macOS и TortoiseGit (бесплатно) для Windows.

Список клиентов GUI

Хотя Git предоставляет встроенные инструменты с графическим интерфейсом (git-gui, gitk), более широкий спектр сторонних опций учитывает предпочтения пользователей, зависящие от платформы.

Графические интерфейсы Windows (GNU GPL/MIT и бесплатные)

• GitHub для рабочего стола
• SourceTree
• TortoiseGit
• Расширения Git
• гитг
• MeGit (на основе EGit)
• GitUI

Графические интерфейсы Mac (GNU GPL/MIT и бесплатные)

• GitHub для рабочего стола
• SourceTree

Графические интерфейсы Linux (GNU GPL/MIT и бесплатные)

• гитг
• MeGit (на основе EGit)
• GitUI
• хихиканье

Фирменный графический интерфейс GIT

• SmartGit (Windows, Linux, Mac)
• GitKraken для ПК (Windows, Linux, Mac)
• Глинт (Windows, Linux, Mac)

Принятие

Фонд Eclipse сообщил в своем ежегодном опросе сообщества, что по состоянию на май 2014 года Git в настоящее время является наиболее широко используемым инструментом управления исходным кодом, при этом 42,9% профессиональных разработчиков программного обеспечения сообщили, что они используют Git в качестве своей основной системы управления исходным кодом ^[98] по сравнению с 36,3% в 2013 году, 32% в 2012 году; или для ответов Git без учета использования GitHub : 33,3% в 2014 году, 30,3% в 2013 году, 27,6% в 2012 году и 12,8% в 2011 году. ^[99] Каталог открытого исходного кода Black Duck Open Hub сообщает о похожем внедрении среди проектов с открытым исходным кодом. ^[100]

Stack Overflow включил контроль версий в свой ежегодный опрос разработчиков ^[101] в 2015 году (16 694 ответа), ^[102] 2017 году (30 730 ответов), ^[103] 2018 году (74 298 ответов) ^[104] и 2022 году (71 379 ответов). ^[15] Git был подавляющим фаворитом разработчиков, участвовавших в этих опросах, сообщив о 93,9% в 2022 году.

Системы контроля версий, используемые разработчиками-респондентами:

Британский сайт по трудоустройству в сфере ИТ itjobswatch.co.uk сообщает, что по состоянию на конец сентября 2016 года 29,27% постоянных вакансий по разработке программного обеспечения в Великобритании ссылались на Git, ^[105] опережая 12,17% для Microsoft Team Foundation Server , ^[106] 10,60% для Subversion , ^[107] 1,30% для Mercurial , ^[108] и 0,48% для Visual SourceSafe . ^[109]

Расширения

Существует множество расширений Git , например Git LFS, который начинался как расширение Git в сообществе GitHub и теперь широко используется другими репозиториями. Расширения обычно разрабатываются и поддерживаются разными людьми независимо, но в какой-то момент в будущем широко используемое расширение может быть объединено с Git.

Другие расширения Git с открытым исходным кодом включают:

• git-annex , распределенная система синхронизации файлов на основе Git
• git-flow, набор расширений Git для обеспечения высокоуровневых операций репозитория для модели ветвления Винсента Дриссена
• git-machete, органайзер репозитория и инструмент для автоматизации операций rebase/merge/pull/push

Microsoft разработала расширение Virtual File System for Git (VFS for Git; ранее Git Virtual File System или GVFS) для обработки размера дерева исходного кода Windows в рамках миграции с Perforce в 2017 году . VFS for Git позволяет клонированным репозиториям использовать заполнители, содержимое которых загружается только после доступа к файлу. ^[110]

Конвенции

Git можно использовать разными способами, но общепринятыми являются некоторые соглашения.

• Команда для создания локального репозитория git init создает ветку с именем master . ^{[61] [111]} Часто она используется в качестве ветки интеграции для слияния изменений в. ^[112] Поскольку удаленная ветка upstream по умолчанию называется origin , ^[113] удаленная ветка по умолчанию — origin/master . Некоторые инструменты, такие как GitHub и GitLab, вместо этого создают ветку по умолчанию с именем main . ^{[114] [115]} Кроме того, пользователи могут добавлять и удалять ветки и выбирать любую ветку для интеграции.
• Pushed commits обычно не перезаписываются, а отменяются ^[116] путем фиксации другого изменения, которое отменяет более раннюю фиксацию. Это предотвращает недействительность общих фиксаций, поскольку фиксация, на которой они основаны, не существует в удаленном режиме. Если фиксации содержат конфиденциальную информацию, их следует удалить, что подразумевает более сложную процедуру перезаписи истории.
• Рабочий процесс git -flow ^[117] и соглашения об именовании часто применяются для различения нестабильных историй, специфичных для функций (feature/*), нестабильных общих историй (develop), готовых к производству историй (main) и экстренных исправлений для выпущенных продуктов (hotfix).
• Запрос на извлечение , он же запрос на слияние , — это запрос пользователя на слияние ветки с другой веткой. ^{[118] [119]} Сам по себе Git не предоставляет запросы на извлечение, но это обычная функция облачных сервисов Git. Основная функция запроса на извлечение ничем не отличается от функции администратора репозитория, извлекающего изменения из другого удаленного репозитория (репозитория, который является источником запроса на извлечение). Однако сам запрос на извлечение — это тикет, управляемый сервером хостинга, который выполняет эти действия; это не функция git SCM.

Безопасность

Git не предоставляет механизмов контроля доступа, но был разработан для работы с другими инструментами, специализирующимися на контроле доступа. ^[120]

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 или внешних команд) или изменять существующие псевдонимы для выполнения вредоносных команд при запуске. Уязвимость была исправлена ​​в версии 2.2.1 Git, выпущенной 17 декабря 2014 года и анонсированной на следующий день. ^{[121] [122]}

Версия Git 2.6.1, выпущенная 29 сентября 2015 года, содержала исправление для уязвимости безопасности (CVE-2015-7545) ^[123] , которая допускала выполнение произвольного кода. ^[124] Уязвимость можно было использовать, если злоумышленник мог убедить жертву клонировать определенный URL-адрес, поскольку произвольные команды были встроены в сам URL-адрес. ^[125] Злоумышленник мог использовать эксплойт с помощью атаки «человек посередине», если соединение было незашифрованным, ^[125] поскольку он мог перенаправить пользователя на URL-адрес по своему выбору. Рекурсивные клоны также были уязвимы, поскольку они позволяли контроллеру репозитория указывать произвольные URL-адреса через файл gitmodules. ^[125]

Git использует хэши SHA-1 внутри. Линус Торвальдс ответил, что хэш в основном был предназначен для защиты от случайного повреждения, а безопасность, которую обеспечивает криптографически безопасный хэш, была всего лишь случайным побочным эффектом, а основная безопасность заключалась в подписи в другом месте. ^{[126] [127]} После демонстрации атаки SHAttered против git в 2017 году git был модифицирован для использования варианта SHA-1, устойчивого к этой атаке. План перехода на хэш-функцию пишется с февраля 2020 года. ^[128]

Торговая марка

«Git» является зарегистрированной словесной торговой маркой Software Freedom Conservancy под номером US500000085961336 с 03.02.2015.

Смотрите также

• Портал бесплатного и открытого программного обеспечения
• Linux-портал
• Интернет-портал

• Сравнение возможностей размещения исходного кода
• Сравнение программного обеспечения для контроля версий
• Список программного обеспечения для контроля версий

Примечания

1. GPL-2.0-only с 2005-04-11. Некоторые части под совместимыми лицензиями, такими как LGPLv2.1 . ^[6]
2. Не указано в качестве варианта в этом опросе

Цитаты

1. "Первоначальная редакция "git", информационного менеджера из ада". GitHub . 8 апреля 2005 г. Архивировано из оригинала 16 ноября 2015 г. Получено 20 декабря 2015 г.
2. "Commit Graph". GitHub . 8 июня 2016 г. Архивировано из оригинала 20 января 2016 г. Получено 19 декабря 2015 г.
3. Джунио С. Хамано (7 октября 2024 г.). «[АНОНС] Git v2.47.0» . Проверено 8 октября 2024 г.
4. "Git website". Архивировано из оригинала 9 июня 2022 г. Получено 9 июня 2022 г.
5. "Git Source Code Mirror". GitHub . Архивировано из оригинала 3 июня 2022 г. Получено 9 июня 2022 г.
6. "Лицензия LGPL Git на github.com". GitHub . 20 мая 2011 г. Архивировано из оригинала 11 апреля 2016 г. Получено 12 октября 2014 г.
7. "Лицензия GPL Git на github.com". GitHub . 18 января 2010 г. Архивировано из оригинала 11 апреля 2016 г. Получено 12 октября 2014 г.
8. "Tech Talk: Linus Torvalds on git (в 00:01:30)". 14 мая 2007 г. Архивировано из оригинала 20 декабря 2015 г. Получено 20 июля 2014 г. – через YouTube.
9. Чакон и Штрауб 2014, стр. 29–31.
10. Torvalds, Linus (7 апреля 2005 г.). "Re: Kernel SCM saga..." linux-kernel (список рассылки). Архивировано из оригинала 1 июля 2019 г. . Получено 3 февраля 2017 г. .«Поэтому я пишу несколько сценариев, чтобы попытаться отслеживать события гораздо быстрее».
11. Torvalds, Linus (10 июня 2007 г.). "Re: fatal: serious inflate inconsistency". git (список рассылки).
12. Линус Торвальдс (3 мая 2007 г.). Google tech talk: Линус Торвальдс на git. Событие происходит в 02:30. Архивировано из оригинала 28 мая 2007 г. Получено 16 мая 2007 г.
13. "Краткая история Git". Pro Git (2-е изд.). Apress. 2014. Архивировано из оригинала 25 декабря 2015 г. Получено 26 декабря 2015 г.
14. Чакон, Скотт (24 декабря 2014 г.). Pro Git (2-е изд.). Нью-Йорк, штат Нью-Йорк: Апресс . стр. 29–30. ISBN 978-1-4842-0077-3. Архивировано из оригинала 25 декабря 2015 года.
15. "Опрос разработчиков Stack Overflow 2022". Stack Overflow . Получено 4 августа 2022 г. .
16. Крилл, Пол (28 сентября 2016 г.). «Enterprise repo wars: GitHub vs. GitLab vs. Bitbucket». InfoWorld . Получено 2 февраля 2020 г. .
17. "github.com Competitive Analysis, Marketing Mix and Traffic". Alexa . Архивировано из оригинала 31 марта 2013 г. Получено 2 февраля 2020 г.
18. "sourceforge.net Competitive Analysis, Marketing Mix and Traffic". Alexa . Архивировано из оригинала 20 октября 2020 г. Получено 2 февраля 2020 г.
19. "bitbucket.org Competitive Analysis, Marketing Mix and Traffic". Alexa . Архивировано из оригинала 23 июня 2017 г. Получено 2 февраля 2020 г.
20. "gitlab.com Competitive Analysis, Marketing Mix and Traffic". Alexa . Архивировано из оригинала 30 ноября 2017 г. Получено 2 февраля 2020 г.
21. Браун, Зак (27 июля 2018 г.). «История происхождения Git». Linux Journal . Linux Journal. Архивировано из оригинала 13 апреля 2020 г. . Получено 28 мая 2020 г. .
22. «BitKeeper и Linux: конец пути?». Linux.com . 11 апреля 2005 г. Получено 18 мая 2023 г.
23. МакАллистер, Нил (2 мая 2005 г.). «Ошибка Линуса Торвальдса в BitKeeper». InfoWorld . Архивировано из оригинала 26 августа 2015 г. Получено 8 сентября 2015 г.
24. Torvalds, Linus (27 февраля 2007 г.). "Re: Интересный факт: Когда git стал самостоятельным хостингом?". git (список рассылки).
25. Торвальдс, Линус (6 апреля 2005 г.). «Сага о Kernel SCM». linux-kernel (список рассылки).
26. Торвальдс, Линус (17 апреля 2005 г.). «Первое настоящее слияние ядра git!». git (список рассылки).
27. Макколл, Мэтт (29 апреля 2005 г.). "Mercurial 0.4b против git patchbomb benchmark". git (список рассылки).
28. Торвальдс, Линус (17 июня 2005 г.). "Linux 2.6.12". git-commits-head (Список рассылки).
29. Торвальдс, Линус (27 июля 2005 г.). «Встречайте нового сопровождающего». git (список рассылки).
30. Хамано, Джунио К. (21 декабря 2005 г.). «Анонс: Git 1.0.0». git (список рассылки).
31. "GitFaq: Почему название 'Git'?". Git.or.cz. Архивировано из оригинала 23 июля 2012 г. Получено 14 июля 2012 г.
32. "После разногласий Торвальдс начинает работу над 'git'". PC World . 14 июля 2012 г. Архивировано из оригинала 1 февраля 2011 г. Торвальдс , похоже, понимал, что его решение отказаться от BitKeeper также будет спорным. Когда его спросили, почему он назвал новое программное обеспечение 'git', что на британском сленге означает 'гнилой человек', он ответил: 'Я эгоистичный ублюдок, поэтому я называю все свои проекты в честь себя. Сначала Linux, теперь git.'
33. "git(1) Manual Page". Архивировано из оригинала 21 июня 2012 г. Получено 21 июля 2012 г.
34. "Первоначальная редакция 'git', информационного менеджера из ада · git/git@e83c516". GitHub . Архивировано из оригинала 8 октября 2017 г. Получено 21 января 2016 г.
35. "Git – Distributed Workflows". Git . Архивировано из оригинала 22 октября 2014 . Получено 15 июня 2020 .
36. Gunjal, Siddhesh (19 июля 2019 г.). «Что такое инструмент контроля версий? Исследуйте Git и GitHub». Medium . Получено 25 октября 2020 г. .
37. Торвальдс, Линус (19 октября 2006 г.). "Re: Таблица сравнения VCS". git (Список рассылки).
38. Блог Jst на Mozillazine "bzr/hg/git performance". Архивировано из оригинала 29 мая 2010 года . Получено 12 февраля 2015 года .
39. Дрейер, Роланд (13 ноября 2006 г.). «О, какое это облегчение». Архивировано из оригинала 16 января 2009 г., заметив, что «git log» в 100 раз быстрее, чем «svn log», поскольку последний должен подключаться к удаленному серверу.
40. "Trust". Git Concepts . Git User's Manual. 18 октября 2006 г. Архивировано из оригинала 22 февраля 2017 г.
41. Торвальдс, Линус. "Re: Таблица сравнения VCS". git (Список рассылки) . Получено 10 апреля 2009 г., описывающий ориентированный на скрипты дизайн Git
42. iabervon (22 декабря 2005 г.). "Git rocks!". Архивировано из оригинала 14 сентября 2016 г., восхваляя возможности скриптования Git.
43. "Git – Git SCM Wiki". git.wiki.kernel.org . Получено 25 октября 2020 г. .
44. Чакон и Штрауб 2014.
45. "Git User's Manual". 10 марта 2020 г. Архивировано из оригинала 10 мая 2020 г.
46. Чакон и Штрауб 2014, стр. 499.
47. Чакон и Штрауб 2014, стр. 33–34.
48. "Git – Packfiles". Git .
49. Чакон и Штрауб 2014, стр. 568.
50. Торвальдс, Линус (10 апреля 2005 г.). "Re: more git updates." linux-kernel (список рассылки).
51. Хайбл, Бруно (11 февраля 2007 г.). «как ускорить 'git log'?». git (список рассылки).
52. Торвальдс, Линус (1 марта 2006 г.). "Re: нечистые переименования / отслеживание истории". git (список рассылки).
53. Хамано, Джунио К. (24 марта 2006 г.). "Re: Ошибки GITtifying GCC and Binutils". git (список рассылки).
54. Хамано, Джунио К. (23 марта 2006 г.). "Re: Ошибки GITtifying GCC and Binutils". git (список рассылки).
55. Торвальдс, Линус (28 ноября 2006 г.). "Re: git и bzr". git (список рассылки)., при использовании git-blameдля отображения кода, перемещенного между исходными файлами.
56. Торвальдс, Линус (18 июля 2007 г.). "git-merge(1)". Архивировано из оригинала 16 июля 2016 г.
57. Торвальдс, Линус (18 июля 2007 г.). "CrissCrossMerge". Архивировано из оригинала 13 января 2006 г.
58. Торвальдс, Линус (10 апреля 2005 г.). "Re: more git updates..." linux-kernel (список рассылки).
59. Торвальдс, Линус (23 марта 2006 г.). "Re: Ошибки GITtifying GCC and Binutils". git (список рассылки). Архивировано из оригинала 22 марта 2021 г. Получено 3 февраля 2017 г.
60. "Git – Объекты Git". Git .
61. Chacon & Straub 2014, стр. 81–83.
62. Чакон и Штрауб 2014, стр. 485–488.
63. Чакон и Штрауб 2014, стр. 488–490.
64. Чакон и Штрауб 2014, стр. 495–496.
65. Чакон и Штрауб 2014, стр. 497–501.
66. "Git – Ссылки Git". Git .
67. "Git Cheat Sheet" (PDF) . education.github.com . Получено 10 июня 2024 г. .
68. "Git Tutorial" (PDF) . web.stanford.edu . Получено 10 июня 2024 г. .
69. "Git Quick Intro" (PDF) . data-skills.github.io . Получено 10 июня 2024 г. .
70. Ба Тран, Эндрю. «Лучшие практики загрузки на GitHub» (PDF) . journalismcourses.org . Получено 10 июня 2024 г. .
71. "Формат файла конфигурации проекта". Gerrit Code Review . Архивировано из оригинала 3 декабря 2020 г. Получено 2 февраля 2020 г.
72. "downloads". Архивировано из оригинала 8 мая 2012 г. Получено 14 мая 2012 г.
73. "git package versions – Repology". Архивировано из оригинала 19 января 2022 г. Получено 30 ноября 2021 г.
74. "msysGit". GitHub . Архивировано из оригинала 10 октября 2016 . Получено 20 сентября 2016 .
75. "Git – Загрузка пакета". Git .(исходный код)
76. "JGit". Архивировано из оригинала 31 августа 2012 года . Получено 24 августа 2012 года .
77. "Git – go-git". Git . Получено 19 апреля 2019 .
78. "SQL-интерфейс для репозиториев Git, написанный на Go.", github.com , получено 19 апреля 2019 г.
79. "Keybase запускает зашифрованный git". keybase.io . Получено 19 апреля 2019 г. .
80. "Dulwich GitHub Repository README.md". GitHub . Архивировано из оригинала 29 апреля 2024 г. Получено 29 апреля 2024 г.
81. "libgit2". GitHub . Архивировано из оригинала 11 апреля 2016 года . Получено 24 августа 2012 года .
82. "rugged". GitHub . Архивировано из оригинала 24 июля 2013 г. Получено 24 августа 2012 г.
83. "pygit2". GitHub . Архивировано из оригинала 5 августа 2015 г. Получено 24 августа 2012 г.
84. "hlibgit2". Архивировано из оригинала 25 мая 2013 г. Получено 30 апреля 2013 г.
85. "js-git: реализация Git на JavaScript". GitHub . Архивировано из оригинала 7 августа 2013 г. Получено 13 августа 2013 г.
86. "Game of Trees". gameoftrees.org . Получено 10 марта 2024 г. .
87. Чакон и Штрауб 2014, стр. 138–139.
88. "Git – Git Daemon". Git . Получено 10 июля 2019 .
89. 4.4 Git на сервере — настройка сервера Архивировано 22 октября 2014 г. на Wayback Machine , Pro Git.
90. "1.4 Getting Started – Installation Git". Git. Архивировано из оригинала 2 ноября 2013 г. Получено 1 ноября 2013 г.
91. Чакон, Скотт; Штрауб, Бен (2014). «Git на сервере – Настройка сервера». Pro Git (2-е изд.). Apress. ISBN 978-1484200773.
92. Руководство пользователя Diffusion: Хостинг репозитория. Архивировано 20 сентября 2020 г. на Wayback Machine .
93. «Gitolite: Размещение репозиториев Git».
94. «Gogs: простой и самостоятельный сервис Git».
95. "Highlights from Git 2.26". Блог GitHub . 22 марта 2020 г. Архивировано из оригинала 22 марта 2021 г. Получено 25 ноября 2020 г. Возможно, вы помните, как в 2018 году Git представил новую версию своего протокола сетевой выборки. Теперь этот протокол используется по умолчанию в версии 2.26, поэтому давайте освежим в памяти, что это значит. Самая большая проблема со старым протоколом заключается в том, что сервер немедленно перечислял все ветви, теги и другие ссылки в репозитории, прежде чем клиент успевал что-либо отправить. Для некоторых репозиториев это могло означать отправку мегабайт дополнительных данных, когда клиент на самом деле хотел узнать только о главной ветке. Новый протокол начинается с запроса клиента и предоставляет клиенту возможность сообщить серверу, какие ссылки его интересуют. Извлечение одной ветви будет спрашивать только об этой ветви, в то время как большинство клонов будут спрашивать только о ветвях и тегах. Это может показаться всем, но серверные репозитории могут хранить другие ссылки (например, заголовок каждого запроса на извлечение, открытого в репозитории с момента его создания). Теперь извлечения из больших репозиториев ускоряются, особенно когда извлечение само по себе невелико, что делает стоимость первоначального объявления ссылок относительно более дорогой. И самое лучшее то, что вам не нужно ничего делать! Благодаря умному дизайну любой клиент, говорящий на новом протоколе, может бесперебойно работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственной причиной задержки между введением протокола и его назначением по умолчанию было желание дать ранним последователям возможность обнаружить любые ошибки.
96. "Git - git-gui Documentation". Git . Получено 1 июля 2024 г. .
97. "Git - GUI Clients". Git . Получено 1 июля 2024 г. .
98. "Результаты опроса сообщества Eclipse 2014 | Ян Скерретт". Ianskerrett.wordpress.com. 23 июня 2014 г. Архивировано из оригинала 25 июня 2014 г. Получено 23 июня 2014 г.
99. "Результаты опроса сообщества Eclipse 2012". eclipse.org. Архивировано из оригинала 11 апреля 2016 г.
100. "Сравнение репозиториев – Open Hub". Архивировано из оригинала 7 сентября 2014 г.
101. "Ежегодный опрос разработчиков Stack Overflow". Stack Exchange, Inc. Получено 9 января 2020 г. Ежегодный опрос разработчиков Stack Overflow — это крупнейший и наиболее полный опрос людей, которые пишут код по всему миру. Каждый год мы проводим опрос, охватывающий все: от любимых технологий разработчиков до их предпочтений в работе. В этом году мы уже девятый год публикуем результаты нашего ежегодного опроса разработчиков, и в начале этого года в 20-минутном опросе приняли участие около 90 000 разработчиков.
102. "Stack Overflow Developer Survey 2015". Stack Overflow. Архивировано из оригинала 4 мая 2019 года . Получено 29 мая 2019 года .
103. "Stack Overflow Developer Survey 2017". Stack Overflow. Архивировано из оригинала 29 мая 2019 года . Получено 29 мая 2019 года .
104. "Stack Overflow Developer Survey 2018". Stack Overflow. Архивировано из оригинала 30 мая 2019 года . Получено 29 мая 2019 года .
105. "Git (software) Jobs, Average Salary for Git Distributed Version Control System Skills". Itjobswatch.co.uk. Архивировано из оригинала 8 октября 2016 года . Получено 30 сентября 2016 года .
106. "Team Foundation Server Jobs, Average Salary for Microsoft Team Foundation Server (TFS) Skills". Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Получено 30 сентября 2016 года .
107. "Работа в Subversion, средняя зарплата для специалистов Apache Subversion (SVN)". Itjobswatch.co.uk. Архивировано из оригинала 25 октября 2016 г. Получено 30 сентября 2016 г.
108. "Mercurial Jobs, Average Salary for Mercurial Skills". Itjobswatch.co.uk. Архивировано из оригинала 23 сентября 2016 года . Получено 30 сентября 2016 года .
109. "VSS/SourceSafe Jobs, Average Salary for Microsoft Visual SourceSafe (VSS) Skills". Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Получено 30 сентября 2016 года .
110. «Переход Windows на Git почти завершён: 8500 коммитов и 1760 сборок каждый день». Ars Technica . 24 мая 2017 г. Архивировано из оригинала 24 мая 2017 г. Получено 24 мая 2017 г.
111. "git-init". Git . Архивировано из оригинала 15 марта 2022 года.
112. "Git – Branches in a Nutshell". Git . Архивировано из оригинала 20 декабря 2020 г. . Получено 15 июня 2020 г. Ветка "master" в Git не является специальной веткой. Она точно такая же, как и любая другая ветка. Единственная причина, по которой она есть почти в каждом репозитории, заключается в том, что команда git init создает ее по умолчанию, и большинство людей не утруждают себя ее изменением.
113. Чакон и Штрауб 2014, стр. 103–109.
114. github/renaming, GitHub, 4 декабря 2020 г. , получено 4 декабря 2020 г.
115. Имя ветки по умолчанию для новых репозиториев теперь является основным, GitLab, 22 июня 2021 г. , получено 22 июня 2021 г.
116. "Git Revert | Atlassian Git Tutorial". Atlassian . Откат имеет два важных преимущества перед сбросом. Во-первых, он не меняет историю проекта, что делает его "безопасной" операцией для коммитов, которые уже были опубликованы в общем репозитории.
117. "Рабочий процесс Gitflow | Учебное пособие по Atlassian Git". Atlassian . Получено 15 июня 2020 г. .
118. Чакон и Штрауб 2014, стр. 170–174.
119. "Forking Workflow | Atlassian Git Tutorial". Atlassian . Получено 15 июня 2020 г. .
120. "Git repository access control". Архивировано из оригинала 14 сентября 2016 года . Получено 6 сентября 2016 года .
121. Петтерсен, Тим (20 декабря 2014 г.). «Защита вашего сервера Git от CVE-2014-9390». Архивировано из оригинала 24 декабря 2014 г. Получено 22 декабря 2014 г.
122. Hamano, JC (18 декабря 2014 г.). "[Анонс] Git v2.2.1 (и обновления для старых версий обслуживания)". Группа новостей : gmane.linux.kernel. Архивировано из оригинала 19 декабря 2014 г. Получено 22 декабря 2014 г.
123. "CVE-2015-7545". 15 декабря 2015 г. Архивировано из оригинала 26 декабря 2015 г. Получено 26 декабря 2015 г.
124. "Git 2.6.1". GitHub . 29 сентября 2015 г. Архивировано из оригинала 11 апреля 2016 г. Получено 26 декабря 2015 г.
125. Blake Burkhart; et al. (5 октября 2015 г.). "Re: CVE Request: git". Архивировано из оригинала 27 декабря 2015 г. Получено 26 декабря 2015 г.
126. "хэш – Насколько безопасны подписанные теги git? Только такие же безопасные, как SHA-1 или как-то безопаснее?". Information Security Stack Exchange. 22 сентября 2014 г. Архивировано из оригинала 24 июня 2016 г.
127. «Почему Git использует криптографическую хэш-функцию?». Stack Overflow. 1 марта 2015 г. Архивировано из оригинала 1 июля 2016 г.
128. "Git – документация по хэш-функциям-переходам". Git .

Внешние ссылки

• Официальный сайт