Git

Для других целей см. Git (устранение неоднозначности).

Не путать с GitHub.

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

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

История

ГИТ разработка началась в апреле 2005 года, после многих разработчиков ядра Linux дала доступ к Системы bitkeeper, фирменная источник-контроля и управления (СКМ) системы, которые они использовали, чтобы сохранить проект с 2002 года. правообладатель системы bitkeeper, Ларри Маквой, сняла свободное использование продукта после утверждая, что Андрей Tridgell создали SourcePuller путем обратного проектирования самой системы bitkeeper протоколы. Тот же инцидент также подтолкнул к созданию другой системы контроля версий, Mercurial.

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

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

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

Развитие ГИТ начался 3 апреля 2005 года. Торвальдс анонсировал проект на 6 апреля и стал самостоятелен уже на следующий день. первое слияние нескольких веток состоялось 18 апреля. Торвальдс добиться его выполнения целей; 29 апреля, зарождающейся в Git был установлен записи патчи для ядра Linux дерева по курсу 6.7 заплат в секунду. 16 июня Git управлял выпуском ядра 2.6.12.

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

Именование

Торвальдс саркастически пошутил по поводу имени git (что на британском английском сленге означает "неприятный человек"): "Я эгоистичный ублюдок, и я называю все свои проекты в честь себя. Сначала"Linux", теперь "git"". Страница руководства описывает Git как "глупый трекер контента". Файл read-me исходного кода уточняет далее:

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

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

Дизайн

В Git дизайн был вдохновлен системы bitkeeper и монотонно. git был первоначально разработан как низкоуровневые версии-система управления двигателем, на вершине которой другие могли бы написать интерфейсов, таких как Когито или StGIT. основные команды git проект стал полной версии-управляющей системой, которая может использоваться напрямую. в то время под сильным влиянием системы bitkeeper, Торвальдс сознательно избегал традиционных подходов, ведущих к уникальной конструкции.

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

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

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

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

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

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

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

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

Эффективное управление крупными проектами

• Торвальдс описал Git как очень быстрый и масштабируемый, а тесты производительности, проведенные Mozilla, показали, что он был на порядок быстрее, чем некоторые системы управления версиями; извлечение истории версий из локального хранилища может быть в сто раз быстрее, чем извлечение ее с удаленного сервера.

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

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

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

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

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

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

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

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

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

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

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

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

• Переименования обрабатываются неявно, а не явно. Распространенная жалоба CVS заключается в том, что он использует имя файла для определения истории его изменений, поэтому перемещение или переименование файла невозможно без прерывания его истории или переименования истории и, таким образом, внесения в историю неточностей. Большинство систем контроля версий после CVS решают эту проблему, присваивая файлу уникальное долговечное имя (аналогичное номеру индекса), которое сохраняется после переименования. Git не записывает такой идентификатор, и это считается преимуществом. Файлы исходного кода иногда разделяются, объединяются или просто переименовываются, и запись этого в виде простого переименования приведет к неточному описанию того, что произошло в (неизменяемой) истории. Git решает проблему, обнаруживая переименования при просмотре истории моментальных снимков, а не записывая их при создании моментального снимка. (Кратко, учитывая файл в редакции N, файл с тем же именем в редакции N − 1 является его предком по умолчанию. Однако, если в редакции N-1 нет файла с аналогичным именем, Git ищет файл, который существовал только в редакцииN − 1 и очень похож на новый файл.) Однако это требует более интенсивной работы с процессором каждый раз, когда просматривается история, и доступно несколько вариантов настройки эвристики. Этот механизм не всегда работает; иногда файл, переименованный с изменениями в одной и той же фиксации, считывается как удаление старого файла и создание нового файла. Разработчики могут обойти это ограничение, зафиксировав переименование и изменения отдельно.

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

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

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

— Линус Торвальдс

• осьминог: Это значение по умолчанию при объединении более двух голов.

Структуры данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализации

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

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

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

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

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

Реализация Git в Далвиче является чистым программным компонентом Python для Python 2.7, 3.4 и 3.5.

Реализация libgit2 ЖКТ-это библиотека программного обеспечения с ANSI C без других зависимостей, которые могут быть построены на различных платформах, включая Windows, для Linux, для macOS и BSD. он имеет привязки для многих языков программирования, в том числе в Ruby, Python и Хаскелл.

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

Git GUIs

Основная статья: Сравнение графических интерфейсов Git

Сервер Git

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

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

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

• Размещение сервера Git с использованием двоичного файла Git.
• Gerrit, сервер git, настраиваемый для поддержки проверки кода и предоставления доступа через ssh, интегрированный Apache MINA или OpenSSH или интегрированный веб-сервер Jetty. Gerrit обеспечивает интеграцию с сертификатами LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https-клиентов. С Gerrit 3.0 все конфигурации будут храниться в виде репозиториев git, для запуска базы данных не требуется. У Gerrit есть функция запроса на вытягивание, реализованная в его ядре, но для нее отсутствует графический интерфейс.
• Phabricator, побочный продукт Facebook. Поскольку Facebook в основном использует Mercurial, поддержка git не так заметна[84].
• Издание сообщества RhodeCode (CE), поддерживающее git, Mercurial и Subversion с лицензией AGPLv3.
• Kallithea, поддерживающая как git, так и Mercurial, разработана на Python с лицензией GPL.
• Внешние проекты, такие как gitolite[85], которые предоставляют сценарии поверх программного обеспечения git для обеспечения детального контроля доступа.
• Существует несколько других решений FLOSS для самостоятельного размещения, в том числе Gogs и Gitea, развилка Gogs, оба разработаны на языке Go с лицензией MIT.

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

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

