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

Git
Git-logo.svg
Git session.svg
Сеанс командной строки, показывающий создание репозитория, добавление файла и удаленную синхронизацию.
Автор (ы) оригиналаЛинус Торвальдс [1]
Разработчики)Хунио Хамано и другие [2]
изначальный выпуск7 апреля 2005 г . ; 15 лет назад ( 2005-04-07 )
Стабильный выпуск
2.30.2 [3] Отредактируйте это в Викиданных / 9 марта 2021 г . ; 4 дня назад ( 9 марта 2021 г. )
Репозиторий
Отредактируйте это в Викиданных
Написано вC , Shell , Perl , Tcl [4]
Операционная системаPOSIX ( Linux , macOS , Solaris , AIX ), Windows
Доступно ванглийский
ТипУправление версиями
ЛицензияGPLv2 , [5] LGPLv2.1 , [6] и другие
Интернет сайтgit-scm .com Отредактируйте это в Викиданных

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

Git был создан Линусом Торвальдсом в 2005 году для разработки ядра Linux , при этом другие разработчики ядра внесли свой вклад в его первоначальную разработку. [11] С 2005 года Джунио Хамано является основным сопровождающим. Как и в большинстве других распределенных систем контроля версий, и в отличие от большинства клиент-серверных систем, каждый каталог Git на каждом компьютере представляет собой полноценный репозиторий с полной историей и возможностями полного отслеживания версий, независимо от доступа к сети или центрального сервера. [12] Git - это бесплатное программное обеспечение с открытым исходным кодом, распространяемое подСтандартная общественная лицензия GNU версии 2 .

История [ править ]

Разработка Git началась в апреле 2005 года, после того как многие разработчики ядра Linux отказались от доступа к BitKeeper , проприетарной системе управления исходным кодом (SCM), которую они использовали для поддержки проекта с 2002 года. [13] [14] Авторские права. Ларри Маквой , владелец BitKeeper, отказался от бесплатного использования продукта после того, как заявил, что Эндрю Триджелл создал SourcePuller путем реверс-инжиниринга протоколов BitKeeper. [15] Тот же инцидент также стимулировал создание другой системы контроля версий, Mercurial .

Линус Торвальдс хотел распределенную систему, которую он мог бы использовать как BitKeeper, но ни одна из доступных бесплатных систем не соответствовала его потребностям. Торвальдс привел пример системы управления исходным кодом, которой требуется 30 секунд для применения патча и обновления всех связанных метаданных, и отметил, что это не будет масштабироваться в соответствии с потребностями разработки ядра Linux, где синхронизация с другими сопровождающими может потребовать 250 таких действий на однажды. В качестве критерия проектирования он указал, что установка исправлений должна занимать не более трех секунд, и добавил еще три пункта: [8]

  • Возьмите Concurrent Versions System (CVS) в качестве примера того, чего не следует делать; в случае сомнений примите прямо противоположное решение. [10]
  • Поддержка распределенного рабочего процесса , подобного BitKeeper . [10]
  • Включите очень надежные меры против случайного или злонамеренного коррупции. [9]

Эти критерии исключали каждую систему контроля версий, которая использовалась в то время, поэтому сразу после разработки ядра Linux 2.6.12-rc2 Торвальдс решил написать свою собственную. [10]

Разработка Git началась 3 апреля 2005 г. [16] Торвальдс объявил о проекте 6 апреля и на следующий день стал самостоятельным хостингом . [17] [16] Первое слияние нескольких филиалов произошло 18 апреля. [18] Торвальдс достиг поставленных целей; 29 апреля зарождающийся Git был протестирован, записывая исправления в дерево ядра Linux со скоростью 6,7 исправлений в секунду. [19] 16 июня Git выпустил ядро ​​2.6.12. [20]

26 июля 2005 года Торвальдс передал техническое обслуживание Хунио Хамано, крупному участнику проекта. [21] Хамано отвечал за выпуск 1.0 21 декабря 2005 года и остается основным сопровождающим проекта. [22]

Именование [ править ]

Торвальдс саркастически высмеял имя git (что на сленге британского английского означает «неприятный человек» ): «Я эгоистичный ублюдок, и все свои проекты я называю в честь себя. Сначала« Linux », теперь« git »». [23] [24] На странице руководства Git описывается как «тупой трекер контента». [25] Файл исходного кода, предназначенный для чтения, уточняет: [26]

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

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

Релизы [ править ]

Список выпусков Git: [27]

