GitHub Resolve Conflicts Lost Commit History

Question

Это когда-нибудь случилось с тобой?

Наша команда разработчиков недавно перевела нашу кодовую базу & в GitHub вместо использования GitLab. Наша установка ветвь выглядит следующим образом:

1. Мастер
2. Балетмейстер
3. Развитие
4. Индивидуальное отделение 1 [будет называться branch1 на этот вопрос]
5. Индивидуальное отделение 2 [будет называться branch2 для этого вопрос]
6. Отдельная ветка 3 [будет называться веткой3 для этого вопроса]
7. и т.д.

У нас была ситуация, когда отрасль 1 закончила разработку того, что у них было, но слияние с ветвью развития на ветку1 перед слиянием в развитие. Он обнаружил, что существуют конфликты слияния, поэтому я использовал кнопку «Разрешить конфликты» GitHub (которая отправила меня на свой удобный веб-инструмент для конфликтов ... см. Здесь https://help.github.com/articles/resolving-a-merge-conflict-on-github/). После того, как конфликты были совершены, он открыл запрос на перенос от ветки 1 до разработки, который должен быть рассмотрен до слияния. Мы заметили, что все его истории совершения и изменения кода произошли до того, как конфликт ручного слияния исчез, и не было возможности просмотреть его изменения. Незнакомец по-прежнему состоит в том, что его код, похоже, уже был объединен в «Развитие», но история этого не происходила, поэтому мы не знаем, как это произошло.

У нас была аналогичная ситуация с branch2. Были конфликты при слиянии с Development на branch2, использовался инструмент слияния GitHub и вся история изменений и изменений кода исчезла. Однако ни один из кодов случайно не был объединен с Development.

ветвь3 также имела конфликты слияния, но использовала командную строку (GitBash) для разрешения этих конфликтов, и история фиксации все еще существовала, когда он был готов слиться с Development.

Могли ли проблемы, которые у нас были с веткой 1 и веткой2, связаны с инструментом слияния через GitHub? Google не слишком полезно ..

спасибо :)

Answer 1

Это вызвано ступеньками, когда ты сливаться и тянуть запрос. Запрос на вытягивание (PR) должен превышать слияние. Цель PR заключается в том, чтобы позволить другим просматривать слияние перед тем, как он действительно выполняется. Если вы хотите объединить branch1 в ветку разработки, вы можете создать запрос на растяжение на основе ветви Development и сравнить branch1. После одобрения PR, поэтому branch1 может объединиться в ветку разработки.

Шаг слияния с разработки на ветку1 не нужен или вреден, если вы сливаете его слияние branch1 в Development. Мы можем проиллюстрировать ниже графике:

A---B---C  branch1 
    \ 
     D---E  Development 

После развития слияния с branch1

A---B---C---F branch1 
    \ /
     D---E  Development 

После слияния филиала 1 в отрасли развития, это только вызвало ветвь 1 и Разработайте точку фиксации. Это быстрое слияние.

A---B---C---F branch1, Development 
    \ /
     D---E  

Так что вам нужно только объединить branch1 в отрасли развития, график должен быть

A---B---D---E--- F’  branch1 
    \  /
     ----C----  Development 

Для восстановления вашей branch1 и развития в статусе до того worongly слияния (commitC и Е отдельно) необходимо ниже команд:

git checkout branch1 
git reset --hard <commit id for C> 
git checkout Development 
git reset --hard <commit id for E>