Skip to content
Tags

,

Git и Github: работа с Pull Requests

02/09/2010

Если у Вас есть интересный проект на Github, рано или поздно другие пользователи захотят помочь Вам в его развитии. Совместная работа на github реализована достаточно просто: человек форкает Ваш репозиторий, вносит свои изменения и посылает Pull Request — запрос на внесение своих изменений в основной репозиторий (Ваш). Что после этого происходит, я и хочу описать.

Просмотр и обсуждение кода

Недавно Github представил новую систему pull request’ов — более продуманную и ориентированную на сотрудничество. Каждый запрос — начало дискуссии, обсуждения правок и кода. На разных страницах запроса можно увидеть и комментарии автора, и подсвеченный diff кода.

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

Слияние правок

Слияние делается в git, веб-интерфейса для этого не предусмотрено 🙂 Я покажу на примере слияния правок к репозиторию nodejs-docs-rus. Сначала надо переключиться в основную ветку (сохранив изменения в stash, если нужно) и создать удалённый источник:

git checkout master
git remote add Locke23rus git://github.com/Locke23rus/nodejs-docs-rus.git

Теперь репозиторий Locke23rus у нас подключен в качестве удалённого источника. Выкачаем его содержимое:

git fetch Locke23rus

Ветви удалённого репозитория будут показаны у нас в git branch -a. Делаем слияние нашей основной ветки и основной ветки Locke23rus:

git merge Locke23rus/master

И отправляем данные на сервер Github:

git push origin master

После этого pull request на сайте должен автоматически закрыться. Если этого не произошло, для закрытия есть специальная кнопка.

Патчи

Второй вариант — кто то присылает патч вместо pull request’а. У меня этим «кем то» был egorich239. С патчем всё тоже несложно.

Во-первых, чтобы пропатчить файл в Windows сам патч необходимо пересохранить с переносами строк, характерными для Windows (иначе утилита patch будет вылетать). Ещё одно: патч скорее всего создавался для файла который был до слияния других правок, поэтому просто поверх изменений Locke23rus он не встанет. Достаём из репозитория версию до слияния:

git log
# Здесь мы смотрим идентификатор нужного комита
git checkout -- a0ed79

Теперь у нас репозиторий указывает не на самый последний комит в основной ветке. Мы создадим для правок egorich’а новую ветку:

git checkout -b egorich239-patch

И теперь уже спокойно накладываем патч на исходный файл:

patch -f api.htm api.diff

В результате получится такая структура репозитория:

Верхняя ветка — наложенный патч от egorich, средняя — master, в которую уже залиты правки Locke23rus. Теперь можно переключаться в основную ветку и сливать туда правки egorich:

git checkout master
git merge egorich239-patch
git push origin master

Ссылки по теме

3 комментария
  1. Euthad permalink

    Помогите с работой.

  2. Эх, с нуля начать пользоваться гитхабом очень тяжело, всё это кажется грамотой с другой планеты 🙂 Зарегился, даже сделал и отправил публичный ключ… но пока не знаю как работать. Ищу статьи.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

%d такие блоггеры, как: