Git пул реквест всегда показывает проблему с коммитами
Я использую гитлаб. Мой вопрос касается запросов на извлечение. Я создал ветку "feature". В конце мы создаем запрос на включение в некоторую ветку «dev». Теперь проблема в том, что для одной и той же ветки «dev» будет выполняться «n» запросов на вытягивание. Итак, теперь, если кто-то объединил запрос на слияние какого-то другого человека в ветку «dev», тогда мне снова придется взять последнюю тягу, исправить конфликты, а затем снова зафиксировать и нажать, чтобы мой последний был добавлен в мой запрос на тягу.
Это похоже на блокировку битов, особенно если разработчик, который уходит в отпуск на пару дней, и его запрос на слияние никогда не будет объединен, поскольку его запрос на извлечение всегда отображается как «вы фиксируете за некоторым количеством коммитов».
Другая проблема заключается в следующем: тот, кому было поручено объединить этот запрос на включение, не может этого сделать, поскольку он зависит от разработчика, пока он снова не объединится с последним коммитом.
Итак, любое решение для этого? или это все делают то же самое, что упоминалось выше?
Вкратце: я столкнулся с этой проблемой: gitlab Запрос на слияние ветки A с разработкой (3 коммита позади), стоит ли мне беспокоиться?
@ bk2204 да, это проблема как для утверждающего, так и для разработчика. Поскольку утверждающий не может объединить его из-за «за коммитами», и разработчик должен всегда обновлять этот MR каждый раз, когда какие-либо новые коммиты добавляются в ветку dev. Как вы сказали, мы все еще можем объединиться, но действительно ли это разрешено и какой вариант запретить? и в случае слияния, что делать, если возникнут конфликты после слияния MR?
Если у вас есть возможность объединиться, то просто сделайте это. Ничего страшного, что он отстает на несколько коммитов, так как это происходит буквально постоянно на крупных проектах. Если есть конфликты, слияние будет невозможно.
@ bk2204 Что делать в случае конфликтов? (предположим, если вы являетесь утверждающим)
@ bk2204 bk2204 У меня был вопрос к вашему ответу .. не могли бы вы проверить ..
Ответы 1
В общем, нормально объединять ветку, если она отстает на несколько коммитов. Это очень распространено в любом проекте разумного размера, и слияние, как правило, будет идентично тому, когда оно перебазируется, а затем объединяется. Git предназначен для простой и надежной обработки этого случая.
Возможно, что некоторые проекты требуют, чтобы все ветки были обновлены перед слиянием, но если ваш проект не требует этого, то нет причин для беспокойства. Причина, по которой этот вывод существует, состоит в том, чтобы дать вам представление о том, насколько разошлись ветви. Если они сильно расходятся, то перебазирование может быть оправдано, потому что у вас больше шансов иметь логический конфликт, который не является текстовым конфликтом. Но если это всего несколько коммитов, я бы не стал напрягаться.
Невозможно объединиться, если есть конфликты. В таком случае обычно вы просите исходного отправителя перебазировать, потому что он написал код и лучше всего разбирается в устранении конфликтов. Как только это будет сделано, вы можете объединиться.
Если мы напрямую объединимся, игнорируя предупреждение «behind commits», то предположим, что в случае конфликта все конфликтные изменения объединяются в ветку dev, а затем тот, кто берет последние из dev, получает все конфликтующие файлы, верно?
Нет. Если есть конфликты, объединиться не получится. GitLab не должен позволять вам.
в порядке Хорошо. еще одно: в мерж-реквесте любой утверждающий сливается напрямую (даже если он показывает, что позади 2 коммита, например: miro.medium.com/max/1642/1*cgLb6Th7ZCha01oupEG4JA.png) или они попросить разработчика объединить dev с функцией и нажать, чтобы решить вышеуказанную проблему?
Если есть конфликты, разработчик должен перебазироваться на основную ветку и принудительно нажать на ту же ветку, которая обновит MR. Если конфликтов нет, то любой должен иметь возможность объединиться, если у него есть соответствующие разрешения.
Вызывает ли это практическую проблему для вас? Если ветка немного отстает от основной ветки, ее все равно можно объединить, если только у вас не включена опция, запрещающая это. Конфликты не должны быть обычным явлением в большинстве репозиториев.