ВерсияИсходная дата выпускаПоследняя (патч) версияДата выхода (патча)Заметные изменения
Старая версия, больше не поддерживается: 0,992005-07-110.99.9n2005-12-15
Старая версия, больше не поддерживается: 1.02005-12-211.0.132006-01-27
Старая версия, больше не поддерживается: 1.12006-01-081.1.62006-01-30
Старая версия, больше не поддерживается: 1.22006-02-121.2.62006-04-08
Старая версия, больше не поддерживается: 1.32006-04-181.3.32006-05-16
Старая версия, больше не поддерживается: 1.42006-06-101.4.4.52008-07-16
Старая версия, больше не поддерживается: 1.52007-02-141.5.6.62008-12-17
Старая версия, больше не поддерживается: 1.62008-08-171.6.6.32010-12-15
Старая версия, больше не поддерживается: 1,72010-02-131.7.12.42012-10-17
Старая версия, больше не поддерживается: 1,82012-10-211.8.5.62014-12-17
Старая версия, больше не поддерживается: 1.92014-02-141.9.52014-12-17
Старая версия, больше не поддерживается: 2.02014-05-282.0.52014-12-17
Старая версия, больше не поддерживается: 2.12014-08-162.1.42014-12-17
Старая версия, больше не поддерживается: 2.22014-11-262.2.32015-09-04
Старая версия, больше не поддерживается: 2.32015-02-052.3.102015-09-29
Старая версия, больше не поддерживается: 2,42015-04-302.4.122017-05-05
Старая версия, больше не поддерживается: 2,52015-07-272.5.62017-05-05
Старая версия, больше не поддерживается: 2,62015-09-282.6.72017-05-05
Старая версия, больше не поддерживается: 2,72015-10-042.7.62017-07-30
Старая версия, больше не поддерживается: 2,82016-03-282.8.62017-07-30
Старая версия, больше не поддерживается: 2,92016-06-132.9.52017-07-30
Старая версия, больше не поддерживается: 2.102016-09-022.10.52017-09-22
Старая версия, больше не поддерживается: 2.112016-11-292.11.42017-09-22
Старая версия, больше не поддерживается: 2,122017-02-242.12.52017-09-22
Старая версия, больше не поддерживается: 2,132017-05-102.13.72018-05-22
Старая версия, больше не поддерживается: 2,142017-08-042.14.62019-12-07
Старая версия, больше не поддерживается: 2,152017-10-302.15.42019-12-07
Старая версия, больше не поддерживается: 2,162018-01-172.16.62019-12-07
Старая версия, больше не поддерживается: 2,172018-04-022.17.52020-04-20
Старая версия, больше не поддерживается: 2,182018-06-212.18.42020-04-20
Старая версия, больше не поддерживается: 2,192018-09-102.19.52020-04-20
Старая версия, больше не поддерживается: 2,202018-12-092.20.42020-04-20
Старая версия, больше не поддерживается: 2,212019-02-242.21.32020-04-20
Older version, yet still maintained: 2,222019-06-072.22.42020-04-20
Older version, yet still maintained: 2,232019-08-162.23.32020-04-20
Older version, yet still maintained: 2,242019-11-042.24.32020-04-20
Older version, yet still maintained: 2,252020-01-132.25.42020-04-20Упрощенное управление кассами [28]
Older version, yet still maintained: 2,262020-03-222.26.22020-04-20
  • Версия протокола 2 теперь используется по умолчанию
  • Некоторые новые трюки с конфигурацией
  • Обновления для git sparse-checkout

[29]

Older version, yet still maintained: 2,272020-06-012.27.02020-06-01
Older version, yet still maintained: 2,282020-07-272.28.02020-07-27
  • Представляем init.defaultBranch
  • Фильтр Блума измененного пути

[30]

Older version, yet still maintained: 2,292020-10-192.29.22020-10-29
  • Экспериментальная поддержка SHA-256
  • Отрицательные спецификации
  • Новые git shortlogприемы

[31]

Current stable version: 2.302020-12-272.30.12021-02-08
  • Userdiff для обновления PHP, Rust, обновления CSS
  • Скрипт завершения командной строки (в contrib /) узнал, что "git stash show" принимает параметры, которые принимает "git diff".

[32]

Легенда:
Старая версия
Старая версия, все еще поддерживается
Последняя версия
Последняя предварительная версия
Future release
Источники: [33] [34]

Дизайн

Дизайн Git был вдохновлен BitKeeper и Monotone . [35] [36] Git изначально разрабатывался как низкоуровневый движок системы управления версиями, поверх которого другие могли писать внешние интерфейсы, такие как Cogito или StGIT . [36] Основной проект Git с тех пор превратился в полную систему контроля версий, которую можно использовать напрямую. [37] Несмотря на сильное влияние BitKeeper, Торвальдс сознательно избегал традиционных подходов, что привело к уникальному дизайну. [38]

Характеристики [ править ]

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

Сильная поддержка нелинейного развития
Git поддерживает быстрое ветвление и слияние, а также включает специальные инструменты для визуализации и навигации по нелинейной истории разработки. В Git основное предположение состоит в том, что изменение будет объединяться чаще, чем написано, поскольку оно передается различным рецензентам. В Git ветви очень легкие: ветка - это только ссылка на одну фиксацию. С его родительскими коммитами можно построить полную структуру ветвей. [ неправильный синтез? ]
Распределенная разработка
Подобно Darcs , BitKeeper , Mercurial , Bazaar и Monotone , Git предоставляет каждому разработчику локальную копию полной истории разработки, а изменения копируются из одного такого репозитория в другой. Эти изменения импортируются как добавленные ветки разработки и могут быть объединены так же, как и локально разработанная ветка. [40]
Совместимость с существующими системами и протоколами
Репозитории могут публиковаться через протокол передачи гипертекста (HTTP), протокол передачи файлов (FTP) или протокол Git через простой сокет или Secure Shell (ssh). Git также имеет эмуляцию сервера CVS, которая позволяет использовать существующие клиенты CVS и плагины IDE для доступа к репозиториям Git. Репозитории Subversion можно использовать напрямую с git-svn. [41]
Эффективное ведение крупных проектов
Торвальдс описал Git как очень быстрый и масштабируемый [42], а тесты производительности, проведенные Mozilla [43], показали, что он был на порядок быстрее некоторых систем контроля версий; Получение истории версий из локально сохраненного репозитория может быть в сто раз быстрее, чем получение ее с удаленного сервера. [44]
Криптографическая аутентификация истории
История Git хранится таким образом, что идентификатор конкретной версии ( фиксация в терминах Git) зависит от полной истории разработки, ведущей к этой фиксации. После публикации невозможно изменить старые версии, не заметив этого. Структура похожа на дерево Меркла , но с добавленными данными в узлах и листьях. [45] ( Mercurial и Monotone также обладают этим свойством.)
Дизайн на основе инструментария
Git был разработан как набор программ, написанных на C, и нескольких сценариев оболочки, которые предоставляют оболочки для этих программ. [46] Хотя большинство этих скриптов с тех пор было переписано на C для повышения скорости и переносимости, дизайн остался прежним, и компоненты легко связать вместе. [47]
Подключаемые стратегии слияния
В составе своего инструментария Git имеет четко определенную модель неполного слияния и несколько алгоритмов для его завершения, в результате чего пользователю сообщается, что он не может выполнить слияние автоматически и что требуется ручное редактирование. [48]
Мусор накапливается, пока не будет собран
Прерывание операций или возврат изменений приведет к тому, что в базе данных останутся бесполезные висячие объекты. Как правило, это небольшая часть постоянно растущей истории разыскиваемых объектов. Git автоматически выполнит сборку мусора, когда в репозитории будет создано достаточно свободных объектов. Сборку мусора можно вызвать явно с помощью git gc. [49]
Периодическая явная упаковка объектов
Git хранит каждый вновь созданный объект как отдельный файл. Несмотря на индивидуальное сжатие, это занимает много места и неэффективно. Это решается использованием пакетов, которые хранят большое количество объектов, дельта-сжатых между собой, в одном файле (или сетевом потоке байтов), который называется пакетным файлом . Пакеты сжимаются с использованием эвристикичто файлы с одинаковыми именами, вероятно, похожи, вне зависимости от их правильности. Для каждого файла пакета создается соответствующий индексный файл, в котором указывается смещение каждого объекта в файле пакета. Вновь созданные объекты (с недавно добавленной историей) по-прежнему хранятся как отдельные объекты, и для сохранения эффективности использования пространства требуется периодическая переупаковка. Процесс упаковки репозитория может быть очень затратным с точки зрения вычислений. Позволяя объектам существовать в репозитории в свободном, но быстро генерируемом формате, Git позволяет отложить дорогостоящую операцию упаковки на более позднее время, когда время будет иметь меньшее значение, например, конец рабочего дня. Git выполняет периодическую переупаковку автоматически, но с помощью этой git gcкоманды также возможна переупаковка вручную . Для целостности данных как файл пакета, так и его индекс имеют SHA-1.контрольная сумма внутри, и имя файла пакета также содержит контрольную сумму SHA-1. Чтобы проверить целостность репозитория, выполните git fsckкоманду. [50]

