#git #github #merge #branching-and-merging
Вопрос:
Для моего текущего индивидуального проекта я делаю PR непосредственно на GitHub (а не на Bitbucket или Azure DevOps). Я хочу, чтобы мои две ветви показали, что они одинаковы после слияния, но я не нашел варианта слияния, который бы это сделал.
Коммиты слияния и коммиты сквоша не находятся в ветке функций, поэтому GitHub сообщает мне, что в целевой ветке есть «последние изменения», и призывает меня сделать PR, чтобы перенести их в мою исходную ветвь (откуда они пришли).
Я просто переключился на опцию перебазирования и объединил PR с четырьмя коммитами, но у этого тоже есть проблемы, так как коммиты имеют разные SHA. На GitHub по-прежнему говорится, что в целевой ветке произошли недавние изменения, и что у нее четыре коммита впереди и четыре позади, и эти коммиты вызывают конфликты для будущих PR.
Мне любопытно, неизбежно ли это при слиянии GitHub или если есть параметр или другая опция, которую я пропускаю.
Комментарии:
1. Являются ли эти 2 ветви долгоживущими ветвями? Если у вас есть
mainветвь , а затем недолговечные ветви функций/тем, которые ответвляются и объединяются обратноmain, вы можете просто удалить временные ветви после завершения слияния. Если они оба являются постоянными ветвями, какова цель второй ветви?2. @TTT, одна из них-ветвь версии с моей основной работой и функциями, а другая-ветвь интеграции, на основе которой GCP создает, когда обнаруживает изменения.
3. Вы принимаете на себя обязательства и по тому, и по другому, или вы только принимаете на себя обязательства, а затем продвигаете их ?
featuresintegrationЕсли вы иногда совершаетеintegrationтакже, то это утверждение не всегда возможно с помощью одного PR: «Я хочу, чтобы мои две ветви показали, что они одинаковы после слияния». Вам тоже пришлось бы развернуться и слиться обратно в другую сторону.4. Я фиксируюсь только на
v1, а затем объединяюсь сtestилиdeployветвями для тестовых или производственных сред. Таким образом, не будет двустороннего слияния, как вы описали.