Зафиксировать беспорядок в истории после раздавливания в master
У меня есть две ветки в репо: master и dev.
Состояние dev
- A - S1 - S2 - ... - SN - B - C
Состояние master
- A - S
Где S фиксация является результатом «сквоша и слияния» S1, ..., SN от dev до master.
Теперь, когда я сравниваю ветки, git показывает много изменений, но на самом деле это B и C.
- Как лучше всего синхронизировать ветки?
- Каков правильный рабочий процесс, чтобы избежать таких ситуаций?
Об общих вопросах: если вы не знаете, что делаете, раздавливание и слияние не будут работать, если вы хотите иметь какую-то связь между ветвями, потому что git нет может видеть, как ветки связаны между собой в прошлом A (потому что вы не создаете общую историю между ними). Для git S — это просто ревизия поверх A с никакого отношения к S1..SN.
Я столкнулся с проблемой, пытаясь объединить dev в main. Я сравнивать ветки как main...dev на github. Настоящие изменения в dev (помеченные как B - C в вопросах) совершает с 17 февраля (шесть последних коммитов в dev).
@eftshift0, я могу найти коммиты (B и C), которые на самом деле являются изменениями поверх S. Можно ли «отсоединить» -B-C цепочку и объединить в main только эту цепочку?
Вы можете выбрать B и C на main, но если dev — долгоживущая ветвь, лучше сделать обычное слияние. Сквош-слияния полезны для недолговечных ветвей, которые вы удаляете после слияния, а не для долгоживущих.
Ответы 1
Хорошо .... ваши комментарии объясняют, что происходит. Таким образом, github будет использовать тройные точки при выполнении сравнения. Итак, если бы вы попробовали git diff master..dev, вы бы увидели только то, что представили B и C. А вот github будет использовать master...dev (или наоборот, неважно). Попробуйте использовать git с тройной точкой, и вы увидите, что он также будет включать изменения, внесенные S, и это потому, что когда вы делаете master...dev, git не будет просто сравнивает master и dev. Сначала он найдет последнего общего предка между ними (A), а затем git diff A..dev, который будет включать изменения, внесенные S1..SN... то же самое, если вы попытались dev...master. В конечном итоге это сделает git diff A..master (что будет включать изменения от S). И это потому, что когда вы раздавили/слили, настоящего слияния не было.
Чтобы снова заставить это работать, нужно установить dev, чтобы B и C были поверх мастера Текущий:
git rebase --onto master SN dev
Это должно дать вам то, что вы хотите, но вы потеряете историю S1~..SN. Другим способом было бы правильно объединить это... но немного взломать, чтобы вам не пришлось переделывать себя (скажем, вам приходилось решать конфликты и прочее? Я не знаю.... Итак), вы можете попробовать это:
git commit-tree -p A -p SN -m "Merging S" S^{tree}
# this will create a new _merge_ revision having A and SN as parents
# the content of the files will be the same as S
# the command will print the ID of a revision
# take that revision ID and let's call it X
# branch dev can live on the way it is.... we just need to put master where X is
git checkout master # if you are not in master already
# make sure you have no changes uncommitted as the next command will destroy those changes
git reset --hard X
# now master is on top of X, the way it should have been
Теперь нет когда-нибудь еще раз попытается сжать/объединить если вы не знаете, что делаете.
Спасибо за продуктивный ответ и обсуждение!
После некоторого тестирования я придумал это решение, но заметил, что мой репозиторий небольшой и поддерживается в основном мной. Так. Локально я сделал ветку dev_local из dev и перебазировал локальную ветку как git rebase -r --onto master SN dev_local (-r вариант). Затем я создал удаленную ветку dev_new из master и слил локально dev_local в dev_new. После этого я удалил dev в репо и переименовал dev_new в dev.
как у тебя работает дифф?
git diff dev..master?git diff dev...master? Можете ли вы включить это в вопрос?