Еще одним свойством Git является то, что он делает снимки деревьев каталогов файлов. Самые ранние системы отслеживания версий исходного кода, Система управления исходным кодом (SCCS) и Система контроля версий (RCS), работали с отдельными файлами и подчеркивали экономию места, которую можно получить за счет чередующихся дельт (SCCS) или дельта-кодирования (RCS). (в основном похожие) версии. Более поздние системы контроля версий поддерживали это понятие файла, имеющего идентификатор, в нескольких версиях проекта. Однако Торвальдс отверг эту концепцию. [51] Следовательно, Git не записывает явно отношения редакций файлов на любом уровне ниже дерева исходного кода.

Эти неявные отношения ревизии имеют некоторые важные последствия:

  • Изучать историю изменений одного файла немного дороже, чем всего проекта. [52] Чтобы получить историю изменений, влияющих на данный файл, Git должен просмотреть глобальную историю, а затем определить, повлияло ли каждое изменение на этот файл. Однако этот метод изучения истории позволяет Git с одинаковой эффективностью создавать единую историю, показывающую изменения в произвольном наборе файлов. Например, подкаталог исходного дерева плюс связанный файл глобального заголовка - очень распространенный случай.
  • Переименования обрабатываются неявно, а неявно. Распространенная жалоба на CVS заключается в том, что она использует имя файла для идентификации своей истории ревизий, поэтому перемещение или переименование файла невозможно без прерывания его истории или переименования истории, что делает историю неточной. Большинство систем контроля версий после CVS решают эту проблему, давая файлу уникальное долгоживущее имя (аналогичное номеру inode ), которое сохраняется при переименовании. Git не записывает такой идентификатор, и это считается преимуществом. [53] [54] Файлы исходного кода иногда разделяются, объединяются или просто переименовываются, [55]и запись этого как простого переименования заморозит неточное описание того, что произошло в (неизменной) истории. Git решает проблему, обнаруживая переименования при просмотре истории снимков, а не записывая ее при создании снимка. [56] (Вкратце, данный файл в ревизии N , файл с тем же именем в редакции N  - 1 не является по умолчанию предок Однако, когда нет , как название файла в редакции. N  - 1, Git поиск файла который существовал только в версии N  - 1 и очень похож на новый файл.) Однако он требует больше процессора-интенсивная работа каждый раз при просмотре истории, и доступно несколько вариантов настройки эвристики. Этот механизм не всегда работает; иногда файл, который переименовывается с изменениями в той же фиксации, читается как удаление старого файла и создание нового файла. Разработчики могут обойти это ограничение, зафиксировав переименование и изменения отдельно.

Git реализует несколько стратегий слияния; во время слияния можно выбрать нестандартную стратегию: [57]

  • решение : традиционный трехсторонний алгоритм слияния .
  • рекурсивный : это значение по умолчанию при извлечении или слиянии одной ветки и является вариантом алгоритма трехстороннего слияния.

    Когда существует несколько общих предков, которые могут использоваться для трехстороннего слияния, он создает объединенное дерево общих предков и использует его в качестве ссылочного дерева для трехстороннего слияния. Сообщается, что это приводит к меньшему количеству конфликтов слияния, не вызывая ошибок слияния, благодаря тестам, выполненным на предыдущих коммитах слияния, взятых из истории разработки ядра Linux 2.6. Кроме того, это может обнаруживать и обрабатывать слияния с переименованием.

    -  Линус Торвальдс [58]
  • осьминог : это значение по умолчанию при объединении более двух голов.

Структуры данных [ править ]

Примитивы Git по своей сути не являются системой управления исходным кодом . Торвальдс объясняет: [59]

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

Исходя из этого первоначального подхода к проектированию, Git разработал полный набор функций, ожидаемых от традиционного SCM [37], причем функции в основном создаются по мере необходимости, а затем дорабатываются и расширяются с течением времени.

Некоторые потоки данных и уровни хранения в системе контроля версий Git

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

Индекс служит точкой соединения между базой данных объектов и рабочим деревом.

