😺🐙🧼 Сам себе GitHub: как работать с чистым Git-репозиторием

Git – мощная система контроля версий, которую обычно используют через платформы вроде GitHub и GitLab. Однако Git сам по себе не требует веб-интерфейсов и облачных сервисов. Многие разработчики предпочитают работать с чистым Git-репозиторием, размещенным на собственном сервере. В этой статье мы рассмотрим, почему это удобно, и как эффективно отправлять патчи в проекты, использующие этот подход.

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 или грамотно оформленные текстовые патчи – каждый из этих подходов имеет свои преимущества и эффективно решает задачу обмена кодом.

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