Существует множество предложений репозиториев Git в качестве сервиса. Наиболее популярными являются GitHub, SourceForge, Bitbucket и GitLab.

Принятие

В затмение фонда сообщила в своем ежегодном общий опрос, что по состоянию на май 2014, ГИТ является в настоящее время наиболее широко используемым исходным кодом инструмент управления, с 42.9% профессиональных разработчиков программного обеспечения, сообщивших, что они используют Git в качестве их основного источника-системы управления по сравнению с 36.3% в 2013 году, 32% в 2012 году; или для Git ответы пользование на GitHub: 33.3% в 2014 году-30,3%, в 2013, 27,6% в 2012 году и 12,8% в 2011г. с открытым исходным кодом каталог Черная утка открыть хаб сообщает похожие востребованности среди проектов с открытым кодом.

Переполнение стека в ключил управление версиями в своих ежегодных разработчик опроса в 2015 году (16,694 ответов), 2017 (30,730 ответов)[97] и 2018 (74,298 ответов).[98] git была несравненным фаворитом отвечать застройщики в этих опросах, отчетности так высоко, как 87,2% в 2018.

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

Имя	2015	2017	2018
Мерзавец	69.3%	69.2%	87.2%
Подрывная деятельность	36.9%	9.1%	16.1%
TFVC	12.2%	7.3%	10.9%
Ртутный	7.9%	1.9%	3.6%
резюме	4.2%	[ii]	[ii]
Волей-неволей	3.3%	[ii]	[ii]
ВСС	[ii]	0.6%	[ii]
Прозрачный кейс	[ii]	0.4%	[ii]
Резервные копии Zip-файлов	[ii]	2.0%	7.9%
Общий доступ к необработанной сети	[ii]	1.7%	7.9%
Другое	5.8%	3.0%	[ii]
Нет	9.3%	4.8%	4.8%

В Великобритании это сайт вакансии сайту itjobswatch.ко.СК сообщает, что по состоянию на конец сентября 2016 года, 29.27% британских постоянная разработка программного обеспечения вакансиях привел ЖКТ, впереди 12.17% для Microsoft сервера Team, 10.60% для подрывной деятельности, 1.30% для ртутный,[102] и 0,48% для визуальной sourcesafe с.

Расширения

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

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

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

Корпорация Майкрософт разработала расширение виртуальной файловой системы для Git (VFS для Git; ранее Виртуальная файловая система Git или GVFS) для обработки размера дерева исходного кода Windows в рамках их миграции в 2017 году из Perforce. VFS для Git позволяет клонированным репозиториям использовать заполнители, содержимое которых загружается только после доступа к файлу.

Конвенции

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

• Основная ветвь (ранее главная ветвь) создается по умолчанию с помощью git init и часто используется в качестве ветви, в которую объединяются другие изменения. Соответственно, по умолчанию имя вышестоящего удаленного узла-origin, поэтому имя удаленной ветви по умолчанию-origin/main. Хотя имя master было распространено до конца 2020 года, Охрана свободы программного обеспечения и проект Git признали его недостатки и начали искать альтернативу в июне 2020 года. Соответствующие проекты последовали этому примеру: с конца 2020 года новые репозитории GitHub называют ветку по умолчанию main, и с середины 2021 года новые репозитории GitLab делают то же самое.
• Принудительные фиксации обычно не должны быть перезаписаны, а скорее должны быть отменены (сверху выполняется фиксация, которая отменяет изменения более ранней фиксации). Это предотвращает недопустимость новых общих коммитов, основанных на общих коммитах, поскольку коммит, на котором они основаны, не существует в удаленном устройстве. Если фиксации содержат конфиденциальную информацию, их следует удалить, что включает в себя более сложную процедуру перезаписи истории.
• Рабочий процесс git-flow и соглашения об именах часто используются для различения нестабильных историй конкретных функций (функция/*), нестабильных общих историй (разработка), готовых к производству историй (основная) и аварийных исправлений для выпущенных продуктов (исправление).
• Запросы на извлечение не являются функцией git, но обычно предоставляются облачными службами git. Запрос на вытягивание-это запрос одного пользователя на объединение ветви их ветви репозитория в другой репозиторий с той же историей (называемый удаленным хранилищем).[111] Основная функция запроса на вытягивание ничем не отличается от функции администратора репозитория, извлекающего изменения из другого удаленного (репозитория, который является источником запроса на вытягивание). Однако сам запрос на вытягивание является билетом, управляемым хост-сервером, который инициирует сценарии для выполнения этих действий; это не функция git SCM.

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

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

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

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

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

Товарный знак

"Git" является зарегистрированной торговой маркой word компании Software Freedom Conservancy под номером US5000085961336 с 2015-02-03.

Этимология

МЕРЗАВЕЦ

Корни этого элегантного, но довольно резкого ругательства ведут к словам «мёрзнуть», «мёрзлый». Изначально так называли абсолютно холодного, бессердечного, равнодушного ко всему человека, неприятного до зябкой дрожи.

Однокоренные и с таким же скрытым смыслом обзывательства — «мразь» и «отморозок».

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

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

Пруф

git-scm.com

• /codesnippets.fandom.com/