База данных объектов содержит пять типов объектов: [60] [50]

  • Блоб ( большой двоичный объект ) является содержание в файле . У больших двоичных объектов нет надлежащего имени файла, отметок времени или других метаданных (внутреннее имя большого двоичного объекта является хешем его содержимого). В git каждый blob является версией файла, в нем хранятся данные файла.
  • Объект дерева эквивалентен каталогу. Он содержит список имен файлов, каждое из которых содержит некоторые биты типа и ссылку на большой двоичный объект или древовидный объект, который является этим файлом, символической ссылкой или содержимым каталога. Эти объекты представляют собой снимок исходного дерева. (В целом это дерево Меркла , а это означает, что достаточно одного хеша для корневого дерева, который фактически используется в коммитах для точного определения точного состояния целых древовидных структур любого количества подкаталогов и файлов.)
  • Объект фиксации связывает древовидные объекты вместе в историю. Он содержит имя объекта дерева (исходного каталога верхнего уровня), метку времени, сообщение журнала и имена нуля или более родительских объектов фиксации.
  • Объект тега - это контейнер, который содержит ссылку на другой объект и может содержать добавленные метаданные, относящиеся к другому объекту. Чаще всего он используется для хранения цифровой подписи объекта фиксации, соответствующего конкретному выпуску данных, отслеживаемых Git.
  • Объект packfile - это версия zlib, сжатая из различных других объектов для компактности и простоты транспортировки по сетевым протоколам.

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

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

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

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

Ссылки [ править ]

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

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

Реализации [ править ]

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

Git (основная реализация на C) в основном разработан для Linux , хотя он также поддерживает большинство основных операционных систем, включая BSD , Solaris , macOS и Windows . [63]

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

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

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

Реализация Dulwich для Git - это программный компонент на чистом Python для Python 2.7, 3.4 и 3.5 [70]

Реализация Git в libgit2 - это программная библиотека ANSI C без каких-либо других зависимостей, которая может быть построена на нескольких платформах, включая Windows, Linux, macOS и BSD. [71] Он имеет привязки для многих языков программирования, включая Ruby , Python и Haskell . [72] [73] [74]

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

Графические интерфейсы Git [ править ]

См. Также: Сравнение графических интерфейсов Git.

Сервер Git [ править ]

Снимок экрана интерфейса GitWeb , показывающий фиксацию различий

Поскольку Git - это распределенная система контроля версий, ее можно использовать как сервер прямо из коробки. Он поставляется со встроенной командой, git daemonзапускающей простой TCP-сервер, работающий по протоколу GIT. [76] Выделенные HTTP-серверы Git помогают (среди других функций), добавляя контроль доступа, отображая содержимое репозитория Git через веб-интерфейсы и управляя несколькими репозиториями. Уже существующие репозитории Git могут быть клонированы и предоставлены другим пользователям в качестве централизованного репо. К нему также можно получить доступ через удаленную оболочку, просто установив программное обеспечение Git и разрешив пользователю войти в систему. [77] Серверы Git обычно прослушивают TCP-порт 9418. [78]

Открытый исходный код [ править ]

  • Размещение сервера Git с использованием Git Binary. [79]
  • 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 не так заметна. [80]
  • RhodeCode Community Edition (CE), поддерживающий git, Mercurial и Subversion с лицензией AGPLv3 .
  • Kallithea , поддерживающая как git, так и Mercurial , разработана на Python с лицензией GPL .
  • Внешние проекты, такие как gitolite, [81], которые предоставляют сценарии поверх программного обеспечения git для обеспечения детального контроля доступа.
  • Существует несколько других решений FLOSS для самостоятельного размещения, включая Gogs [82] и Gitea , ответвление Gogs, оба разработанные на языке Go с лицензией MIT .

Сервер Git как услуга [ править ]

См. Также: Сравнение возможностей размещения исходного кода

Есть много предложений репозиториев Git в качестве услуги. Самыми популярными являются GitHub , SourceForge , Bitbucket и GitLab . [83] [84] [85] [86] [87]

Принятие [ править ]

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

Stack Overflow включил контроль версий в свой ежегодный опрос разработчиков [91] в 2015 г. (16 694 ответа), [92] 2017 г. (30 730 ответов) [93] и 2018 г. (74 298 ответов). [94] Git был подавляющим фаворитом разработчиков в этих опросах: в 2018 году он составил 87,2%.

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

Имя2015 г.2017 г.2018 г.
Git69,3%69,2%87,2%
Subversion36,9%9,1%16,1%
TFVC12,2%7,3%10,9%
Mercurial7,9%1,9%3,6%
CVS4,2%[я][я]
Волей-неволей3,3%[я][я]
VSS[я]0,6%[я]
ClearCase[я]0,4%[я]
Резервные копии zip-файлов[я]2,0%7,9%
Общий доступ к сети[я]1,7%7,9%
Другой5,8%3,0%[я]
Никто9,3%4,8%4,8%

Работы сайта UK IT itjobswatch.co.uk сообщает , что по состоянию на конец сентября 2016 года, 29,27% в Великобритании постоянного развития программного обеспечения вакансий процитировали Гит, [95] впереди 12,17% для Microsoft Team Foundation Server , [96] 10,60% для Subversion , [97] 1,30% для ртутного , [98] и 0,48% для Visual SourceSafe . [99]

Расширения [ править ]

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

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

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

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

Соглашения [ править ]

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

  • Мастер филиала создается по умолчанию с мерзавца инициализации и часто используется в качестве филиала , что другие изменения объединены в. [101] Соответственно, имя по умолчанию для удаленного восходящего потока - origin, а имя удаленной ветки по умолчанию - origin / master . Существуют альтернативы master в качестве имени ветки по умолчанию из-за его отрицательной коннотации. [102] С 2020 года новые репозитории GitHub называют ветку по умолчанию main . [103]
  • Толкаемые фиксаций не должны быть перезаписаны, а должны быть REVERT изд [104] (фиксация производится на вершине , которая переворачивает изменения в более ранней фиксации), если они не содержат конфиденциальную информацию , которая не должна остаться в истории. Это предотвращает недействительность общих новых коммитов, основанных на общих коммитах, поскольку фиксация, на которой они основаны, не существует на удаленном компьютере.
  • ГИТ-поток [105] Рабочий процесс и соглашения об именах часто принимаются , чтобы отличить особенность конкретных нестабильные истории (функция / *), нестабильные общие истории (разработка), производство готовых историй (мастер), а также аварийные пластыри для выпущенных продуктов (исправлений).
  • Запросы на извлечение не являются функцией git, но обычно предоставляются облачными службами git. Запрос на вытягивание - это запрос одного пользователя на слияние ветки своего ответвления репозитория с другим репозиторием, имеющим ту же историю (называемым удаленным восходящим потоком). [106] Основная функция запроса на вытягивание не отличается от функции администратора репозитория, извлекающего изменения с другого удаленного устройства (репозитория, являющегося источником запроса на вытягивание); однако сам запрос на перенос - это билет, управляемый хост-сервером, который запускает сценарии для выполнения этих действий, это не функция git SCM.

Безопасность [ править ]

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

17 декабря 2014 года был обнаружен эксплойт, влияющий на версии клиента Git для Windows и macOS . Злоумышленник может выполнить произвольный код на целевом компьютере с установленным Git, создав вредоносное дерево (каталог) Git с именем .git (каталог в репозиториях Git, в котором хранятся все данные репозитория) в другом случае (например, .GIT или .Git, необходим потому, что Git не позволяет создавать вручную версию .git со строчными буквами ) с вредоносными файлами в подкаталоге .git / hooks (папка с исполняемыми файлами, запускаемыми Git) в репозитории, созданном злоумышленником или в репозитории, который злоумышленник может изменить. Если пользователь Windows или Mac тянет(загружает) версию репозитория с вредоносным каталогом, затем переключается в этот каталог, каталог .git будет перезаписан (из-за нечувствительности к регистру файловых систем Windows и Mac), а вредоносные исполняемые файлы в .git / могут быть запущены хуки , что приводит к выполнению команд злоумышленника. Злоумышленник также может изменить файл конфигурации .git / config , который позволяет злоумышленнику создавать вредоносные псевдонимы Git (псевдонимы для команд Git или внешних команд) или изменять существующие псевдонимы для выполнения вредоносных команд при запуске. Уязвимость была исправлена ​​в версии 2.2.1 Git, выпущенной 17 декабря 2014 года, о чем было объявлено на следующий день. [108] [109]

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

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

См. Также [ править ]

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

Заметки [ править ]

  1. ^ a b c d e f g h i j k Не указан как вариант в этом обзоре

