u22-26egorov/up: Учебный процесс

1.3 Работа с чужим репозиторием

В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Немного о моделях совместной разработки

На GitHub популярны две модели совместной разработки: Модель «Fork + Pull» позволяет любому склонировать (fork) существующий репозиторий и сливать изменения в свой личный fork без необходимости иметь доступ к оригинальному репозиторию. Затем, изменения должны быть включены в исходный репозиторий его хозяином. Эта модель уменьшает количество телодвижений для новых contributors и популярна для open source проектов, так как позволяет людям работать независимо, без единого координирования.

Модель «общего репозитория» (The Shared Repository Model) чаще встречается у малых команд и организаций, работающих над закрытыми проектами. Каждый в команде имеет доступ «на запись» в один общий репозиторий, а для изолирования изменений применяются тематические ветви (topic branches).

Pull request'ы особенно полезны в модели «Fork + Pull», поскольку предоставляют способ уведомить мэйнтэйнеров проекта (т.е. хозяина оригинального репозитория) о изменениях в вашей копии репозитория. Впрочем, они так же полезны и в модели общего репозитория, где обычно используются для того, чтобы инициировать пересмотр или обсуждение кода перед тем, как включать его в основную ветвь разработки.

Делаем копию репозитория

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

В рамках руководства, будем считать, что мы работаем над репозиторием FileManager пользователя Kartohez (Деев К., 36 гр.), а ваше имя пользователя — ypv.

Делаем форк (свою копию / ветвь чужого проекта):

Теперь он появляется у Вас отдельным репозиторием:

Создаем отдельный локальный каталог для этого проекта:

Копируем свой репозиторий на свой компьютер

git clone http://213.155.192.79:3001/ypv/FileManager.git

Обратите внимание на структуру каталогов, каталог .git находится в склонированном проекте. И в дальнейшем необходимо вводить команды именно в нем. Т.е. на уровень ниже.

Добавляем привязку к чужому репозиторию

Склонированный репозиторий имеет одну привязку к удалённому репозиторию, названную origin, которая указывает на вашу копию на Gogs, а не на оригинальный репозиторий. Чтобы отслеживать изменения и в нём, вам нужно будет добавить другую привязку, названную, например, upstream:

git remote add upstream http://213.155.192.79:3001/Kartohez/FileManager.git

git fetch upstream

Работаем над проектом

Теперь творите добро (и пусть оно будет выражаться в коммитах). Например, добавим фиксированную границу для Form1:

Коммитим изменения:

Отправляем в СВОЙ репозиторий (origin). Сразу проверяем, что push прошел и в нашем репозитории коммит отобразился:

Отправляем pull request (запрос на слияние нашего репозитория и оригинального)

Идите на страницу вашей копии репозитория на Gogs и жмите кнопку Pull Request:

Далее вы попадёте на предпросмотровую страницу, на которой сможете ввести название и описание ваших изменений (название потом попадёт в описание мёрдж-коммита и станет достоянием общественности, учтите это). Там же вы можете посмотреть, какие коммиты попали в пулл реквест, а так же общий diff всех изменений в пулл реквесте: