GIT - Перезапись кода ядра на отдельной ветке

Question

У меня есть такой сценарий, который я не считаю необычным, но я изо всех сил пытаюсь найти пример того, как это делается правильно в сети.

У нас есть наш проект с мастер-веткой. В моем примере можно сказать, что текущее состояние мастера идентифицирует v1.5.0 проекта.

Теперь мы решили написать v2.0.0, к которому произойдут массовые изменения и перезаписывания, файлы будут полностью удалены и удалены. Этот переписать теперь происходит на новой ветке, мы будем называть неустойчивой.

Неделя или около того в разработку по нестабильной функции и/или исправлению необходимо добавить в v1.5.0, без проблем мы говорим, что новая функция ветвления - запись - слияние с мастером. Мастер теперь находится в v1.6.0.

Теперь это исправление/функция не относится к новой версии проекта, так как весь проект переписывается.

Мы полный v2.0.0 на неустойчивой отрасли, которая первоначально была основана на v1.5.0 из мастера отрасли, которая сейчас находится в ... скажу версия 1.8.4 - как бы вы о слиянии нестабильной ветви с мастер-веткой без: разрушая историю версий от 1.5 до 1.8.4 или оставляя артефакты из версий до 2.0.0 в объединенной ветви и, возможно, нарушая новый код, написанный в версии 2.0.

Answer 1

Вы, наверное, уже знаете git merge -s ours, который делает именно противоположное тому, что вы хотите сделать: он игнорирует изменения в источника отрасли и позволяет в результате слияния точно совпадает с содержимым целевой отрасли. Не существует соответствующего -s theirs, хотя по причинам, по которым я не собираюсь входить сюда.

Итак, нам нужно будет импровизировать то, что имеет тот же эффект. Грубая схема: выполните слияние без фиксации, волшебным образом замените код 2.0.0 на него, а затем завершите слияние.

Прежде всего, убедитесь, что у вас нет незафиксированных изменений. Здесь мы будем использовать забавные трюки; гарантия недействительна и все такое.

1. сверху владелец, git merge -n unstable. -n будет уверен, что слияние еще не зафиксировано, даже если конфликтов нет (конечно, у вас появятся конфликты из-за обширной перезаписи, но давайте будем в безопасности).
2. это магия: git read-tree --reset -u unstable (читай unstable в индекс и обновить рабочее дерево соответственно, игнорируя любые конфликты)
3. git commit завершить слияние. Он будет иметь как старые, так и новые в своей истории , но только 2.0.0 в .
4. Убедитесь, что все это не оставило никаких остатков вашей предыдущей основной версии в качестве файлов без следа. Я не знаю наверняка, действительно ли это может произойти, но это не мешает проверить.

Answer 2

Это все о том, как обращаться с массивными расходящимися ветвями. Здесь есть несколько вариантов:

• merge: менее идеальный, так как вы получите много конфликтов, и если ядро ​​изменилось, будет сложно решить и убедиться, что все работает.
• handcraft: проверьте изменения, сделанные на master, так как unstable расходятся и перекодируют их. Это тот случай, когда вы понимаете, что расхождение между ветвями слишком велико, а слияние не имеет смысла. Тем не менее, вы все еще можете использовать вишневый захват, который все еще применяется. Вам лучше иметь отдельный отдельный трекер, в котором перечислены вещи, применяемые к master, так как разделение ветвей.

Обратите внимание, что rebase не является вариантом, потому что master ветка уже опубликована.

На боковой ноте очень интересный проект находится в бета-версии, но выглядит применимым: git-imerge. Этот проект позволяет объединить фиксации один за другим и решать конфликты, которые намного меньше.