Ручное закрытие запроса на битбакет - программирование
Подтвердить что ты не робот

Ручное закрытие запроса на битбакет

Мой вопрос

Я делаю так:

git clone
git checkout -b new_feature
< work and commit >
git rebase master
< work and commit >
< finish working >
git rebase master
git push origin new_feature
< I create pull request via bitbucket web interface >

Кто-то, кто просматривает изменения, делает:

git pull
git checkout master
git merge --squash new_feature
git push origin master

Я надеялся, что это закроет запрос на тягу, как принято, но это не так, что я пропустил?

Некоторая справочная информация

Я прочитал много документации по битбакету, "работая с запросами на pull", но это все еще не ясно для меня.

Я вижу, что все мои коммиты из ветки new_feature были применены к ветке master (через git merge --squash), и я могу видеть, какие файлы были изменены, но теперь, когда я нажимаю "слияние" на битбакете -request interface У меня есть еще одна фиксация в master, которая является слиянием, и это не изменяет никаких файлов (все изменения уже были применены предыдущим git merge --squash), но просто переносит все эти события в master, что не то, что я хотел.

Через: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

Вручную отправляет запросы в локальную систему

Иногда рекомендуется использовать рабочий процесс, где вы проверяете в вашей локальной системе, прежде чем принимать запрос на вытягивание. Вы может сделать это с любым запросом на тяну. Типичный рабочий процесс: Получите запрос на вытягивание в Bitbucket. Обновите локальный репозиторий входящий набор изменений. Исследуйте и/или проверяйте набор изменений. если ты набор изменений хорош, вы объедините его в свой локальный репозиторий. Вы возможно, придется разрешить некоторые конфликты. Затем вы нажимаете на локальный хранилище обратно в Bitbucket. Назад на Bitbucket, запрос на вытягивание отмеченные как принятые на вкладке "Запросы на поиск". Если вам не нравится изменить запрос, вы отмените изменения локально и отклоните попытку запрос на Bitbucket. Идеи?

4b9b3361

Ответ 1

ОБНОВИТЬ

По состоянию на 31 января 2017 года была реализована функция для устранения невозможности вручную закрыть PR.

Более подробную информацию см. В (и upvote!) Ответе @BenAmos.


Оригинальный ответ

(хранится в исторических целях)

Вы ничего не пропустили. Bitbucket автоматически не закрывает запрос на извлечение при его объединении.

Вы должны вручную закрыть запрос на вытягивание самостоятельно, выбрав опцию "Отклонить".

enter image description here

Ответ 2

Насколько я понимаю, есть два способа закрыть запрос на извлечение Bitbucket как "Объединенный".

  1. Нажмите кнопку "Объединить". Bitbucket объединит вашу ветку функций в ветку назначения. (Более новые версии Bitbucket позволяют выбирать между --no-ff и --squash. Старые версии неявно используют -no-ff.)
  2. Используйте команды консоли git (или другой интерфейс), чтобы объединить ветвь вашей функции в свою ветку назначения, а затем нажмите оба на начало координат.

Первый вариант, безусловно, самый простой и простой, но он не очень хорошо работает с определенными рабочими процессами разработки.

Ключом к получению второго варианта работы является то, что ваша ветка функций должна находиться в вашей ветке назначения. Bitbucket периодически проверяет запросы на загрузку, которые были объединены вручную, и, когда они найдены, автоматически маркирует эти запросы на перенос как объединенные. Примечание. Atlassian не рекламирует это поведение. Я не смог найти официальную документацию, подтверждающую эту претензию, но по крайней мере один другой человек видел ее работу.

На основе описанного вами рабочего процесса я предполагаю, что человек, который рассмотрел и нажал ваши изменения, имеет историю git, которая выглядит примерно так:

*   ddddddd (origin/master, master) new feature, squashed
| * ccccccc (origin/new_feature, new_feature) new feature part C
| * bbbbbbb new feature part B
| * aaaaaaa new feature part A
|/
o

В этом случае самым простым способом автоматического закрытия Bitbucket запроса на вытягивание будет:

git branch --force new_feature ddddddd
git push --force origin new_feature

Это также работает для веток функций, которые были переустановлены.

ПРЕДУПРЕЖДЕНИЕ! Помните об этих фактах:

  • Не все рабочие процессы допускают подобные усилия.
  • Bitbucket автоматически обновляет коммиты, отображаемые с помощью запроса на извлечение, когда изменяется его ветвь. В зависимости от порядка, в котором вы нажимаете свои ветки, это может привести к пустым спискам фиксаций. (Подробнее об этом ниже.)
  • Когда запрос на перенос закрыт, любая информация о фиксации и информация о различиях блокируются.

Когда вы нажимаете свою ветку назначения на начало координат до того, как вы нажмете ветвь своей функции, Bitbucket сначала ищет любые фиксации в ветке добавленной функции, которые не находятся в ветке назначения. Поскольку новая ветвь функции является предком ветки назначения, результат пуст. Поэтому Bitbucket удаляет все коммиты с вкладки фиксации запроса pull, который теперь читает: "Нет изменений". Затем, поскольку ветвь функции находится в истории ветвей адресата, Bitbucket закрывает запрос на извлечение, замораживая вкладку свободных фиксаций так:

There are no changes.

Любопытно, что в этом случае diff остается неповрежденным.

Если ни один из вышеперечисленных вариантов слияния не работает для вас, ваши оставшиеся опции:

  • Отклоните запрос на извлечение.
  • Подумайте о том, чтобы сменить рабочий процесс на то, что Bitbucket легче поддерживает.
  • Поплавьте запрос функции с Bitbucket/Atlassian.

См. Также документацию для git-branch и git-push.

Ответ 3

BitBucket Server 4.5.1 изменил, как удаленные слияния классифицируются в запросе pull (т.е. отклонены или объединены).

Ответ @BenAmos выше работает хорошо, но если вы нажмете фиксацию слияния на ветку назначения, прежде чем принудительно нажать на ветвь функции, BitBucket автоматически закрывает запрос на перенос и классифицирует его как "отклоненный".

Однако, если вы вместо этого надавите на ветвь функции, прежде чем нажимать фиксацию слияния на ветку назначения, BitBucket автоматически закрывает запрос на перенос и классифицирует его как "объединенный".

От атласа: "Запрос на перенос теперь будет отклонен после нажатия, если: нет никаких коммитов на ветке, которые также не находятся на ветке, а ветка не обновлена ​​в том же нажатии"

Ссылка: https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841

Ответ 4

Я думаю, битбакет не распознает ваш PR как объединенный, потому что git merge --squash создает полностью новый фиксатор. В нашей компании мы также пробовали ветки git merge --squash, когда объединили их в основную ветвь, но отказались от нее, потому что объёмные запросы были объединены таким образом, и нам нужно было "отменить" их или удалить связанные ветки удаленных функций.

То, что мы делаем в настоящее время, это раздавить всю ветвь функции в одном и принудительно надавить на удаленный филиал. После этого лицу, ответственному за слияние с мастером, просто нужно щелкнуть "Слияние" на странице запроса на битбакет, и это все, PR отмечен "Объединенный", и все изменения, внесенные в ветвь функции, передаются в одну опрятную фиксацию.