Эта страница была обновлена 2020-09 и содержит сведения для версии маршрутизатора 0.9.47.

Git over I2P for Users

Руководство по настройке доступа к git через туннель I2P. Этот туннель будет действовать как точка доступа к одному git-сервису на I2P.

Если вы собираетесь использовать сервис на i2pgit.org/git.idk.i2p, то у вас, вероятно, уже настроен туннель, и большая часть этого урока к вам не относится.

Первое: Создайте учетную запись в сервисе Git

Чтобы создать свои репозитории на удаленном git-сервисе, зарегистрируйте учетную запись пользователя на этом сервисе. Конечно, можно также создавать репозитории локально и отправлять их на удаленный git-сервис, но в большинстве случаев для этого потребуется учетная запись и создание места для репозитория на сервере. На Gitlab есть очень простая форма регистрации:

Это общие инструкции для любого случая в-i2p Git с HTTP и SSH шлюзами. Если вы собираетесь внести свой вклад в I2P, вам следует создать учетную запись в I2P gitlab, которая открыта для сообщества. Регистрация аккаунта может занять несколько дней, поскольку администратору необходимо отсортировать большое количество спам-регистраций. Вы можете помочь в этом, связавшись с администратором, чтобы подтвердить, что вы человек, используя инструкции на главной странице.

Second: Create a project to test with

Чтобы убедиться, что процесс настройки работает, полезно создать репозиторий для тестирования с сервера, и в рамках этого руководства мы будем использовать форк маршрутизатора I2P. Сначала перейдите в репозиторий i2p-hackers/i2p.i2p:

Затем присоедините к своему экаунту.

Third: Set up your git client tunnel

Чтобы иметь доступ на чтение и запись к моему серверу, вам потребуется настроить туннель для вашего SSH-клиента. В качестве примера мы будем использовать HTTP-туннель, но если вам нужно только чтение, клонирование по HTTP/S, то вы можете пропустить все это и просто использовать переменную окружения http_proxy, чтобы настроить git на использование предварительно настроенного I2P HTTP Proxy. Например:

http_proxy=http://localhost:4444 git clone http://gittest.i2p/i2p-developer/i2p.i2p

Затем добавьте адрес, с которого вы будете пушать и пулить. Обратите внимание, что этот пример адреса предназначен для клонирования по протоколу Read-Only HTTP-over-I2P, если ваш администратор не разрешает протокол git HTTP(Smart HTTP), то вам нужно будет получить от него SSH клон base32. Если у вас есть SSH клон base32, замените его на base32 в этом шаге, что приведет к неудаче.

Выберите порт, на который локально будет перенаправлена служба I2P.

Я часто использую его, поэтому запускаю клиентский туннель автоматически, но это зависит от вас.

Когда все будет готово, это должно выглядеть примерно так.

Четвертое: Попытка клонирования

Теперь ваш туннель настроен, и вы можете попытаться сделать клон по SSH.

Конфиденциальность Git: Коммит в git добавляет метку времени в сообщения коммита git, которая может быть настроена так, чтобы отражать ваш локальный часовой пояс. Чтобы обеспечить использование UTC для всех коммитов, рекомендуется использовать псевдоним git, например:

git config --global alias.utccommit '!git commit --date="$(date --utc +%Y-%m-%dT%H:%M:%S%z)"'

что позволит вам заменить

git commit

для

git utccommit

чтобы скрыть ваш местный часовой пояс.

GIT_SSH_COMMAND="ssh -p 7442" \
    git clone git@127.0.0.1:i2p-developer/i2p.i2p

Вы можете получить ошибку, когда удаленный конец неожиданно зависнет. К сожалению, git до сих пор не поддерживает возобновляемое клонирование. Пока это не сделано, есть несколько довольно простых способов справиться с этим. Первый и самый простой - попытаться клонировать на небольшую глубину:

GIT_SSH_COMMAND="ssh -p 7442" \
    git clone --depth 1 git@127.0.0.1:i2p-developer/i2p.i2p

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

git fetch --unshallow

На данный момент у вас еще нет всех ветвей. Вы можете получить их, выполнив следующие команды:

git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch origin

Что указывает git изменить конфигурацию репозитория так, чтобы при выборке из origin были найдены все ветви.

Если это не сработает, можно попробовать открыть меню конфигурации туннелей и добавить несколько резервных туннелей.

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

Предлагаемая схема работы для разработчиков!

Контроль правок может облегчить вам жизнь, но лучше всего он работает, если вы используете его правильно! В свете этого, мы настоятельно рекомендуем использовать рабочий процесс fork-first, feature-branch, с которым многие знакомы по Github. В таком рабочем процессе мастер-ветка используется как своего рода "ствол" для обновлений и никогда не трогается программистом, вместо этого все изменения в мастер сливаются из веток. Чтобы настроить рабочее пространство для этого, выполните следующие шаги:

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

Установите второй пульт в локальном репозитории, используя исходный код из восходящего потока.
```
git remote add upstream git@127.0.0.1:i2p-hackers/i2p.i2p
```
Перетяните все изменения, внесенные выше, на свой текущий мастер:
```
git pull upstream master
```
Прежде чем вносить какие-либо изменения в исходный код, проверьте новую ветку функций для разработки:
```
git checkout -b feature-branch-name
```
Когда вы закончите работу над изменениями, зафиксируйте их и перенесите в свою ветку
```
git commit -am "I added an awesome feature!"
git push origin feature-branch-name
```
Отправьте запрос на слияние. Когда запрос на слияние будет одобрен и внесен в восходящий мастер, проверьте мастер локально и внесите изменения:
```
git checkout master
git pull upstream master
```
При внесении изменений в мастер-версию (i2p-hackers/i2p.i2p) вы можете обновить свой мастер-код, используя эту процедуру.
```
git checkout master
git pull upstream master
```

Решение проблемы временной метки git utccommit alias было найдено на основе информации, впервые опубликованной здесь: saebamini.com.