Git - Git

Эта статья может быть слишком техническим для большинства читателей, чтобы понять. Пожалуйста помогите улучшить это к сделать понятным для неспециалистов, не снимая технических деталей. (Август 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

Git

Сеанс командной строки, показывающий создание репозитория, добавление файла и удаленную синхронизацию.
Оригинальный автор (ы)	Линус Торвальдс[1]
Разработчики)	Хунио Хамано и другие[2]
изначальный выпуск	7 апреля 2005 г.; 15 лет назад (2005-04-07)
Стабильный выпуск	2.29.2 / 29 октября 2020; 36 дней назад (2020-10-29)[3]
Репозиторий	мерзавец.kernel.org/паб/ scm/ git/ git.git/
Написано в	C, Ракушка, Perl, Tcl, Python[4]
Операционная система	POSIX (Linux, macOS, Солярис, AIX ), Windows
Доступно в	английский
Тип	Управление версиями
Лицензия	GPLv2,[5] LGPLv2.1,[6] и другие
Интернет сайт	git-scm.com

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

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

История

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

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

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

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

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

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

Именование

Торвальдс саркастически высмеял это имя мерзавец (что означает "неприятный человек" в Британский английский сленг): «Я эгоистичный ублюдок, и все свои проекты я называю в честь себя. Первый»Linux ', теперь' git '. "^[24][25] В страница руководства описывает Git как «тупой трекер контента».^[26] Прочитаемый файл исходного кода уточняет:^[27]

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

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

Релизы

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

Дизайн

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

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

