Я создавал новые ветки Git из старых веток без проверки на мастер - PullRequest
0 голосов
/ 20 апреля 2020

Я проверял новые ветки из старой ветки, а не проверял мастера. В настоящее время я создал четыре новые функции: home_feature, admin_user-feature, customer_request, blog_feature.

Я забыл оформить заказ мастеру перед созданием ветви customer_request и создать эту функцию, перейдя в функцию блога. , сейчас я сталкиваюсь с множеством конфликтов. Я попытался использовать 'git rebase', но в коммитах до 80 коммитов на ветку, поэтому это не практично. Как я могу разрешить эти конфликты?

enter image description here

Ответы [ 2 ]

0 голосов
/ 21 апреля 2020

Из комментариев это оказалось решением. У вас было три ветви:

  • Мастер (M)
  • Старая ветвь функций (O)
  • Новая ветвь функций (N)

N был разветвлен O случайно, а не M, что вы и хотели. Это означает, что существует ряд коммитов, начинающихся в определенный момент времени в N, и вы хотите воссоздать ветвь с этими коммитами, как если бы вы разветвились от M.

Решением было создать новую ветвь :

  • Более новая ветвь функций (N2 из M)

Затем определите серию хэшей фиксации из N и примените их к N2. Вы можете сделать это вручную, выбирая каждую из них по очереди.

Существовал риск, что они не будут применяться корректно, потому что M мог изменить некоторые файлы по сравнению с O, и, следовательно, ваша работа в N могла бы был основан на устаревших файлах / папках. Слияние текстовых изменений - довольно простой алгоритм, он не понимает структуру кода, как это могут сделать люди (иными словами, не все можно объединить).

Однако, как оказалось, черри-пики применялись чисто. Если бы вы не смогли этого сделать, вам, возможно, пришлось бы создать diff для каждого сбойного и посмотреть, как применить его вручную к N2, учитывая изменения в M. Где это происходит, все равно стоит попытаться выберите следующие коммиты, так как не все из них нуждаются в ручном разрешении конфликтов.

0 голосов
/ 20 апреля 2020

Вы можете выполнить слияние и исправить конфликты только один раз, а не, возможно, несколько раз, как вам может потребоваться перебазировка.

Или вы можете позволить Git автоматически выбирать либо ваши изменения, либо изменения мастера изменяется при возникновении конфликтов.

Например, если вы выполняете ребазинг, вы можете добавить опцию ours (или theirs) в стратегию рекурсивного слияния.

Например, следующая команда переместит вашу ветку поверх мастера, и для любых конфликтов она выберет ваши изменения вместо изменений от мастера:

git rebase master -Xtheirs

theirs и ours в этом случае немного нелогичны. -Xtheirs выберет ваши изменения, а -Xours выберет изменения у мастера.

...