Git: Как сделать "rebase on the master" при открытом Pull Request'е?
 

На самом деле два вопроса:
1) Работаю я над фичей какой-нибудь. Долго работаю. В это время master меняется. Как исключить конфликты при pull request'е?

2) Что делать если pull request уже отправлен и возник конфликт?

Нужно следить за тем чтобы твоя ветка была всегда актуальной.

Ручное или интерактивное разрешение конфликтов

Как это сделать таким образом, чтобы в историю коммитов не попала лишняя шняга? Если я делаю периодический merge то появляются же нежелательные коммиты.

Меня просит исправить ситуацию владелец резитория, куда я отправил запрос на слияние. Что конкретно я должен сделать? Придется ли пересоздавать pull request, если необходима история без левых коммитов?

Следуй общепринятому воркфлоу.

Еще раз:

1. Делаешь форк репозитория (если речь идет о гитхабе)
2. Клонируешь репозиторий:

git clone --recursive ....

3. Добавляешь алиас для удаленного репозитория:

git remote add fork ....

4. Подтягиваешь изменения из удаленного репозитория:

git pull fork master

По-умолчанию в pull'e используется флаг --no-ff и автокоммит, так что все по-честному.
Но если есть желание поиграться с ребейсом, можно заюзать --rebase

Если не хочешь делать автокоммит, то сделай все вручную:

git fetch fork master
git merge foo --no-commit --no-ff

5. Обнови все сабмодули (если нужно):

git pull --recurse-submodules && git submodule update --recursive

Или так (если нужно обновить только сабмодули):

git submodule foreach --recursive git submodule update --init

6. Создаешь свою ветку:

git checkout -b foo

7. Вносишь свои изменения
8. Обновляешь тесты.
9. Запускаешь тесты (в большинстве случаев, для JS-репозиториев нужно выполнить команду grunt)
10. Делаешь коммит:

git commit -am ...

11. Отправляешь свои изменения:

git push fork foo

PS: желательно чтобы коммит был не в мастер, чтобы владелец репозитория мог поправить историю и выкатить релиз (git tag).

Я правильно понимаю что сейчас, когда pull request уже открыт, у меня всего два варианта:
1) «git merge foo --no-commit --no-ff», поправить конфликт и закоммитить фикс.
2) Закрыть pull request, сделать rebase или чего-то там, чтобы моя feature ветка получила все последние изменения из master, но чтобы это не отразилось на истории коммитов (раньше я для этого тупо создавал новую ветку feature_new, основанную на свежем master'е, и делал cherry-pick коммитов из feature). Затем открыть новый Pull Request.

Оба варианта не очень нравятся, но как я понимаю никакого третьего магического варианта нет, так что придется выбирать из этих двух?

Только

git fetch fork foo
git merge foo --no-commit --no-ff

Еще можешь сделать:

git push --force --verbose origin master

и тогда все должно уйти одним коммитом, т.е. твои предыдущие будут объединены.

Если же ты хочешь чтобы никто не видел твоей "песочницы", то используй:

git merge --squash

А если я сделаю git push origin feature --force, то что станется с Pull Request'ом? Он автоматически закроется (как при удалении ветки)?

C чего это?

Каждый твой push будет отражаться в истории пул-реквеста, а с форсом все уйдет как один