Ru:PullRequest

О Pull Request'ах.

(эта статья недописана находится тут, а не в основной onPHP wiki, т.к. мне не хочется ее пихать в основную wiki недописанной). Если есть комментарии, предложения, пожелания по ней - пишите в личку :)

Статья состоит из 3-х частей:

1. Общие правила заведения и рассмотрения Pull Request'ов.
2. Описание-пример как создавать Pull Request и мержить его.
3. Небольшой обзор git с точки зрения как его представляю "я" и как с ним работать :)

Общие правила заведения и рассмотрения Pull Request'ов и процесса разработки

• Баги, фичи и любые иземения желательно выполнять через pull request.
• Pull Request должен заводиться на мастер версию и в первую очередь мержиться именно мастер. Далее, особенно если это багфикс, мержить в остальные ветки (сейчас это 1.0)
• И бага и фича должны покрываться тестами и при этом ни один из тестов не должен быть поломан.
• Если ломается BC (Back Compatability) или прекращается поддержка какой либо старой версии автору необходимо это указывать и предупреждать, что в свою очередь требует дополнительного обсуждения.
• Мерж в мастер делается если контрибьютеры не против данного изменения и обсуждение окончено. Если Pull Request создал один из контрибьютеров, то ему в конечном итоге и мержить изменение.

Описание-пример как создавать Pull Request и мержить его

Это описание workflow как работать с Pull Request'ами на github'е. В примере я буду использовать свой fork фреймворка: git@ github.com:AlexeyDsov/onphp-framework.git

• Если еще не сделали, то делаем fork проекта. После этого у вас появляется свой репозиторий по адресу.
• Выгружаем себе локально свой репозиторий, например так:

mkdir ~/onPHP-fork
cd ~/onPHP-fork
git clone [email protected]:AlexeyDsov/onphp-framework.git .

Теперь все последующие операции с репозиторием будем выполнять из папки ~/onPHP-fork

• Подключаем основной onphp-framework репозиторий, например так:

git remote add onphp-origin [email protected]:onPHP/onphp-framework.git
git remote update

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

git merge onphp-origin/master //выполняет слияние локального мастера с мастером из главного репозитория
git push origin master:master //отправляем обновление своего мастера на свой fork (тот который у меня AlexeyDsov)

• Теперь все готово что бы сделать бранч, например, myNewFeature в котором можно сделать feature:

git checkout -b myNewFeature

• Выполняем нужные правки и после этого коммитим изменения в локальный репозиторий:

git add file1 file2 file3
git commit -m 'implemented new feature myNewFeature'

• Когда сделаны все коммиты, то необходимо локальные изменения слить в свой форк. Таким образом там нужно тоже создать отдельную ветку под изменения:

git push origin myNewFeature:myNewFeature

• После этого заходим на github в свой форк во вкладку Network и кликаем на последний свой коммит в ветке myNewFeature. В этом жмем вверху-справа кнопочку Pull Request и заполняем после этого тему реквеста и описание, жмем кнопку Send Pull Request. Вот собственно Pull Request и создался. Если вдруг хочется сделать какие-либо правки в ветке и добавить коммит, то просто делаем правки, коммитим их в ту же ветку и опять пишем git push origin myNewFeature:myNewFeature. А github в Pull Request'е сам подтянет новые коммиты в ветке.
• Когда обсуждение успешно окончено и решено замержить Pull Request, то контрибьютер может нажать в реквесте кнопку Merge если merge не приводит к конфликтам. Если же merge приводит к конфликтам и невозможен в автоматическом режиме, то есть два способа решения:

1. Можно замержить мастер в myNewFeature, решить конфликт и далее безконфликтно замержить myNewFeature в master.

2. Можно просто замержить myNewFeature в мастер решив при этом конфликтю. Рассмотрю второй вариант. Пусть я контрибьютор и у меня под рукой нет выгруженного репозитория:

git clone [email protected]:AlexeyDsov/onphp-framework.git onPHP-fork //создает репозиторий и подключает к нему remote репозитория AlexeyDsov с именеме origin
cd onPHP-fork
git remote add onphp-origin [email protected]:onPHP/onphp-framework.git // подключаем главный onphp репозиторий и называем его onphp-origin
git checkout -b onphp-master -t onphp-origin/master //создаем локально бранч onphp-master следящий за веткой master из репозитория onphp-origin. При этом сразу и переключаемся на этот новый бранч.
git merge origin/myNewFeature //мержим из репозитория origin бранч myNewFeature и получаем конфликт
//дальше решаем конфликт либо через mergetool либо совсем ручками и коммитим все незакоммиченные файлы
//после этого push'им изменения в мастер главного репозитория:
git push onphp-origin onphp-master:master

Github этот мерж должен будет сам увидеть и автоматом закроет Pull Request под тем кто выполнял ручной merge.

Небольшой обзор git с точки зрения как его представляю "я" и как с ним работать :)

Здесь я отталкиваюсь от отличий с svn'ом и это скорее набор примечательных фактов которые я отмечаю(л) при работе с git'ом:

• В отличие от svn каждая папка созданная с помощью git clone сама по себе является полноценным репозиторием со всей историей коммитов.
• Для git в ubuntu есть хороший клиент просмотра дерева коммитов - sudo apt-get install gitg. И далее из корневой папки репозитория нужно его запустить: gitg&
• По моим ощущениям бранчи можно называть "указателями ветку" коммитов. Таким образом если какой-то бранч удаляется, то сам коммит еще остается в репозитории.
• Работа с внешними репозиториями это git remote. С помощью git remote add repositoryName repositoryUrl можно подключать новые репозитории, а дальше с помощью git remote update выкачивать обновления по ним полностью.
• Для создания локального бранча связанного с бранчем удаленного репозитория нужно писать git checkout -b newBranch01 -t remoteRep/newBranch Где newBranch01 - имя бранча в локальном репозитории, remoteRep - имя удаленного репозитория, а newBranch - имя бранча в удаленном репозитории.