Эта секция нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: "Гит"  – Новости  · газеты  · книги  · ученый  · JSTOR (Июнь 2020 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

Git поддерживает быстрое ветвление и слияние, а также включает специальные инструменты для визуализации и навигации по нелинейной истории разработки. В Git основное предположение состоит в том, что изменение будет объединяться чаще, чем написано, поскольку оно передается различным рецензентам. В Git ветки очень легкие: ветка - это только ссылка на одну фиксацию. С его родительскими коммитами можно построить полную структуру ветвей.^{[неправильный синтез? ]}

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

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

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

Репозитории можно публиковать через Протокол передачи гипертекста (HTTP), протокол передачи файлов (FTP) или протокол Git через простой сокет или Безопасная оболочка (SSH). Git также имеет эмуляцию сервера CVS, которая позволяет использовать существующие клиенты CVS и плагины IDE для доступа к репозиториям Git. Subversion репозитории можно использовать напрямую с git-svn.^[41]

Эффективное ведение крупных проектов

Торвальдс описал Git как очень быстрый и масштабируемый,^[42] и тесты производительности, сделанные Mozilla^[43] показал, что это был порядок величины быстрее, чем некоторые системы контроля версий; Получение истории версий из локально сохраненного репозитория может быть в сто раз быстрее, чем получение ее с удаленного сервера.^[44]

Криптографическая аутентификация истории

История Git хранится таким образом, что идентификатор конкретной версии ( совершить в терминах Git) зависит от полной истории разработки, предшествующей этой фиксации. После публикации невозможно изменить старые версии, не заметив этого. Структура похожа на Дерево Меркла, но с добавленными данными в узлах и листьях.^[45] (Mercurial и Монотонный тоже есть это свойство.)

Дизайн на основе инструментария

Git был разработан как набор программ, написанных на C и несколько сценариев оболочки, которые предоставляют оболочки для этих программ.^[46] Хотя большинство этих сценариев с тех пор было переписано на C для повышения скорости и переносимости, дизайн остался прежним, и компоненты легко связать вместе.^[47]

Подключаемые стратегии слияния

В рамках своего инструментария Git имеет четко определенную модель неполного слияния и несколько алгоритмов для его завершения, в результате чего пользователю сообщается, что он не может выполнить слияние автоматически и что требуется ручное редактирование.^[48]

Мусор накапливается до сбора

Прерывание операций или возврат изменений приведет к тому, что в базе данных останутся бесполезные висячие объекты. Как правило, это небольшая часть постоянно растущей истории разыскиваемых объектов. Git автоматически выполнит вывоз мусора когда в репозитории было создано достаточно свободных объектов. Сборку мусора можно вызвать явно, используя git gc.^[49]

Периодическая явная упаковка объектов

Git сохраняет каждый вновь созданный объект как отдельный файл. Несмотря на индивидуальное сжатие, это занимает много места и неэффективно. Это решается использованием пакеты которые хранят большое количество объектов дельта-сжатый между собой в один файл (или сетевой поток байтов), называемый packfile. Пакеты сжимаются с помощью эвристический что файлы с одинаковыми именами, вероятно, похожи, вне зависимости от их правильности. Для каждого файла пакета создается соответствующий индексный файл, в котором указывается смещение каждого объекта в файле пакета. Вновь созданные объекты (с недавно добавленной историей) по-прежнему хранятся как отдельные объекты, и для сохранения эффективности использования пространства требуется периодическая переупаковка. Процесс упаковки репозитория может быть очень затратным с точки зрения вычислений. Позволяя объектам существовать в репозитории в свободном, но быстро генерируемом формате, Git позволяет отложить дорогостоящую операцию упаковки на более позднее время, когда время имеет меньшее значение, например, конец рабочего дня. Git выполняет периодическую переупаковку автоматически, но ручная переупаковка также возможна с git gc команда. Для целостности данных как файл пакета, так и его индекс имеют SHA-1 контрольная сумма внутри, и имя файла пакета также содержит контрольную сумму SHA-1. Чтобы проверить целостность репозитория, запустите git fsck команда.^[50]

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

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

• Изучать историю изменений одного файла немного дороже, чем всего проекта.^[52] Чтобы получить историю изменений, влияющих на данный файл, Git должен просмотреть глобальную историю, а затем определить, повлияло ли каждое изменение на этот файл. Однако этот метод изучения истории позволяет Git с одинаковой эффективностью создавать единую историю, показывающую изменения в произвольном наборе файлов. Например, подкаталог исходного дерева плюс связанный с ним файл глобального заголовка - очень распространенный случай.
• Переименования обрабатываются неявно, а неявно. Обычная жалоба на CVS заключается в том, что он использует имя файла для идентификации его истории изменений, поэтому перемещение или переименование файла невозможно без прерывания его истории или переименования истории и, таким образом, делает историю неточной. Большинство систем управления версиями после CVS решают эту проблему, давая файлу уникальное долгоживущее имя (аналогично индекс номер), который переживает переименование. 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 object - это версия zlib, сжатая из различных других объектов для компактности и простоты транспортировки по сетевым протоколам.

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

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

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

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

Рекомендации

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

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

Реализации

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

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

Первые окна порт Git был в первую очередь платформой эмуляции 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. JGit используется в Геррит инструмент проверки кода, а в EGit - клиент Git для Затмение IDE.^[66]

go-git - это Открытый исходный код реализация Git написана на чистом Идти.^[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] Он имеет привязки для многих языков программирования, включая Рубин, Python и Haskell.^[72][73][74]

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

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

Git сервер

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

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

Открытый исходный код

• Размещение сервера Git с использованием Git Binary.^[79]
• Геррит, сервер git, настраиваемый для поддержки обзоров кода и предоставления доступа через ssh, интегрированный Apache MINA или OpenSSH, или интегрированный Причал веб сервер. Gerrit обеспечивает интеграцию с клиентскими сертификатами LDAP, Active Directory, OpenID, OAuth, Kerberos / GSSAPI, X509 https. В Gerrit 3.0 все конфигурации будут храниться в виде репозиториев git, для запуска базы данных не требуется. В ядре Gerrit реализована функция pull-request, но для нее отсутствует графический интерфейс.
• Фабрикатор, спин-офф от Facebook. Поскольку Facebook в основном использует Mercurial поддержка git не так заметна.^[80]
• RhodeCode Community Edition (CE) с поддержкой git, Mercurial и Subversion с Лицензия AGPLv3.
• Каллифея, поддерживая как git, так и Mercurial, разработанный в Python с Лицензия GPL.
• Внешние проекты вроде гитолита,^[81] которые предоставляют сценарии поверх программного обеспечения git для обеспечения детального контроля доступа.
• Есть несколько других решений FLOSS для самостоятельного размещения, в том числе Gogs.^[82] и Гитеа, форк Gogs, оба разработаны в Язык Go с Лицензия MIT.

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

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

Принятие

В Фонд Затмения сообщил в своем ежегодном опросе сообщества, что по состоянию на май 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]

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

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

Британский веб-сайт ИТ-вакансий itjobswatch.co.uk сообщает, что по состоянию на конец сентября 2016 года 29,27% вакансий постоянных разработчиков программного обеспечения в Великобритании ссылались на Git,^[95] опережает 12,17% для Microsoft Сервер Team Foundation,^[96] 10.60% для Subversion,^[97] 1,30% для Mercurial,^[98] и 0,48% для Visual SourceSafe.^[99]

Расширения

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

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

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

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

Конвенции

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

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

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

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

17 декабря 2014 г. была обнаружена уязвимость, влияющая на Windows и macOS версии клиента Git. Злоумышленник мог выполнить выполнение произвольного кода на целевом компьютере с установленным Git, создав вредоносное дерево (каталог) Git с именем .git (каталог в репозиториях Git, в котором хранятся все данные репозитория) в другом регистре (например, .GIT или .Git, необходим потому, что Git не допускает использование строчной версии .git создается вручную) с вредоносными файлами в .git / крючки подкаталог (папка с исполняемыми файлами, которую запускает 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]

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

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

Примечания

Рекомендации

внешняя ссылка

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