Оффлайновое использование Git

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

Система контроля версий Git вполне благополучно работает без удалённого репозитория. Такова её природа. При таком подходе можно создавать ветви репозитория, можно индексировать файлы и коммитить их в репозиторий. Всё выглядит так же, как и при обычной работе.

mkdir testRepo
cd testRepo
git init
touch test.txt
git add --all
git commit -m "Initial Commit"

Всё это отлично работает в том случае, когда разработка ведётся на единственном компьютере, но это не всегда так.

Разработка на нескольких компьютерах: применение USB-флешки или жёсткого диска

Когда политика безопасности компании позволяет выполнение операций чтения/записи в применении к флеш‑накопителю или к портативному жёсткому диску, удалённый репозиторий можно создать на подобном устройстве.

Смонтируем флешку на компьютере, на котором ведётся разработка.

cd /path/to/memory/stick
mkdir repoName.git
cd repoName.git
git init --bare

Перейдём в репозиторий, который планируется использовать несколькими разработчиками, добавим на флешку удалённый репозиторий и отправим в него изменения.

cd /path/to/local/repo/
git remote add origin /path/to/memory/stick/repoName.git
git push origin master

Обратите внимание на то, что удалённый репозиторий может называться как угодно. Он не обязательно должен носить имя origin.

Размонтируем флешку и смонтируем её на другом компьютере, где ведётся разработка.

Если на этом компьютере нет копии репозитория, то для его создания можно прибегнуть к команде git clone.

git clone /path/to/memory/stick/repoName.git

Если на компьютере уже есть копия репозитория — флешку можно добавить в систему в роли удалённого репозитория, а потом загрузить из него изменения.

cd /path/to/local/repo/
git remote add origin /path/to/memory/stick/repoName.git
git pull origin

С этого момента Git можно использовать как обычно, следя за тем, чтобы при выполнении команд git pull, fetch или push флешка была бы смонтирована на компьютере.

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

Разработка на нескольких компьютерах: применение CD/DVD-дисков

Если разработка ведётся в среде, к которой предъявляются повышенные требования безопасности, использование флеш‑накопителей на компьютерах может быть запрещено. В таких условиях, правда, тоже можно пользоваться Git, но это будет сопряжено с некоторыми неудобствами.

Git без проблем перенесёт изменения из одной копии локального репозитория в другую копию. Это значит, что один из вариантов работы в жёстко зарегулированной среде заключается в простом копировании директории, содержащей локальный Git‑репозиторий, на другой компьютер. Например — посредством CD‑диска или другого носителя информации. Изменения и коммиты при этом делаются на обеих машинах так же, как и при работе с удалённым репозиторием. Когда нужно скомбинировать изменения — выбирают один из компьютеров для выполнения слияния репозиториев и копируют на него другой репозиторий. Для загрузки всех изменений в текущую ветку репозитория можно использовать команду pull:

git pull /path/to/other/repo

Ещё для загрузки изменений можно воспользоваться командой fetch и создать новую ветку репозитория для их хранения:

git fetch /path/to/other/repo
git checkout -b new_branch FETCH_HEAD

На данном этапе завершим создание новой копии репозитория, применив слияния, и переместим её на другой компьютер или на другие компьютеры. Далее — достаточно воспользоваться командой pull для загрузки изменений в другие репозитории. Или, если нужно, можно просто заменить содержимое этих репозиториев копией нового репозитория.

Понятно, что такой порядок работы далёк от оптимального. Копирование всей директории репозитория сопряжено с копированием личных настроек разработчика, а так же — файлов, перечисленных в .gitignore, не включаемых в репозиторий. Для того чтобы сгладить проблемы такого рода — можно, вместо простого копирования репозитория, пользоваться командой push. Но гораздо лучше будет прибегнуть к созданию пакетов с применением команды git bundle.

Создание пакетов с помощью git bundle

Команда git bundle позволяет сформировать единый файл, поместив в него весь репозиторий или его часть. Этот файл хранится в таком формате, который позволяет Git работать с ним при вызове команд clone и fetch.

Порядок действий при применении этого метода очень близок к тому, что мы рассмотрели в прошлом разделе. Но вместо копирования всей директории репозитория создаётся Git‑пакет. Создадим такой пакет на одной машине, использовав такую команду:

git bundle create repoName.bundle --all

Опция --all позволяет включить в пакет весь репозиторий, в том числе — все ветви и теги. Выбрать конкретные ветви или теги можно, воспользовавшись опциями -b branchName или -t tagName.

Скопируем файл repoName.bundle на другой компьютер. Для клонирования репозитория воспользуемся такой простой командой:

git clone repoName.bundle

Изменения и коммиты можно делать на любой машине. А потом, как и прежде, нужно выбрать одну из них для выполнения слияния. На машинах, где слияние не делается, нужно, проверив, чтобы в репозиторий были бы внесены все изменения, создать пакеты с помощью такой команды:

git bundle create repoName.bundle --all

При работе с большими репозиториями имеет смысл подумать о том, чтобы включать в пакет лишь часть репозитория. Это позволит избежать переноса неоправданно больших объёмов данных. Например, чтобы включить в пакет 5 последних коммитов из ветки master, можно применить такую команду:

git bundle create repoName.bundle -5 master

Важно, чтобы не было пропусков между коммитами в пакете и коммитами в репозитории на той машине, где производится слияние репозиториев. Иначе ничего не получится.

Теперь скопируем пакет на компьютер, где производится слияние репозиториев, и с помощью команды pull загрузим изменения в репозиторий:

git pull /path/to/repoName.bundle

После завершения слияния/перебазирования репозитория создадим новый пакет:

git bundle create repoName.bundle --all

В этой команде опцию --all можно заменить на описание необходимых репозиториев/коммитов.

Теперь переместим пакет на другие машины и обновим их репозитории, загрузив в них новые данные:

git pull /path/to/repoName.bundle

Создание локального удалённого репозитория

Пакеты решают проблему синхронизации Git‑репозиториев при отсутствии компьютерной сети. Но и их использование означает, что компьютеры в нашей системе, скорее всего, будут слегка рассинхронизированы. Если к команде присоединится новый разработчик — с чьей машины ему скопировать репозиторий? Лучше всего будет назначить компьютер одного из разработчиков «сервером». На этом компьютере можно, с помощью ключа bare, создать чистый репозиторий. Он будет присутствовать на машине в дополнение к локальному клону репозитория, в котором разработчик будет заниматься своими делами.

cd /path/to/store/main/repo
mkdir remoteRepoName.git
cd remoteRepoName.git
git init --bare

Перейдём в локальный Git‑репозиторий (или создадим новый репозиторий) и добавим в него созданный на предыдущем шаге remoteRepoName.git в качестве удалённого репозитория.

cd /path/to/local/repo/
git remote add origin /path/to/store/main/repo/remoteRepoName.git
git push origin branchName

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

git push origin branchName

Итоги

Распределённая природа Git позволяет этой системе контроля версий нормально работать и без создания центрального сервера. То, о чём шла речь в этой статье, совсем не так удобно, как выгрузка данных на GitHub с помощью команды push. Но это, без сомнения, лучше альтернативы в виде «ручного» контроля версий, порождающей конструкции наподобие main_v1_final version_with_bobs_extra_patch finalfinal_version.

Спасибо за внимание!