Git. Создание репозитория на другом компе

Не буду топить за git, оно итак понятно, что те, кто не знает и не умеет пользоваться этой технологией, находятся за рамками интересов к ним самим и, соответственно, возможности заработать денег.

Использование бесплатных внешних репозитоиев git, таких как bitbucket, gitlab, github и других, — это весьма полезно, а иногда это единственная возможность для совместной работы над одним проектом нескольких разработчиков. Внешние репозитории так же хорошо подходят для одного разработчика-одиночки, который трудится над своими проектами из разных мест, например, из дома, с компа на территории заказчика, с рабочего комп и так далее.

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

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

Далее я кратко опишу процесс создания такого репозитория и покажу как настроить git для работы с ним. Описание процесса будет происходить в ключе «делай как я». Вам остаётся только подставить в приведённые здесь команды вместо наименований моих проектов и компов свои наименования.

Итак, исходные данные следующие.

Предположим, у меня имеется два компа. Один рабочий, на нём крутится Debian-10, а другой так-себе — Raspberry Pi. Разумеется, организовывать сервер git на Rasberry Pi — это не совсем правильное решение, но в некоторых случаях это нормально, а для примера с целью обучения — в самый раз.

Предположим, что у меня на рабочем компе имеется два проекта, которые мне хотелось бы поместить под «охрану» СУВ (Система Управления Версиями) git. Проекты имеют названия opcua и t62541 и располагаются в директориях /home/alex/test/py/opcua/ и /home/alex/work/t62541/, соответственно.

Рабочий комп имеет имя zh. Малинка называется — rasberrypi. И на компе, и на Малинке наименования моих учётных записей одинаковые — alex.

Итак, что я делаю.

На Малинке, в своем домашнем директории /home/alex я создаю поддиректорий repos и захожу в него:

Затем создаю в нём файл README, в котором описываю назначение этого директория.

В принципе, этого можно не делать. Но я уже много раз сталкивался со случаями, когда я однажды создавал поддиректории со сложной структурой (с файлами и поддиректориями), а потом, по прошествии какого-то времени, успешно забывал, что тут у меня лежит. Приходилось тратить время, просматривать файлы и восстанавливать картину. В таких случаях наличие файла README сэкономило бы массу времени и ментальных сил.

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

$ nano README

Напечатали? Сохраняемся (нажимаем F3) и выходим (F2).

Теперь открываем терминал рабочего компа и заходим в директорий с первым проектом.

Да, У меня тут оказалось много файлов. Но это ничего не значит. Проекты бывают всякие.

В этом директории создадим локальный репозиторий, поставим под контроль все файлы, и выполним первый коммит:

$ git init
$ git add .
$ git commit -m "Начальный коммит."

После выполнения коммита убедимся, что всё сохранено и изменений в рабочем проекте нет. Затем убедимся, что у нас в репозитории находится всего одна ветка развития проекта (ветка master) и никаких внешних репозиториев не отслеживается.

Это можно не делать. Но для ориентации, где мы находимся, не помешает.

$ git status
$ git branch -a
$ git remote

Хорошо. Теперь возвращаемся в окно терминала Малинки.

На Малинке нужно завести пустой репозиторий под наш проект. Проект называется opcua, поэтому мы создадим под него репозиторий с именем opcua.git:

$ git init --bare opcua.git

Команда ll показывает, что в директории repos появился поддиректорий opcua.git.
Отлично!

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

$ git remote add origin 172.16.27.128:repos/opcua.git/

слово origin — это краткое наименование удалённого репозитория. Сам удалённый репозитория имеет вот такое длинное имя — 172.16.27.128:repos/opcua.git/. Чтобы каждый раз не набирать его (тем более, что может так случится, что длинное имя может оказаться весьма трудным для запоминания и последующего безошибочного набора), обычно пользуются сокращённым именем. Как правило, это имя origin. Но можно определить и любое другое.

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

$ git push -u origin master

Всё! Теперь наш проект хранится в двух разных местах, и случайная потеря одной копии не приведёт к катастрофе.

Выполнение команды

$ git branch -a

показывает, что теперь у нас две ветки проекта.

Одна находится на локальном компе (ветка master), а другая — на удалённом (ветка remotes/origin/master).  И эти ветки мы можем синхронизировать между собой.

Не понятно? Хорошо, проделаем этот путь ещё раз, но с другим проектом.

Итак, открываем окно терминала на удалённом компе, на котором будет располагаться удалённый репозиторий. В выбранном поддиректории для будущих репозиториев создаём пустой пустой репозиторий под конкретный проект. На этот раз проект называется t62541:

$ git init --bare t62541.git

Затем на рабочем компе открываем окно терминала и заходим в директорий проекта:

$ cd ~/work/t62541

и там последовательно набираем следующие команды:

$ git init
$ git add main.c open62541.[ch]
$ git commit -m "первый коммит"
$ git add remote origin 172.16.27.128:repos/t62541.git/
$ git push -u origin master

Вот, и всё. Вот, и вся любофф.

Конечно, если  у вас IP-шник удалённого компа прописан в файле /etc/hosts, то даже и его не надо вспоминать и набирать ручками.

Допустим, сетевое имя Малинки у меня в /etc/hosts значится как

172.16.27.128    rpi

, тогда строка задания удалённого репозитория будет выглядеть ещё проще:

$ git remote add origin rpi:repos/t62541.git/

Не пытайтесь охватить всё сразу и тут же понять. Линукс — это не  виндовс-фастфуд. Линукс — это технология здорового питания и длительного усвоения.

3 responses to “Git. Создание репозитория на другом компе

  1. Для этих-же целей использовал gitolite — практически тоже самое, но слегка обмазанное сриптами. Установка и обслуживание чуть попроще и без дополнительных накладных расходов, ибо кроме git-a и нескольких скриптов обвязки там почти ничего нет.

    • Ага.

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

  2. Можно было ещё короче:

    Покупаете за пять баксов себе виртуалку с докером, устанавливаете там контейнер с GoGS (можно без докера, но повозиться придётся подольше в разы).

    Всё, занавес, у вас личный GitHub.
    https://gogs.io/

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s