Линус Торвальдс создал Git в середине 2000-х годов, чтобы решить проблему, которую в то время не могли распространять другие системы управления версиями с открытым исходным кодом, быть надежной и быстрой.
Как он упоминает в этом техническом докладе Google о Git , Git был создан по необходимости для проекта Linux. Во время выступления Git был очень молод, и люди привыкли к нему. Казалось, он решил все проблемы, с которыми сталкивается программное обеспечение контроля версий, и это способствовало его стремительному росту.
Git’s Недостатки
Перенесемся на несколько лет вперед, и люди начали замечать первый настоящий недостаток в Git: было трудно работать с очень большими репозиториями. Насколько большой мы говорим здесь? Это большой Facebook . Команда Facebook прогнозирует, что через несколько лет простой git status потребует до полминуты, чтобы показать результат, поскольку Facebook добавляет большое количество коммитов от тысяч разработчиков каждый день. Facebook перевел всю свою кодовую базу на Mercurial , и его команда активно начала вносить свой вклад в Mercurial для удовлетворения потребностей Facebook.
Где Git потерпел неудачу? Сотрудник Mercurial, Prasoon Shukla, сравнивая масштабирование в Git и Mercurial , говорит, что это можно отнести к тому, как Mercurial и Git хранят коммиты. Mercurial управляет парой объектов (или файлов) для каждого файла в вашем хранилище, тогда как Git создает объект для каждого коммита. Следовательно, при увеличении количества коммитов количество объектов в Mercurial остается постоянным, в отличие от линейного увеличения Git. Поэтому, когда вы запускаете простую команду git status , Git должен просеять все эти объекты, что занимает значительное время (несмотря на высокую эффективность Git).
Другая область, в которой Git может потерпеть неудачу, — это управление большими двоичными файлами в хранилище. Поскольку Git отслеживает изменения в файлах, он не может интерпретировать изменения в содержимом бинарных файлов. И размер репозитория увеличивается с каждым коммитом, потому что Git должен хранить точный двоичный файл, а не изменения по сравнению с предыдущей версией.
На протяжении многих лет разработчики Git пытались решить эти проблемы. Каждый сторонний сервис предлагает решения, позволяющие Git управлять большими репозиториями, например, расширение GitHub для хранения больших файлов .
В этом посте рассматриваются методы, которые можно использовать для обработки больших репозиториев в Git — с точки зрения больших историй, а также наличия больших двоичных файлов или обоих.
Проекты с большим количеством коммитов
Сначала я рассмотрю несколько способов более эффективного управления репозиториями с большими историями.
Мелкий клон репозиториев
Как упоминалось ранее, основной причиной замедления проектов с большой историей является огромное количество коммитов. В распределенной системе, такой как Git, когда вы клонируете репозиторий, загружается его полная история проекта. Тем не менее, Git предоставляет способ указать количество коммитов, которые вы хотите иметь в своем клоне проекта. Это известно как мелкий клон . Когда вы уменьшаете количество коммитов, ваши Git-операции выполняются быстрее.
Чтобы выполнить мелкое клонирование, вам нужно добавить опцию --depth с количеством коммитов, которое мы хотим, к команде clone :
git clone --depth [number_of_commits] [url_of_remote]
В более ранних версиях Git была ограниченная поддержка мелких клонов . Если ваша усеченная история не растянулась достаточно долго, вам не разрешалось толкать или тянуть. Однако с выпуском Git 1.9.0 поддержка мелких клонов была значительно увеличена.
Клонировать одну ветку
Когда вы клонируете репозиторий, все ветви на удаленном компьютере загружаются. (Если вы запускаете git branch в недавно клонированном репозитории, он показывает только master ветвь. Вы должны запустить git branch -a чтобы git branch -a список всех ветвей, которые были частью удаленного.) Вероятно, что многие из коммитов присутствуют в других ветки не имеют отношения к работе одного разработчика. Следовательно, вы можете клонировать только master или ветку, относящуюся к вашей разработке. Это значительно уменьшает количество коммитов, которые составляют историю клонированной версии, особенно если ветки в репозитории имеют расходящиеся истории.
Чтобы клонировать только одну ветку пульта, вы можете выполнить следующую команду:
git clone [url_of_remote] --branch [branch_name] --single-branch
Эта команда указывает Git клонировать только ветку branch_name с удаленного компьютера.
Проекты с большими файлами
Следующая проблема, которая возникает, — это наличие больших двоичных файлов (которые не являются традиционными текстовыми файлами). Git не отслеживает изменения в двоичных файлах, поэтому любое изменение в двоичном файле сохраняется как сам двоичный файл. Если бинарные файлы имеют большой размер (например, 3D-модели или графический дизайн), размер репозитория значительно увеличивается с каждым изменяющимся коммитом.
Использование субмодулей
Одним из выходов из проблемы больших файлов является использование субмодулей, которые позволяют вам управлять одним Git-репозиторием внутри другого. Вы можете создать подмодуль, который содержит все ваши двоичные файлы, оставляя остальной код отдельно в родительском репозитории и обновлять подмодуль только при необходимости. Это логически отделяет основную часть вашего проекта от больших файлов и помогает управлять ими отдельно.
Использование стороннего расширения
Существует множество расширений для Git, созданных другими разработчиками, для обработки больших файлов. Одним из вариантов является использование git-annex , которое позволяет вам управлять файлами в Git, не проверяя содержимое файла в Git. Другое расширение (разработка которого сейчас остановлена) — это git-bigfiles .
GitHub недавно запустил Git Large File Storage , расширение с открытым исходным кодом для Git, для управления большими двоичными файлами в Git. LFS хранит эти большие файлы на удаленном сервере, таком как GitHub, тогда как в вашем Git-хранилище хранятся только текстовые указатели. SitePoint недавно опубликовал учебник о том, как начать работу с Git LFS .
За короткое время Git LFS приобрел популярность, сигнализируя о том, что он обеспечивает хороший способ обработки таких больших двоичных файлов в Git.
Последние мысли
Прошло много времени с тех пор, как Facebook объявил о своем переходе на Mercurial (хотя он все еще продолжает использовать Git для сторонних проектов, таких как ReactJS ). Приятно видеть, что разработчики Git и сторонние разработчики и положительно отреагировали на это, и предложили инновационные решения проблем. Если вы думаете об изучении контроля версий, я бы порекомендовал вам перейти на Git, поскольку будущее определенно светлое!
Если вы хотите узнать больше о Git и его удивительных возможностях, ознакомьтесь с новой книгой Shaumik Jump Start Git , опубликованной прямо здесь, на SitePoint!
- Понять основную философию Git.
- Начните работать с Git: установите его, изучите основные команды и настройте свой первый проект.
- Работайте с Git в составе совместной команды.
- Используйте инструменты отладки Git для максимальной эффективности отладки.
- Возьмите под свой контроль расширенные функции Git: reflog, rebase, stash и многое другое.
- Используйте Git с облачными сервисами Git-репозитория, такими как Github и Bitbucket.
- Посмотрите, как Git эффективно используется в больших проектах с открытым исходным кодом.