✖


Jump to content

Гит

(Перенаправлено с Джунио Хамано )
Чтобы узнать о других значениях, см. Git (значения) .
Не путать с GitHub , GitLab или Gitea .

Гит
Оригинальный автор(ы) Линус Торвальдс [1]
Разработчик(и) Джунио Хамано и другие [2]
Первоначальный выпуск 7 апреля 2005 г .; 19 лет назад ( 07.04.2005 )
Стабильная версия
2.46.0 [3]  Отредактируйте это в Викиданных / 29 июля 2024 г.
Репозиторий
Написано в В основном на языке C , с графическим интерфейсом пользователя и сценариями программирования , написанными на языке Shell , Perl , Tcl и Python. [4] [5]
Операционная система POSIX ( Linux , macOS , Solaris , AIX ), Windows
Доступно в Английский
Тип Контроль версий
Лицензия Только GPL-2.0 [я] [7]
Веб-сайт git-scm .с  Edit this on Wikidata

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

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

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

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

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

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

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

История

[ редактировать ]

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

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

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

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

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

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

Мы

[ редактировать ]

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

В файле доступном для чтения, более подробно описано: исходного кода, [34]

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

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

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

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

[ редактировать ]

Дизайн

[ редактировать ]

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

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

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

Недостатки

[ редактировать ]

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

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

Объединение стратегий

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

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

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

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

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

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

Хранилище объектов содержит пять типов объектов: [60] [48]

  • Blob — это содержимое файла . У больших двоичных объектов нет правильного имени файла, меток времени или других метаданных (внутреннее имя большого двоичного объекта представляет собой хеш его содержимого). В Git каждый большой двоичный объект представляет собой версию файла, в которой содержатся данные файла. [61]
  • Объект дерева является эквивалентом каталога. Он содержит список имен файлов, [62] каждый из которых содержит несколько битов типа и ссылку на объект blob или дерева, который представляет собой файл, символическую ссылку или содержимое каталога. Эти объекты представляют собой снимок исходного дерева. (В целом это дерево Меркла , что означает, что достаточно только одного хеша для корневого дерева, и он фактически используется в коммитах для точного определения точного состояния целых древовидных структур любого количества подкаталогов и файлов.)
  • Объект фиксации связывает древовидные объекты вместе в историю. Он содержит имя объекта дерева (исходного каталога верхнего уровня), метку времени, сообщение журнала и имена нуля или более родительских объектов фиксации. [63]
  • Объект -тег — это контейнер, который содержит ссылку на другой объект и может содержать добавленные метаданные, связанные с другим объектом. Чаще всего он используется для хранения цифровой подписи объекта фиксации, соответствующей конкретной версии данных, отслеживаемых Git. [64]
  • Объект Packfile собирает различные другие объекты в пакет, сжатый zlib, для компактности и простоты транспортировки по сетевым протоколам. [65]

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

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

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

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

Команды

[ редактировать ]

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

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

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

Ссылки на Git

[ редактировать ]

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

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

Реализации

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

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

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

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

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

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

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

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

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

Git-сервер

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

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

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

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

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

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

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

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

[ редактировать ]

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

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

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

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

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

Список клиентов с графическим интерфейсом

[ редактировать ]

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

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

[ редактировать ]

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

[ редактировать ]

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

[ редактировать ]

Собственный графический интерфейс GIT

[ редактировать ]

Принятие

[ редактировать ]

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

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

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

Имя 2015 2017 2018 2022
Гит 69.3% 69.2% 87.2% 93.9%
Подрывная деятельность 36.9% 9.1% 16.1% 5.2%
ТФВК 12.2% 7.3% 10.9% [ii]
Меркуриальный 7.9% 1.9% 3.6% 1.1%
CVS 4.2% [ii] [ii] [ii]
Перфорс 3.3% [ii] [ii] [ii]
ВСС [ii] 0.6% [ii] [ii]
Код IBM DevOps ClearCase [ii] 0.4% [ii] [ii]
Резервные копии ZIP-файлов [ii] 2.0% 7.9% [ii]
Общий доступ к сети [ii] 1.7% 7.9% [ii]
Другой 5.8% 3.0% [ii] [ii]
Никто 9.3% 4.8% 4.8% 4.3%

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

