Git: Слить снова из предыдущей ветки

Question

Можно ли объединить предыдущую ветку и разрешить конфликты с текущей веткой?

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

Я подумал о том, чтобы отойти от современного мастера, засорять старые файлы в новой ветке работой коллеги, а затем вернуться из главы предыдущей ветки. В идеале я бы мог вручную подтвердить конфликты. Это будет иметь структуру вроде:

           o-------o-------o-------o
          /               /         \
         /               /           \
--------o---------------+-------------o----->

, где не было никаких изменений в исходной ветви в +, где я хочу слиться отсюда с новой веткой.

Когда я пытаюсь выполнить слияние с исходной веткой, я получаю сообщение «Все файлы обновлены».

EDIT: Фактическая структура правок немного отличается от изображения выше, она ближе к:

------A-----B--------+---->   dev branch
      |      \        \
      |       B'---C`--D-->   new branch with changes
      |
      A`----C                 changes made outside Git

где A` - копия проекта в A, B - изменения, которые я сделал в Git, C - изменения, сделанные моим коллегой вне Git, а C` - состояние ветви после того, как я скопировал его изменения. in. D - результирующее слияние с исходной веткой, в которой я хочу выбрать конфликты.

Однако вместо D я просто получаю C, без изменений. Я полагаю, что это может быть связано с тем, что состояние ветви при копировании равно B, и, следовательно, Git видит новые файлы как простой набор добавлений и удалений, и ничего сложного автоматически не разрешается.

Answer 1

Я нашел решение своей основной проблемы, не обязательно фактический механизм, который я искал, но это решение.

Проблема заключалась в том, что в то время, когда я создавал ветку для внешних изменений, я уже создал некоторый код. Git видел порядок изменений для нового кода как A---B---C, где он был на самом деле A----C. Но порядок изменений во время слияния выглядел бы как A---B---C---B (вместо A---C---B, который должен вызывать разрешение конфликта), и поэтому Git был весьма рад разрешить B-C-B как просто B-C.

Но на самом деле мне не нужно было переходить от главы первоначальной ветви разработки. Если вместо этого я создал новую ветвь из последнего коммита в ветку разработки, прежде чем сделал копию для отправки ему, и скопировал его изменения в эту ветвь, последующее объединение из ветки разработки будет правильно переносить изменения.

-----A---B-----+--->
     :\         \
     : A`---C`---D-->
     :
     A`---C

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

Answer 2

Вот процедура, которой нужно следовать:

1. Потяните свою основную ветвь (мастер).
2. создайте новую ветку из вашей основной ветки.
3. Скопируйте изменения ваших друзей или код в новую ветку.
4. Добавить и зафиксировать эти изменения.
5. Теперь перебазируйте вашу ветку с главной веткой, так что теперь вы получите все меняется с мастера на вашу ветку.
6. Теперь вы должны разрешать конфликты, если они у вас есть.
7. После разрешения конфликтов добавьте файлы и продолжите перебазирование.
8. Теперь вы получите изменения вашего друга и последний код основного филиала. к вашему коду.
9. Затем вы можете отправить свой код в новую ветку.

Вот код для всех шагов:

1. git pull origin master

2. git checkout -b friend_changes

3. Скопируйте изменения из другой папки в эту

4. git add -A; git commit -m "Firend changes"

5. git rebase -i master

6. Разрешение конфликтов, если таковые имеются

7. git add . ; git rebase --continue

8. Теперь вы получили все изменения здесь

9. git push origin friend_changes

Документация для git rebase

Другая ссылка