Перебазирование с раздавливанием во время запроса на открытое извлечение - PullRequest
Новая
       31

Перебазирование с раздавливанием во время запроса на открытое извлечение

0 голосов
/ 27 июня 2018

МЕДВЕДЬ МНЕ, ЭТО ДОЛГО

Введение

Существует открытый запрос извлечения из ветви working-branch в ветку development, которая является одной из основных веток со следующими коммитами: 

Commit 1
Commit 2
Commit 3

Проверка кода

Теперь другой разработчик выбирает этот запрос на извлечение и проверяет код, затем он запрашивает изменения Commit 1 и Commit 3 для каждого примера.

Подход 1

Разработчик создает Commit 4, где реализована вся обратная связь, и отправляет ее в репозиторий, который, в свою очередь, появится в истории фиксации запроса на извлечение.

Недостатки , учитывая, что все больше и больше отзывов может применяться к запросу извлечения, тогда коммиты по фактическому PR будут выглядеть как 

Commit 1
Commit 2
Commit 3
Commit 4 (first round of feedback)
...
Commit n

Подход 2

Разработчик создает локально новые коммиты, например Commit 4 для действия запрашиваемых изменений и Commit 5 для изменения действия для Commit 3 (в противном случае фиксация 5 может даже не существовать, поскольку действия сначала запрашивают изменения для фиксации 3, а затем просто вносят в них изменения)

Новая структура (локально) выглядит следующим образом 

Commit 1
Commit 2
Commit 3
Commit 4 -> contains updates from PR for Commit 1
Commit 5 -> Contains updates from PR for Commit 3

Затем разработчик делает следующее git rebase HEAD~5 -i, которое выдает следующее 

pick 1111111 Commit 1
pick 2222222 Commit 2
pick 3333333 Commit 3
pick 4444444 Commit 4
pick 5555555 Commit 5

и сквош Commit 4 и Commit 5

pick 1111111 Commit 1
f 4444444 Commit 4
pick 2222222 Commit 2
pick 3333333 Commit 3
f 5555555 Commit 5

Который после перебазировки будет иметь 3 коммита в соответствии с первоначальным намерением.

Минусы

В случае, если другой разработчик разветвил вашу ветку, после этого ему / ей нужно перебазировать вашу ветку (это не будет недостатком, если разработчик знает, как выполнить этот вид перебазировки), когда хеши коммитов изменяются.

Плюсы

Лучшая прозрачность истории, где и что было реализовано. Более компактная история (без дополнительных коммитов с небольшими изменениями)

Вопрос

Какой подход вы практиковали, у вас другое мнение по поводу выше? По вашему мнению, что из вышеперечисленного лучше подобрать? Известны ли вам какие-либо внешние ссылки (официальная / неофициальная документация), в которых говорится, использовать тот или иной подход.

Заключение

Я лично (и наша внутренняя команда) работаю с Подходом 2.

...