Ссылки [ править ]

  1. ^ «Первоначальная версия« мерзавца », информационного менеджера из ада» . GitHub . 8 апреля 2005 года архивации с оригинала на 16 ноября 2015 года . Проверено 20 декабря 2015 года .
  2. ^ "График фиксации" . GitHub . 8 июня 2016 года архивации с оригинала на 20 января 2016 года . Проверено 19 декабря 2015 .
  3. ^ https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.30.2.txt .
  4. ^ "Зеркало исходного кода Git" . Архивировано 8 февраля 2017 года . Проверено 1 января 2017 года .
  5. ^ "Лицензия Git GPL на github.com" . GitHub . 18 января 2010. Архивировано 11 апреля 2016 года . Проверено 12 октября 2014 года .
  6. ^ "Лицензия Git LGPL на github.com" . GitHub . 20 мая 2011. Архивировано 11 апреля 2016 года . Проверено 12 октября 2014 года .
  7. ^ «Tech Talk: Линус Торвальдс на git (в 00:01:30)» . Архивировано 20 декабря 2015 года . Проверено 20 июля 2014 года - через YouTube.
  8. ^ a b Торвальдс, Линус (7 апреля 2005 г.). «Re: Сага о ядре SCM». linux-kernel (список рассылки). «Так что я пишу несколько сценариев, чтобы попытаться отслеживать вещи намного быстрее».
  9. ^ a b Торвальдс, Линус (10 июня 2007 г.). «Re: фатальный: серьезное несоответствие накачки» . git (список рассылки).
  10. ^ a b c d Линус Торвальдс (3 мая 2007 г.). Технический разговор Google: Линус Торвальдс на git . Событие происходит в 02:30. Архивировано 28 мая 2007 года . Проверено 16 мая 2007 года .
  11. ^ «Краткая история Git» . Pro Git (2-е изд.). Апресс. 2014. Архивировано 25 декабря 2015 года . Проверено 26 декабря 2015 года .
  12. Рианна Чакон, Скотт (24 декабря 2014 г.). Pro Git (2-е изд.). Нью-Йорк, Нью-Йорк: Апресс . С. 29–30. ISBN 978-1-4842-0077-3. Архивировано 25 декабря 2015 года.
  13. ↑ Brown, Zack (27 июля 2018 г.). "Ошибка BitKeeper Линуса Торвальдса" . InfoWorld . LinuxJournal. Архивировано 13 апреля 2020 года . Проверено 28 мая 2020 .
  14. ^ BitKeeper и Linux: конец пути? | linux.com Архивировано 8 июня 2017 года на Wayback Machine
  15. Перейти ↑ McAllister, Neil (2 мая 2005 г.). "Ошибка BitKeeper Линуса Торвальдса" . InfoWorld . Архивировано 26 августа 2015 года . Проверено 8 сентября 2015 года .
  16. ^ a b Торвальдс, Линус (27 февраля 2007 г.). "Re: Общая информация: когда git self-host?" . git (список рассылки).
  17. ↑ Торвальдс, Линус (6 апреля 2005 г.). «Сага о ядре SCM». linux-kernel (список рассылки).
  18. ↑ Торвальдс, Линус (17 апреля 2005 г.). «Первое в истории слияние git с настоящим ядром!» . git (список рассылки).
  19. ^ Mackall, Matt (29 апреля 2005). «Тест Mercurial 0.4b против git patchbomb» . git (список рассылки).
  20. ↑ Торвальдс, Линус (17 июня 2005 г.). «Linux 2.6.12» . git-commits-head (список рассылки).
  21. ↑ Торвальдс, Линус (27 июля 2005 г.). «Встречайте нового сопровождающего ...» git (Список рассылки).
  22. ^ Hamano, Junio С. (21 декабря 2005). «Анонс: Git 1.0.0» . git (список рассылки).
  23. ^ "GitFaq: Почему имя 'Git'?" . Git.or.cz. Архивировано 23 июля 2012 года . Проверено 14 июля 2012 года .
  24. ^ «После разногласий Торвальдс начинает работу над« мерзавцем » » . Мир ПК . 14 июля 2012 г. Архивировано 1 февраля 2011 г. Торвальдс, похоже, знал, что его решение отказаться от BitKeeper также будет спорным. Когда его спросили, почему он назвал новое программное обеспечение «мерзавцем», что на британском сленге означает «гнилой человек», он ответил. «Я эгоистичный ублюдок, поэтому все свои проекты я называю в честь себя. Сначала Linux, теперь git.
  25. ^ "git (1) Страница руководства" . Архивировано 21 июня 2012 года . Проверено 21 июля 2012 года .
  26. ^ "Первоначальная версия 'git', информационного менеджера из ада · git / git @ e83c516" . GitHub . Архивировано 8 октября 2017 года . Проверено 21 января +2016 .
  27. ^ https://github.com/git/git/releases
  28. ^ «Основные моменты из Git 2.25» . Блог GitHub . 13 января 2020 . Проверено 27 ноября 2020 года . Редкая проверка - это не что иное, как список шаблонов путей к файлам, которые Git должен попытаться заполнить в вашей рабочей копии при проверке содержимого вашего репозитория. По сути, он работает как .gitignore, за исключением того, что действует на содержимое вашей рабочей копии, а не на ваш индекс.
  29. ^ «Основные моменты из Git 2.26» . Блог GitHub . 22 марта 2020 . Проверено 25 ноября 2020 года .Возможно, вы помните, когда Git представил новую версию своего протокола сетевой выборки еще в 2018 году. Этот протокол теперь используется по умолчанию в версии 2.26, поэтому давайте освежимся, что это означает. Самая большая проблема со старым протоколом заключается в том, что сервер немедленно перечисляет все ветки, теги и другие ссылки в репозитории, прежде чем у клиента будет возможность что-либо отправить. Для некоторых репозиториев это может означать отправку мегабайт дополнительных данных, когда клиент действительно хотел знать только об основной ветке. Новый протокол начинается с клиентского запроса и предоставляет клиенту способ сообщить серверу, какие ссылки ему интересны. При выборке одной ветки будет запрашиваться только эта ветка, в то время как большинство клонов будут спрашивать только о ветвях и тегах. Это может показаться всем,но серверные репозитории могут хранить другие ссылки (например, заголовок каждого запроса на вытягивание, открытого в репозитории с момента его создания). Теперь загрузка из больших репозиториев улучшается по скорости, особенно когда выборка сама по себе небольшая, что делает стоимость первоначальной справочной рекламы относительно дороже. И что самое приятное, вам не нужно ничего делать! Благодаря продуманному дизайну любой клиент, использующий новый протокол, может без проблем работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним последователям обнаружить любые ошибки.особенно, когда выборка сама по себе небольшая, что делает стоимость первоначальной справочной рекламы относительно дороже. И что самое приятное, вам не нужно ничего делать! Благодаря продуманному дизайну любой клиент, использующий новый протокол, может без проблем работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним последователям обнаружить любые ошибки.особенно, когда выборка сама по себе небольшая, что делает стоимость первоначальной справочной рекламы относительно дороже. И что самое приятное, вам не нужно ничего делать! Благодаря продуманному дизайну любой клиент, использующий новый протокол, может без проблем работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним последователям обнаружить любые ошибки.возврат к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним последователям обнаружить любые ошибки.возврат к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним последователям обнаружить любые ошибки.
  30. ^ «Основные моменты из Git 2.28» . Блог GitHub . 27 июля 2020 . Проверено 25 ноября 2020 года .
  31. ^ «Основные моменты из Git 2.29» . Блог GitHub . 19 октября 2020 . Проверено 25 ноября 2020 года .
  32. ^ «Примечания к выпуску Git 2.30» . Загрузки Git . 27 декабря 2020 . Проверено 27 декабря 2020 года .
  33. ^ "git / git" . GitHub .
  34. ^ Hamano, Junio (21 ноября 2007). «Как поддерживать Git» . GitHub . Дата обращения 1 августа 2020 .
  35. ↑ Торвальдс, Линус (5 мая 2006 г.). «Re: [ОБЪЯВЛЕНИЕ] Git wiki» . linux-kernel (список рассылки). "Немного истории" о предшественниках Git
  36. ^ a b Торвальдс, Линус (8 апреля 2005 г.). "Re: Сага о ядре SCM" . linux-kernel (список рассылки) . Проверено 20 февраля 2008 года .
  37. ^ a b Торвальдс, Линус (23 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки).
  38. ↑ Торвальдс, Линус (20 октября 2006 г.). "Re: Сравнительная таблица VCS" . git (список рассылки). Обсуждение Git и BitKeeper.
  39. ^ «Git - Краткая история Git» . git-scm.com . Проверено 15 июня 2020 .
  40. ^ «Git - Распределенные рабочие процессы» . git-scm.com . Проверено 15 июня 2020 .
  41. ^ Gunjal, Siddhesh (19 июля 2019). «Что такое средство контроля версий? Изучите Git и GitHub» . Средний . Проверено 25 октября 2020 года .
  42. ↑ Торвальдс, Линус (19 октября 2006 г.). "Re: Сравнительная таблица VCS" . git (список рассылки).
  43. ^ Блог Jst на Mozillazine "bzr / hg / git performance" . Архивировано из оригинального 29 мая 2010 года . Проверено 12 февраля 2015 года .
  44. ^ Дрейер, Roland (13 ноября 2006). «О, какое это облегчение» . Архивировано 16 января 2009 года., учитывая, что «git log» в 100 раз быстрее, чем «svn log», потому что последний должен связываться с удаленным сервером.
  45. ^ "Доверие" . Концепции Git . Руководство пользователя Git. 18 октября 2006 г. Архивировано 22 февраля 2017 г.
  46. ^ Торвальдс, Линус. "Re: Сравнительная таблица VCS" . git (список рассылки) . Проверено 10 апреля 2009 года ., описывающий дизайн Git, ориентированный на сценарии
  47. ^ iabervon (22 декабря 2005 г.). "Git Rock!" . Архивировано 14 сентября 2016 года., хвалят скриптовые возможности Git.
  48. ^ "Git - Git SCM Wiki" . git.wiki.kernel.org . Проверено 25 октября 2020 года .
  49. ^ "Руководство пользователя Git" . 10 марта 2020 г. Архивировано 10 мая 2020 г.
  50. ^ a b "Git - Packfiles" . git-scm.com .
  51. ↑ Торвальдс, Линус (10 апреля 2005 г.). «Re: больше обновлений git». linux-kernel (список рассылки).
  52. ^ Haible, Бруно (11 февраля 2007). "как ускорить" git log "?" . git (список рассылки).
  53. ↑ Торвальдс, Линус (1 марта 2006 г.). «Re: нечистые переименования / отслеживание истории» . git (список рассылки).
  54. ^ Hamano, Junio С. (24 марта 2006). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки).
  55. ^ Hamano, Junio С. (23 марта 2006). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки).
  56. ↑ Торвальдс, Линус (28 ноября 2006 г.). «Re: git и bzr» . git (список рассылки)., при использовании git-blameдля отображения кода, перемещаемого между исходными файлами.
  57. ↑ Торвальдс, Линус (18 июля 2007 г.). "git-merge (1)" . Архивировано 16 июля 2016 года.
  58. ↑ Торвальдс, Линус (18 июля 2007 г.). «CrissCrossMerge» . Архивировано из оригинала 13 января 2006 года.
  59. ↑ Торвальдс, Линус (10 апреля 2005 г.). "Re: больше обновлений git ..." linux-kernel (Список рассылки).
  60. ^ «Git - объекты Git» . git-scm.com .
  61. ^ «Git - Ссылки Git» . git-scm.com .
  62. ^ «Формат файла конфигурации проекта» . Обзор кода Gerrit . Дата обращения 2 февраля 2020 .
  63. ^ "загрузки" . Архивировано 8 мая 2012 года . Проверено 14 мая 2012 года .
  64. ^ "msysGit" . Архивировано 10 октября 2016 года . Проверено 20 сентября 2016 года .
  65. ^ "Git - Пакет загрузки" . git-scm.com .( исходный код )
  66. ^ "JGit" . Архивировано 31 августа 2012 года . Проверено 24 августа 2012 года .
  67. ^ "Git - go-git" . git-scm.com . Проверено 19 апреля 2019 .
  68. ^ «Интерфейс SQL для репозиториев Git, написанный на Go». , github.com , получено 19 апреля 2019 г.
  69. ^ "Keybase запускает зашифрованный git" . keybase.io . Проверено 19 апреля 2019 .
  70. ^ "Далвич" . Архивировано 29 мая 2012 года . Проверено 27 августа 2012 года .
  71. ^ "libgit2" . Архивировано 11 апреля 2016 года . Проверено 24 августа 2012 года .
  72. ^ "прочный" . Архивировано 24 июля 2013 года . Проверено 24 августа 2012 года .
  73. ^ "pygit2" . Архивировано 5 августа 2015 года . Проверено 24 августа 2012 года .
  74. ^ "hlibgit2" . Архивировано 25 мая 2013 года . Проверено 30 апреля 2013 года .
  75. ^ "js-git: реализация Git на JavaScript" . Архивировано 7 августа 2013 года . Проверено 13 августа 2013 года .
  76. ^ "Git - Git Daemon" . git-scm.com . Проверено 10 июля 2019 .
  77. ^ 4.4 Git на сервере - Настройка сервера Архивировано 22 октября 2014 г. на Wayback Machine , Pro Git.
  78. ^ «1.4 Начало работы - Установка Git» . git-scm.com. Архивировано 2 ноября 2013 года . Проверено 1 ноября 2013 года .
  79. ^ Чакон, Скотт; Штрауб, Бен (2014). «Git на сервере - Настройка сервера» . Pro Git (2-е изд.). Апресс. ISBN 978-1484200773.
  80. ^ Руководство пользователя Diffusion: Хостинг репозитория .
  81. ^ "Gitolite: размещение репозиториев Git" .
  82. ^ «Gogs: безболезненная автономная служба Git» .
  83. ^ Криль, Пол (28 сентября 2016). «Войны корпоративного репо: GitHub против GitLab против Bitbucket» . InfoWorld . Дата обращения 2 февраля 2020 .
  84. ^ "github.com Анализ конкуренции, маркетинг-микс и трафик" . Алекса . Дата обращения 2 февраля 2020 .
  85. ^ "Sourceforge.net Анализ конкуренции, маркетинг-микс и трафик" . Алекса . Дата обращения 2 февраля 2020 .
  86. ^ "bitbucket.org Конкурентный анализ, маркетинг и трафик" . Алекса . Дата обращения 2 февраля 2020 .
  87. ^ "gitlab.com Анализ конкуренции, маркетинг-микс и трафик" . Алекса . Дата обращения 2 февраля 2020 .
  88. ^ "Результаты опроса сообщества Eclipse 2014 | Ян Скерретт" . Ianskerrett.wordpress.com. 23 июня 2014 года. Архивировано 25 июня 2014 года . Проверено 23 июня 2014 года .
  89. ^ «Результаты опроса сообщества Eclipse 2012» . eclipse.org. Архивировано 11 апреля 2016 года.
  90. ^ «Сравнить репозитории - Open Hub» . Архивировано 7 сентября 2014 года.
  91. ^ «Ежегодный опрос разработчиков Stack Overflow» . Стек биржа, Inc . Дата обращения 9 января 2020 . Ежегодный опрос разработчиков Stack Overflow - это самый крупный и всесторонний опрос людей, которые пишут код по всему миру. Каждый год мы проводим опрос, охватывающий все, от любимых технологий разработчиков до их профессиональных предпочтений. В этом году мы уже девятый год публикуем результаты нашего ежегодного опроса разработчиков, и почти 90 000 разработчиков приняли участие в 20-минутном опросе ранее в этом году.
  92. ^ «Опрос разработчиков Stack Overflow 2015» . Переполнение стека. Архивировано из оригинала 4 мая 2019 года . Проверено 29 мая 2019 .
  93. ^ «Опрос разработчиков Stack Overflow 2017» . Переполнение стека. Архивировано из оригинального 29 мая 2019 года . Проверено 29 мая 2019 .
  94. ^ «Опрос разработчиков Stack Overflow 2018» . Переполнение стека. Архивировано из оригинального 30 мая 2019 года . Проверено 29 мая 2019 .
  95. ^ «Работа в Git (программное обеспечение), средняя заработная плата за навыки работы с системой управления распределенными версиями Git» . Itjobswatch.co.uk. Архивировано 8 октября 2016 года . Проверено 30 сентября 2016 года .
  96. ^ «Работа в Team Foundation Server, средняя зарплата для навыков Microsoft Team Foundation Server (TFS)» . Itjobswatch.co.uk. Архивировано 29 октября 2016 года . Проверено 30 сентября 2016 года .
  97. ^ «Работа в Subversion, средняя зарплата для навыков Apache Subversion (SVN)» . Itjobswatch.co.uk. Архивировано 25 октября 2016 года . Проверено 30 сентября 2016 года .
  98. ^ «Переменчивые рабочие места, средняя зарплата для переменчивых навыков» . Itjobswatch.co.uk. Архивировано 23 сентября 2016 года . Проверено 30 сентября 2016 года .
  99. ^ «Вакансии VSS / SourceSafe, средняя зарплата для навыков Microsoft Visual SourceSafe (VSS)» . Itjobswatch.co.uk. Архивировано 29 октября 2016 года . Проверено 30 сентября 2016 года .
  100. ^ «Переход Windows на Git почти завершен: 8 500 коммитов и 1760 сборок каждый день» . Ars Technica . Архивировано 24 мая 2017 года . Дата обращения 24 мая 2017 .
  101. ^ «Git - ветви в двух словах» . git-scm.com . Проверено 15 июня 2020 . Ветвь «master» в Git не является особой веткой. Это точно так же, как и любая другая ветка. Единственная причина, по которой он есть почти в каждом репозитории, заключается в том, что команда git init создает его по умолчанию, и большинство людей не беспокоятся о его изменении.
  102. ^ «Относительно Git и именования веток» . Сохранение свободы программного обеспечения . Дата обращения 4 декабря 2020 .
  103. ^ github / renaming , GitHub, 4 декабря 2020 г. , получено 4 декабря 2020 г.
  104. ^ "Git Revert | Atlassian Git Tutorial" . Atlassian . Возврат имеет два важных преимущества перед сбросом. Во-первых, он не меняет историю проекта, что делает его «безопасной» операцией для коммитов, которые уже были опубликованы в общем репозитории.
  105. ^ «Gitflow Workflow | Atlassian Git Tutorial» . Atlassian . Проверено 15 июня 2020 .
  106. ^ «Форкинг рабочего процесса | Atlassian Git Tutorial» . Atlassian . Проверено 15 июня 2020 .
  107. ^ "Архивная копия" . Архивировано 14 сентября 2016 года . Проверено 6 сентября +2016 .CS1 maint: archived copy as title (link)
  108. ^ Pettersen, Тим (20 декабря 2014). «Защита вашего сервера Git от CVE-2014-9390» . Архивировано 24 декабря 2014 года . Проверено 22 декабря 2014 .
  109. ^ Hamano, JC (18 декабря 2014). «[Анонс] Git v2.2.1 (и обновления старых версий обслуживания)» . Группа новостей :  gmane.linux.kernel . Архивировано из оригинального 19 декабря 2014 года . Проверено 22 декабря 2014 .
  110. ^ "CVE-2015-7545" . 15 декабря 2015. Архивировано 26 декабря 2015 года . Проверено 26 декабря 2015 года .
  111. ^ "Git 2.6.1" . 29 сентября 2015 года. Архивировано 11 апреля 2016 года . Проверено 26 декабря 2015 года .
  112. ^ a b c Блейк Беркхарт; и другие. (5 октября 2015 г.). "Re: Запрос CVE: git" . Архивировано 27 декабря 2015 года . Проверено 26 декабря 2015 года .
  113. ^ "hash - Насколько безопасны подписанные теги git? Только так же безопасно, как SHA-1 или как-то более безопасно?" . Обмен стеками информационной безопасности. 22 сентября 2014 года. Архивировано 24 июня 2016 года.
  114. ^ "Почему Git использует криптографическую хеш-функцию?" . Переполнение стека. 1 марта 2015. Архивировано 1 июля 2016 года.
  115. ^ "Git - документация по переходу хэш-функции" . git-scm.com .

Внешние ссылки [ править ]

  • Официальный веб-сайт
  • Git в Open Hub