Вызов запроса Github

У меня есть следующий сценарий:

  • Моя ветка по умолчанию Github "развивается"
  • У меня есть три запроса на растяжение для ветки "develop"
  • 3 запроса на вывод строятся и проверяются в порядке (на сервере CI)
  • тогда один запрос на перенос вручную объединяется для "разработки". '$ bumpversion --commit dev' выполняется автоматически, и версия создается и освобождается. Следовательно, все файлы, содержащие изменение версии, "развиваются" (.bumpversion.cfg, module/__ init __. Py)
  • пока все хорошо. Теперь из-за изменений в "разработке" оставшиеся два запроса на тягу становятся недействительными и больше не могут быть объединены через GUI Github. Мне нужно проверить ветку и слиться с "развиваться", как подробно описывает Анирудха.
  • Я не хочу, чтобы мои запросы на загрузку стали недействительными из-за изменений этих двух файлов.

Я уверен, что решение очевидно для экспертов git, которые знают, как это исправить. До сих пор я не мог найти его, поэтому, пожалуйста, поделитесь.

Ответ 1

Я предлагаю вам выполнить git rebase для этого сценария.

Git Rebase Official Doc

Что он делает, это проверка, которую вы указываете при выполнении rebase, скажем, у вас есть pr # 2 и pr # 3 в ожидании, вы клонируете репо и делаете, пока в ветке, которая сгенерировала PR,

git rebase develop

Он скажет, что rebase в prgress, поэтому вы идете и разрешаете конфликты в этом процессе и делаете

git add

Теперь rebase либо продолжается, либо останавливается, если больше конфликтов не существует. Если у вас есть, вы можете прочитать статус в терминале, продолжить,

git rebase --continue

Теперь сделайте это, пока не будут разрешены все конфликты.

И наконец, когда вы проверяете ветку для этого PR, вы должны увидеть, что нет конфликтов, и ветвь может быть автоматически объединена (явно нажав на удаленное репо).

Теперь повторите тот же процесс для pr # 3, и все готово.

Таким образом,

git rebase develop
git add <files>
git rebase --continue

повторите это также для pr # 3.

Ответ 2

Все, что вам нужно сделать, это checkout для этих запросов: git checkout PR1

вытащите последние изменения в ветке Развить. git pull origin develop

Просмотрите соответствующие изменения. и нажмите на свой PR. Удаленный PR-модуль git обновляется с новыми изменениями, и ваш CI также будет соответствующим образом одобрять.

Ответ 3

Вам следует рассмотреть возможность удаления информации о версии в вашем коде и только вставлять ее, когда вы действительно выпускаете или развертываете приложение.

Таким образом, ваш исходный код не становится грязным при продолжении изменений версии.

Конечно, вы хотите, чтобы git проверял изменения и сообщал вам, когда есть конфликты. Я предлагаю вам использовать альтернативное решение, чтобы конфликты не возникали, и слияние стало простым. (прочитайте всю мою почту, чтобы иметь полное решение)

Частичное решение в вашем случае

Вместо того, чтобы иметь определенную версию, имеется относительное число версий.

Что я имею в виду: есть файл с примечаниями к выпуску. и каждый раз, когда кто-то делает запрос на растяжение, он добавляет строку в этот файл. Файл будет выглядеть так:

1.0.0 Added a major breaking change
0.1.0 Added a feature
0.0.1 Added a bugfix
1.0.0 Another major change
0.0.1 Bugfix
0.0.1 Another bugfix

В релизе вы рассчитываете свою версию:

Предупреждения

  • для второго варианта: важно, в каком порядке вы принимаете запросы на pull. (может привести к разному номеру версии)
  • Возможно, git все же хочет объединить те же строки (вместо того, чтобы добавлять их друг под друга), что все еще приводит к конфликтам.

Преимущества

  • Больше не нужно беспокоиться о правильном номере версии
  • Имеются примечания к выпуску

Устранение конфликтов

Вместо того, чтобы помещать все примечания к версии в один файл: заставить людей писать заметку о версии для каждого файла, как в следующем синтаксисе: [yyyy-mm-dd] [1.0.0.0 (semVerFix)] [информационная заметка об изменении/исправление]

/\ Проблема в том, что управление версиями может оказаться неправильным, если вы принимаете новый запрос на перенос до более старого и продолжаете интеграцию в среднем времени.

Окончательное решение

В репозитории git.

есть папка с именем `/release-notes '

Если кто-либо изменяет изменение, файл должен быть добавлен здесь с указанием внесенных изменений (желательно, чтобы вы работали над одной функцией или исправлялись одновременно).

Этот файл имеет следующий формат [Дата] [Версия bump] [Описание]. [Дополнительное расширение файла] например: 2016-10-26 1.0.0.0 Added new versioning tooling.txt

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

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

Ответ 4

Если вы не можете переустановить эту ветвь PR наверху своей новой разработки (которая GitHub, предложенная недавно) из-за конфликтов, нормальный поток:

  • свяжитесь с автором PR
  • попросите его переустановить PR-филиал поверх извлеченного обновленного источника/разработки, разрешить конфликты, проверить, что все работает.
  • принудительно нажимаем ветвь PR (которая будет обновлять PR и будет запускать новый раунд сборки сервером CI).

В принципе, вам нужно убедиться, что автор PR делает всю тяжелую работу;) Все, что вам нужно сделать, это объединить или переустановить (без конфликтов), когда вы хотите интегрировать этот PR.

Ответ 5

Контроль версий должен выполняться через git, а не через файл внутри репозитория. Вместо bumpversion.cfg вы можете использовать теги для новых версий:

git tag 1.0.0 -m "Optional Description or release name."

и иметь файл изменений, который изменяется только bumpversion путем накопления заголовков фиксации.

Debian имеет расширение git, чтобы сделать все это автоматически:

git dch

Изменить: если вы хотите добавить версии автоматически, у вас может быть какое-то соглашение, чтобы добавить приращение в сообщение фиксации, в идеале, с помощью фиксации фиксации. git dch имеет опции для указания, какая версия должна быть увеличена кстати.