Git стал стандартом для контроля версий, и большинство разработчиков привыкли пользоваться этой системой на платформах вроде GitHub и GitLab. Однако использование чистого Git без привязки к этим сервисам дает значительные преимущества:
- Полный контроль над репозиторием. Когда код хранится на сторонних платформах, вы зависите от их политики, владельцев и возможных изменений в правилах. С чистым Git вы полностью контролируете свои проекты: где и как они хранятся, кто имеет к ним доступ и какие инструменты они могут использовать.
- Простота настройки и минимальные зависимости. Платформы типа GitHub удобны, но требуют дополнительных сервисов (базы данных, веб-интерфейсов и прочего). Чистый Git гораздо легче развернуть и обслуживать.
- Гибкость в отправке исправлений. На GitHub есть единственный стандартный способ отправки кода – через запрос на вытягивание. В чистом Git можно передавать изменения несколькими удобными способами, причем без регистрации на платформе, без 2FA-аутентификации, без сбора личных данных и т.п.
- Безопасность. Гораздо разумнее держать кодовые базы конфиденциальных корпоративных проектов на собственном внутреннем сервере.
Код из чистого Git-репозитория можно клонировать с помощью git clone, а для просмотра без клонирования использовать веб-интерфейс gitweb. Чуть сложнее дело обстоит с отправкой исправлений (на GitHub это можно сделать, нажав кнопку Create pull request). Это обстоятельство ставит в тупик многих разработчиков, которые хотели бы внести свой вклад в проект, находящийся в чистом Git-репозитории. Ниже мы рассмотрим три основных способов отправки кода в чистый Git-репозиторий.
Как отправить код в чистый Git-репозиторий
1. Лучший вариант – ссылка на ваш репозиторий на любом сервисе или личном сайте.
Создайте ветку с исправлениями и пришлите владельцу проекта ссылку:
git clone https://your.repo.url
Этот способ предпочитают большинство владельцев чистых Git-репозиториев, потому что он:
- Не загромождает почту патчами.
- Автор проекта может просто выполнить
git fetchи увидеть изменения. - Обновление патчей происходит проще – если владелец оставил комментарии к коду, вам не нужно снова отправлять полный набор файлов. Достаточно обновить ветку в вашем репозитории и отправить новое письмо.
URL может быть любым, главное, чтобы его можно было передать в git clone или чтобы он вел на веб-страницу, где есть ссылка, пригодная для git clone. Это может быть страница на git-хостинге (GitHub и т.п.), либо просто статический сайт, куда вы загрузили репозиторий и запустили git update-server-info.
По сути, это тот же самый процесс, что и формализованный запрос на вытягивание (или запрос на слияние) в системах управления репозиториями. Именно поэтому там сначала нужно форкнуть (клонировать) целевой репозиторий, внести изменения в ветку и отправить PR. Формально кнопка Create pull request делает то же самое, но имейл с этой информацией ничем не хуже.
2. Использование git bundle.
Git bundle – это недостаточно известная, но очень полезная функция Git, которая позволяет упаковать целый репозиторий или его часть в один файл. Эта функция незаменима, если у вас нет возможности выложить код в открытый доступ. Бандлы (архивы) бывают полными и инкрементальными.
Полный бандл – это весь Git-репозиторий, упакованный в один файл. Он содержит:
- Коллекцию Git-объектов.
- Набор ссылок – обычно это вершины (HEAD) веток.
С таким бандлом можно работать так же, как с удаленным репозиторием:
- Использовать
git fetchилиgit pull, указав имя файла. - Начать с
git ls-remote, чтобы увидеть, какие ветки содержатся в бандле.
Единственное ограничение – вы не можете изменять сам бандл
Инкрементальный бандл содержит только часть объектов, предполагая, что получатель уже имеет некоторые базовые объекты. Это идеально подходит для отправки патчей к существующему репозиторию.
git bundle create fix-weasel-rotator.bundle origin/main..HEAD
Полученный файл fix-weasel-rotator.bundle можно отправить по почте или через мессенджер.
Преимущества метода:
- Один файл независимо от количества патчей.
- Компактность – бандлы значительно меньше текстовых файлов патчей (используют то же сжатие, что и упакованный формат объектов Git).
- Бинарный формат защищает от искажений при передаче по электронной почте (клиенты не пытаются «улучшить» форматирование или кодировку).
- Полные данные о коммитах – сохраняются родительские связи, что позволяет легко определить базовый коммит и применить правильный ребейз.
- Продвинутая обработка конфликтов – возможность использовать
git rebaseвместоgit am.
3. Текстовые патчи (git format-patch).
Команда git format-patch создаeт набор текстовых файлов с патчами, по одному для каждого коммита. Эти патчи автоматически получают имена в формате 0001-*, 0002-* и так далее, что позволяет легко отслеживать их порядок применения:
git format-patch origin/main
Эти файлы можно отправить автору проекта как вложения к письму (именно как вложения в виде текстового или zip-файла, а не фрагменты кода в теле письма, так как email-клиенты могут испортить разметку). По сравнению с бандлами этот подход имеет несколько недостатков:
1. Сложность управления несколькими файлами.
- При получении письма с пятью патчами необходимо работать с пятью отдельными файлами.
- Имена файлов длинные и неудобные для работы.
2. Уязвимость текстового формата.
Текстовые файлы могут быть изменены почтовым клиентом во время передачи, и это может привести к серьезным проблемам при применении патчей.
3. Проблемы с разрешением конфликтов.
- Команда git am, которая применяет эти патчи, не всегда эффективно справляется с конфликтами.
- Поскольку патчи не содержат информацию о базовом коммите, вероятность возникновения конфликтов выше.
Как не надо отправлять патчи
Эти способы не подходят большинству владецев чистых Git-репозиториев:
- Не используйте
git send-email, так как это усложняет обработку патчей – они приходят вразнобой, и владельцу придется вручную сортировать файлы. git diffвместо патча, поскольку в diff нет информации о коммитах, авторах и комментариях. Более того, владельцу придется вручную писать сообщения коммитов, а для этого нужно либо хорошо понимать суть исправления, либо копировать текст из сопроводительного имейла.
Заключение
Использование чистого Git-репозитория – это не шаг назад от современных облачных решений, а осознанный выбор в пользу большей свободы, безопасности и контроля. Отсутствие привязки к конкретному сервису защищает вас от неожиданных изменений в его политике и гарантирует сохранность личных данных.
Как мы убедились, отправлять патчи в проекты, использующие чистый Git, не так сложно, как может показаться на первый взгляд. Ссылка на ваш репозиторий, git bundle или грамотно оформленные текстовые патчи – каждый из этих подходов имеет свои преимущества и эффективно решает задачу обмена кодом.
Освоив эти методы, вы не только расширите свои возможности как разработчик, но и сможете участвовать в более широком спектре проектов, включая те, которые предпочитают держаться в стороне от популярных облачных платформ.
Комментарии