Расширения

[ редактировать ]

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

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

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

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

Конвенции

[ редактировать ]

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

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

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

[ редактировать ]

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

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

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

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

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

[ редактировать ]

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

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ GPL-2.0 - только с 11 апреля 2005 г. Некоторые части находятся под совместимыми лицензиями, такими как LGPLv2.1 . [6]
  2. ^ Перейти обратно: а б с д и ж г час я дж к л м н тот п д р с Не указан в качестве опции в этом опросе

Цитаты

[ редактировать ]
  1. ^ «Первоначальная версия «git», адского информационного менеджера» . Гитхаб . 8 апреля 2005 г. Архивировано из оригинала 16 ноября 2015 г. Проверено 20 декабря 2015 г.
  2. ^ «График фиксации» . Гитхаб . 8 июня 2016 г. Архивировано из оригинала 20 января 2016 г. . Проверено 19 декабря 2015 г.
  3. ^ Джунио С. Хамано (29 июля 2024 г.). «[АНОНС] Git v2.46.0» . Проверено 29 июля 2024 г.
  4. ^ «Сайт Git» . Архивировано из оригинала 9 июня 2022 года . Проверено 9 июня 2022 г.
  5. ^ «Зеркало исходного кода Git» . Гитхаб . Архивировано из оригинала 3 июня 2022 года . Проверено 9 июня 2022 г.
  6. ^ «Лицензия Git LGPL на github.com» . Гитхаб . 20 мая 2011 года. Архивировано из оригинала 11 апреля 2016 года . Проверено 12 октября 2014 г.
  7. ^ «Лицензия Git GPL на github.com» . Гитхаб . 18 января 2010 года. Архивировано из оригинала 11 апреля 2016 года . Проверено 12 октября 2014 г.
  8. ^ «Tech Talk: Линус Торвальдс на git (00:01:30)» . Архивировано из оригинала 20 декабря 2015 года . Проверено 20 июля 2014 г. - через YouTube.
  9. ^ Чакон и Штрауб 2014 , стр. 29–31.
  10. ^ Перейти обратно: а б Торвальдс, Линус (7 апреля 2005 г.). «Re: Сага о Kernel SCM...» linux-kernel (список рассылки). Архивировано из оригинала 1 июля 2019 года . Проверено 3 февраля 2017 г. «Поэтому я пишу несколько сценариев, чтобы попытаться отслеживать ситуацию намного быстрее».
  11. ^ Перейти обратно: а б Торвальдс, Линус (10 июня 2007 г.). «Re: фатально: серьезное раздувание несоответствия» . git (список рассылки).
  12. ^ Перейти обратно: а б с д Линус Торвальдс (3 мая 2007 г.). Технический доклад Google: Линус Торвальдс о git . Событие происходит в 02:30. Архивировано из оригинала 28 мая 2007 года . Проверено 16 мая 2007 г.
  13. ^ Перейти обратно: а б «Краткая история Git» . Pro Git (2-е изд.). Апресс. 2014. Архивировано из оригинала 25 декабря 2015 года . Проверено 26 декабря 2015 г.
  14. ^ Чакон, Скотт (24 декабря 2014 г.). Pro Git (2-е изд.). Нью-Йорк, штат Нью-Йорк: Апресс . стр. 29–30. ISBN  978-1-4842-0077-3 . Архивировано из оригинала 25 декабря 2015 года.
  15. ^ Перейти обратно: а б «Опрос разработчиков Stack Overflow 2022» . Переполнение стека . Проверено 4 августа 2022 г.
  16. ^ Криль, Пол (28 сентября 2016 г.). «Корпоративные войны репо: GitHub против GitLab против Bitbucket» . Инфомир . Проверено 2 февраля 2020 г.
  17. ^ Перейти обратно: а б «Конкурентный анализ github.com, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 31 марта 2013 года . Проверено 2 февраля 2020 г.
  18. ^ Перейти обратно: а б «Конкурентный анализ sourceforge.net, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 20 октября 2020 года . Проверено 2 февраля 2020 г.
  19. ^ Перейти обратно: а б «Конкурентный анализ Bitbucket.org, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 23 июня 2017 года . Проверено 2 февраля 2020 г.
  20. ^ Перейти обратно: а б «Конкурентный анализ gitlab.com, маркетинговый комплекс и трафик» . Алекса . Архивировано из оригинала 30 ноября 2017 года . Проверено 2 февраля 2020 г.
  21. ^ Браун, Зак (27 июля 2018 г.). «История происхождения Git» . Linux-журнал . Linux-журнал. Архивировано из оригинала 13 апреля 2020 года . Проверено 28 мая 2020 г.
  22. ^ «BitKeeper и Linux: конец пути?» . Linux.com . 11 апреля 2005 года . Проверено 18 мая 2023 г.
  23. ^ Макаллистер, Нил (2 мая 2005 г.). «Ошибка BitKeeper Линуса Торвальдса» . Инфомир . Архивировано из оригинала 26 августа 2015 года . Проверено 8 сентября 2015 г.
  24. ^ Перейти обратно: а б Торвальдс, Линус (27 февраля 2007 г.). «Re: Общая информация: Когда git стал самостоятельным хостом?» . git (список рассылки).
  25. ^ Торвальдс, Линус (6 апреля 2005 г.). «Сага о Kernel SCM». linux-kernel (список рассылки).
  26. ^ Торвальдс, Линус (17 апреля 2005 г.). «Первое настоящее слияние ядра git!» . git (список рассылки).
  27. ^ Макколл, Мэтт (29 апреля 2005 г.). «Бенчмарк Mercurial 0.4b против git patchbomb» . git (список рассылки).
  28. ^ Торвальдс, Линус (17 июня 2005 г.). «Линукс 2.6.12» . git-commits-head (список рассылки).
  29. ^ Торвальдс, Линус (27 июля 2005 г.). «Знакомьтесь, новый сопровождающий». git (список рассылки).
  30. ^ Хамано, Хунио К. (21 декабря 2005 г.). «Объявить: Git 1.0.0» . git (список рассылки).
  31. ^ «GitFaq: Почему такое название «Git»?» . Git.or.cz. Архивировано из оригинала 23 июля 2012 года . Проверено 14 июля 2012 г.
  32. ^ «После разногласий Торвальдс начинает работу над «git » . Мир ПК . 14 июля 2012 г. Архивировано из оригинала 1 февраля 2011 г. Торвальдс , похоже, осознавал, что его решение отказаться от BitKeeper также будет спорным. Когда его спросили, почему он назвал новое программное обеспечение «мерзавцем», что на британском сленге означает «гнилой человек», он ответил. «Я эгоистичный ублюдок, поэтому все свои проекты называю в свою честь. Сначала Linux, теперь git».
  33. ^ «Страница руководства git(1)» . Архивировано из оригинала 21 июня 2012 года . Проверено 21 июля 2012 года .
  34. ^ «Первоначальная версия 'git', адского информационного менеджера · git/git@e83c516» . Гитхаб . Архивировано из оригинала 8 октября 2017 года . Проверено 21 января 2016 г.
  35. ^ «Git — распределенные рабочие процессы» . Гит . Архивировано из оригинала 22 октября 2014 года . Проверено 15 июня 2020 г.
  36. ^ Гунджал, Сиддхеш (19 июля 2019 г.). «Что такое инструмент контроля версий? Изучите Git и GitHub» . Середина . Проверено 25 октября 2020 г.
  37. ^ Торвальдс, Линус (19 октября 2006 г.). "Re: Сравнительная таблица VCS" . git (список рассылки).
  38. ^ Блог Jst о Mozillazine «производительность bzr/hg/git» . Архивировано из оригинала 29 мая 2010 года . Проверено 12 февраля 2015 г.
  39. ^ Драйер, Роланд (13 ноября 2006 г.). «О, какое это облегчение» . Архивировано из оригинала 16 января 2009 г. , отметив, что «git log» работает в 100 раз быстрее, чем «svn log», поскольку последний должен связаться с удаленным сервером.
  40. ^ "Доверять" . Концепции Git . Руководство пользователя Git. 18 октября 2006 г. Архивировано из оригинала 22 февраля 2017 г.
  41. ^ Торвальдс, Линус. "Re: Сравнительная таблица VCS" . git (список рассылки) . Проверено 10 апреля 2009 г. , описывающий скрипт-ориентированный дизайн Git
  42. ^ Ябервон (22 декабря 2005 г.). «Гит рулит!» . Архивировано из оригинала 14 сентября 2016 года. , хвалит возможности Git по написанию сценариев.
  43. ^ «Git – Git SCM Wiki» . git.wiki.kernel.org . Проверено 25 октября 2020 г.
  44. ^ Чакон и Штрауб 2014 .
  45. ^ «Руководство пользователя Git» . 10 марта 2020 г. Архивировано из оригинала 10 мая 2020 г.
  46. ^ Чакон и Штрауб 2014 , с. 499.
  47. ^ Чакон и Штрауб 2014 , стр. 33–34.
  48. ^ Перейти обратно: а б «Git — Packfiles» . Гит .
  49. ^ Чакон и Штрауб 2014 , с. 568.
  50. ^ Торвальдс, Линус (10 апреля 2005 г.). «Re: больше обновлений git». linux-kernel (список рассылки).
  51. ^ Хайбле, Бруно (11 февраля 2007 г.). "как ускорить 'git log'?" . git (список рассылки).
  52. ^ Торвальдс, Линус (1 марта 2006 г.). «Re: нечистые переименования/отслеживание истории» . git (список рассылки).
  53. ^ Хамано, Хунио К. (24 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки).
  54. ^ Хамано, Хунио К. (23 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки).
  55. ^ Торвальдс, Линус (28 ноября 2006 г.). «Re: git и bzr» . git (список рассылки). , при использовании git-blame чтобы показать код, перемещенный между исходными файлами.
  56. ^ Торвальдс, Линус (18 июля 2007 г.). "git-merge(1)" . Архивировано из оригинала 16 июля 2016 года.
  57. ^ Торвальдс, Линус (18 июля 2007 г.). «КриссКроссСлияние» . Архивировано из оригинала 13 января 2006 года.
  58. ^ Торвальдс, Линус (10 апреля 2005 г.). «Re: больше обновлений git...» linux-kernel (список рассылки).
  59. ^ Торвальдс, Линус (23 марта 2006 г.). «Re: Ошибки GITtifying GCC и Binutils» . git (список рассылки). Архивировано из оригинала 22 марта 2021 года . Проверено 3 февраля 2017 г.
  60. ^ «Git – Объекты Git» . Гит .
  61. ^ Перейти обратно: а б Чакон и Штрауб, 2014 , стр. 81–83.
  62. ^ Чакон и Штрауб 2014 , стр. 485–488.
  63. ^ Чакон и Штрауб, 2014 , стр. 488–490.
  64. ^ Чакон и Штрауб, 2014 , стр. 495–496.
  65. ^ Чакон и Штрауб 2014 , стр. 497–501.
  66. ^ «Git – Ссылки на Git» . Гит .
  67. ^ «Шпаргалка по Git» (PDF) . Education.github.com . Проверено 10 июня 2024 г.
  68. ^ «Учебник по Git» (PDF) . веб-сайт Stanford.edu . Проверено 10 июня 2024 г.
  69. ^ «Краткое введение в Git» (PDF) . данные-skills.github.io . Проверено 10 июня 2024 г.
  70. ^ Ба Тран, Эндрю. «Рекомендации по загрузке на GitHub» (PDF) . сайт Journalismcourses.org . Проверено 10 июня 2024 г.
  71. ^ «Формат файла конфигурации проекта» . Обзор кода Геррита . Архивировано из оригинала 3 декабря 2020 года . Проверено 2 февраля 2020 г.
  72. ^ «загрузки» . Архивировано из оригинала 8 мая 2012 года . Проверено 14 мая 2012 г.
  73. ^ «Версии пакетов git — Репология» . Архивировано из оригинала 19 января 2022 года . Проверено 30 ноября 2021 г.
  74. ^ «мсисГит» . Гитхаб . Архивировано из оригинала 10 октября 2016 года . Проверено 20 сентября 2016 г.
  75. ^ «Git — Загрузка пакета» . Гит . ( исходный код )
  76. ^ «ДжГит» . Архивировано из оригинала 31 августа 2012 года . Проверено 24 августа 2012 г.
  77. ^ «Гит-гоу-гит» . Гит . Проверено 19 апреля 2019 г.
  78. ^ «SQL-интерфейс к репозиториям Git, написанный на Go». , github.com , получено 19 апреля 2019 г.
  79. ^ «Keybase запускает зашифрованный git» . keybase.io . Проверено 19 апреля 2019 г.
  80. ^ «README.md репозитория GitHub в Далвиче» . Гитхаб . Архивировано из оригинала 29 апреля 2024 года . Проверено 29 апреля 2024 г.
  81. ^ "либгит2" . Гитхаб . Архивировано из оригинала 11 апреля 2016 года . Проверено 24 августа 2012 г.
  82. ^ «грубый» . Гитхаб . Архивировано из оригинала 24 июля 2013 года . Проверено 24 августа 2012 г.
  83. ^ "пигит2" . Гитхаб . Архивировано из оригинала 5 августа 2015 года . Проверено 24 августа 2012 г.
  84. ^ "хлибгит2" . Архивировано из оригинала 25 мая 2013 года . Проверено 30 апреля 2013 г.
  85. ^ «js-git: реализация Git на JavaScript» . Гитхаб . Архивировано из оригинала 7 августа 2013 года . Проверено 13 августа 2013 г.
  86. ^ «Игра деревьев» . gameoftrees.org . Проверено 10 марта 2024 г.
  87. ^ Чакон и Штрауб 2014 , стр. 138–139.
  88. ^ «Git – Git Daemon» . Гит . Проверено 10 июля 2019 г.
  89. ^ 4.4 Git на сервере — настройка сервера. Архивировано 22 октября 2014 г. на Wayback Machine , Pro Git.
  90. ^ «1.4 Начало работы – установка Git» . Гит. Архивировано из оригинала 2 ноября 2013 года . Проверено 1 ноября 2013 г.
  91. ^ Чакон, Скотт; Штрауб, Бен (2014). «Git на сервере – Настройка сервера» . Pro Git (2-е изд.). Апресс. ISBN  978-1484200773 .
  92. ^ Руководство пользователя Diffusion: Хостинг репозитория. Архивировано 20 сентября 2020 г. на Wayback Machine .
  93. ^ «Gitolite: размещение репозиториев Git» .
  94. ^ «Gogs: безболезненный самостоятельный сервис Git» .
  95. ^ «Основные моменты Git 2.26» . Блог GitHub . 22 марта 2020 г. Архивировано из оригинала 22 марта 2021 г. . Проверено 25 ноября 2020 г. Возможно, вы помните, когда еще в 2018 году Git представил новую версию своего протокола сетевой выборки. Теперь этот протокол используется по умолчанию в версии 2.26, поэтому давайте освежим информацию о том, что это значит. Самая большая проблема старого протокола заключается в том, что сервер немедленно перечисляет все ветки, теги и другие ссылки в репозитории, прежде чем клиент сможет что-либо отправить. Для некоторых репозиториев это может означать отправку мегабайтов дополнительных данных, когда клиент действительно хочет знать только о главной ветке. Новый протокол начинается с запроса клиента и предоставляет клиенту возможность сообщить серверу, какие ссылки его интересуют. При выборе одной ветки будет запрашиваться только об этой ветке, в то время как большинство клонов будут запрашивать только о ветках и тегах. Может показаться, что это все, но репозитории серверов могут хранить и другие ссылки (например, заголовок каждого запроса на включение, открытого в репозитории с момента его создания). Теперь скорость выборки из больших репозиториев увеличивается, особенно когда сама выборка невелика, что, условно говоря, делает стоимость первоначальной ссылочной рекламы более дорогой. И самое приятное то, что вам не нужно ничего делать! Благодаря продуманной конструкции любой клиент, поддерживающий новый протокол, может беспрепятственно работать как со старыми, так и с новыми серверами, возвращаясь к исходному протоколу, если сервер его не поддерживает. Единственная причина задержки между внедрением протокола и его использованием по умолчанию заключалась в том, чтобы позволить ранним пользователям обнаружить любые ошибки.
  96. ^ «Git — Документация git-gui» . Гит . Проверено 1 июля 2024 г.
  97. ^ «Git — клиенты с графическим интерфейсом» . Гит . Проверено 1 июля 2024 г.
  98. ^ «Результаты опроса сообщества Eclipse за 2014 год | Ян Скерретт» . Ianskerrett.wordpress.com. 23 июня 2014 года. Архивировано из оригинала 25 июня 2014 года . Проверено 23 июня 2014 г.
  99. ^ «Результаты опроса сообщества Eclipse 2012» . eclipse.org. Архивировано из оригинала 11 апреля 2016 года.
  100. ^ «Сравнить репозитории – Open Hub» . Архивировано из оригинала 7 сентября 2014 года.
  101. ^ «Ежегодный опрос разработчиков Stack Overflow» . Стек Биржа, Inc. Проверено 9 января 2020 г. Ежегодный опрос разработчиков Stack Overflow — это крупнейший и наиболее полный опрос людей, которые программируют по всему миру. Каждый год мы проводим опрос, охватывающий все: от любимых технологий разработчиков до их предпочтений в работе. В этом году мы уже девятый раз публикуем результаты нашего ежегодного опроса разработчиков, и в начале этого года почти 90 000 разработчиков приняли участие в 20-минутном опросе.
  102. ^ «Опрос разработчиков Stack Overflow 2015» . Переполнение стека. Архивировано из оригинала 4 мая 2019 года . Проверено 29 мая 2019 г.
  103. ^ «Опрос разработчиков Stack Overflow 2017» . Переполнение стека. Архивировано из оригинала 29 мая 2019 года . Проверено 29 мая 2019 г.
  104. ^ «Опрос разработчиков Stack Overflow 2018» . Переполнение стека. Архивировано из оригинала 30 мая 2019 года . Проверено 29 мая 2019 г.
  105. ^ «Вакансии в Git (программное обеспечение), средняя зарплата для навыков работы с распределенной системой контроля версий Git» . Itjobswatch.co.uk. Архивировано из оригинала 8 октября 2016 года . Проверено 30 сентября 2016 г.
  106. ^ «Вакансии Team Foundation Server, средняя зарплата для навыков Microsoft Team Foundation Server (TFS)» . Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Проверено 30 сентября 2016 г.
  107. ^ «Вакансии по подрывной деятельности, средняя зарплата для навыков Apache Subversion (SVN)» . Itjobswatch.co.uk. Архивировано из оригинала 25 октября 2016 года . Проверено 30 сентября 2016 г.
  108. ^ «Метуативные вакансии, средняя зарплата для ртутных навыков» . Itjobswatch.co.uk. Архивировано из оригинала 23 сентября 2016 года . Проверено 30 сентября 2016 г.
  109. ^ «Вакансии VSS/SourceSafe, средняя зарплата для навыков Microsoft Visual SourceSafe (VSS)» . Itjobswatch.co.uk. Архивировано из оригинала 29 октября 2016 года . Проверено 30 сентября 2016 г.
  110. ^ «Переход Windows на Git почти завершен: 8500 коммитов и 1760 сборок каждый день» . Арс Техника . 24 мая 2017 года. Архивировано из оригинала 24 мая 2017 года . Проверено 24 мая 2017 г.
  111. ^ "git-инит" . Гит . Архивировано из оригинала 15 марта 2022 года.
  112. ^ «Git – ветки в двух словах» . Гит . Архивировано из оригинала 20 декабря 2020 года . Проверено 15 июня 2020 г. Ветка «master» в Git не является специальной веткой. Это точно так же, как и любая другая отрасль. Единственная причина, по которой он есть почти в каждом репозитории, заключается в том, что команда git init создает его по умолчанию, и большинство людей не удосуживаются его изменить.
  113. ^ Чакон и Штрауб 2014 , стр. 103–109.
  114. ^ github/renameming , GitHub, 4 декабря 2020 г. , получено 4 декабря 2020 г.
  115. ^ Имя ветки по умолчанию для новых репозиториев теперь является основным , GitLab, 22 июня 2021 г. , получено 22 июня 2021 г.
  116. ^ «Git Revert | Учебное пособие по Atlassian Git» . Атласиан . Возврат имеет два важных преимущества перед сбросом. Во-первых, он не меняет историю проекта, что делает его «безопасной» операцией для коммитов, которые уже были опубликованы в общем репозитории.
  117. ^ «Рабочий процесс Gitflow | Учебное пособие по Atlassian Git» . Атласиан . Проверено 15 июня 2020 г.
  118. ^ Чакон и Штрауб 2014 , стр. 170–174.
  119. ^ «Рабочий процесс разветвления | Учебное пособие по Atlassian Git» . Атласиан . Проверено 15 июня 2020 г.
  120. ^ «Контроль доступа к репозиторию Git» . Архивировано из оригинала 14 сентября 2016 года . Проверено 6 сентября 2016 г.
  121. ^ Петтерсен, Тим (20 декабря 2014 г.). «Защита вашего сервера Git от CVE-2014-9390» . Архивировано из оригинала 24 декабря 2014 года . Проверено 22 декабря 2014 г.
  122. ^ Хамано, JC (18 декабря 2014 г.). «[Анонс] Git v2.2.1 (и обновления для старых версий обслуживания)» . Группа новостей : gmane.linux.kernel . Архивировано из оригинала 19 декабря 2014 года . Проверено 22 декабря 2014 г.
  123. ^ «CVE-2015-7545» . 15 декабря 2015 года. Архивировано из оригинала 26 декабря 2015 года . Проверено 26 декабря 2015 г.
  124. ^ «Гит 2.6.1» . Гитхаб . 29 сентября 2015 г. Архивировано из оригинала 11 апреля 2016 г. Проверено 26 декабря 2015 г.
  125. ^ Перейти обратно: а б с Блейк Беркхарт; и др. (5 октября 2015 г.). «Re: Запрос CVE: git» . Архивировано из оригинала 27 декабря 2015 года . Проверено 26 декабря 2015 г.
  126. ^ «хеш — насколько безопасны подписанные теги git? Только так же безопасно, как SHA-1, или как-то безопаснее?» . Обмен стеками информационной безопасности. 22 сентября 2014 г. Архивировано из оригинала 24 июня 2016 г.
  127. ^ «Почему Git использует криптографическую хэш-функцию?» . Переполнение стека. 1 марта 2015 г. Архивировано из оригинала 1 июля 2016 г.
  128. ^ «Git – Документация по переходу хэш-функций» . Гит .
[ редактировать ]
Викискладе есть медиафайлы, связанные с Git .
В Wikibooks есть книга на тему: Git.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Git&oldid=1238010237"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c4c76414f9c579ba8491779b8e610166__1722519900
URL1:https://arc.ask3.ru/arc/aa/c4/66/c4c76414f9c579ba8491779b8e610166.html
Заголовок, (Title) документа по адресу, URL1:
Git - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)