Оффлайновое использование 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
.
Спасибо за внимание!
О, а приходите к нам работать? ? ?
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.