Есть ли способ конфликтовать слияния прошлых коммитов одной ветви? - PullRequest
Новая
       57

Есть ли способ конфликтовать слияния прошлых коммитов одной ветви?

1 голос
/ 07 мая 2019

Итак, вот сделка:

Был файл домашнего задания, над которым я работал.Я checkout ввел репо в школьный компьютер и добавил комментарии к этому репо.Но прежде, чем объединить комментарии, я внес изменения в часть моего исходного кода.Когда я объединил две ветви, я использовал git checkout --ours, когда я должен был сохранить измененную часть ветви A и часть комментариев из ветви B. Что еще хуже, я даже сделал больше изменений после объединения.

Таким образом, все прошло по сути так: 

Source code          Source code  
-----------          ----------- 
Part A         ->    Part A Change source         
-----------          -----------  
Part B               Part B         
-----------          -----------   

                     Source code  
                     ----------- 
               ->    Part A         
                     -----------  
                     Part B Comments         
                     -----------

Это должно было слиться в 

Source code        
-----------        
Part A Change source  And then More changes      
-----------          
Part B Comments                
-----------

Но оно стало 

Source code        
-----------        
Part A Change source  And then more changes    
-----------          
Part B                 
-----------

Теперь я попытался создать конфликт слиянияна git merge 6883dbbb (тег комментария) Но это показало 

Already up to date.

Я видел много ответов, предлагающих проверить ветку.Тем не менее, я хочу частичное обращение одного файла.Поскольку я добавил (и хочу сохранить) больше изменений после первоначального слияния, я не могу оформить заказ до точки слияния.Есть ли предложения по этой проблеме?Благодарю.

| *   commit 4a51c9ac25e88f29b57d345ec294413e0969f1b6
| |\  Merge: 98b00f5 688a3db
| | | Author: 
| | | Date:   Tue May 7 00:51:21 2019 +0900
| | | 
| | |     complete merge
| | | 
| | * commit 688a3dbbbf7dab71703bb3107f0d4451cf85da88
| | | Author: 
| | | Date:   Sun May 5 03:02:39 2019 +0900
| | | 
| | |     HW4 report initial finish part 1 & comments
| | | 
| * | commit 98b00f5db8844251b13dc98ac5d6314d4fc4180f
| | | Author: 
| | | Date:   Tue May 7 00:39:35 2019 +0900
| | | 
| | |     confirm everything works
| | | 
| * | commit a89a77a64336dad49d124a2e8470b84764b9660d
| | | Author:  
| | | Date:   Sun May 5 17:08:26 2019 +0900
| | | 
| | |     move testcase
| | | 
| * | commit 40c4977a813088c910c54002cd9ca56eb880f722
| |/  Author: 
| |   Date:   Sun May 5 17:07:01 2019 +0900
| |   
| |       fix bubble
| |

Ответы [ 2 ]

1 голос
/ 07 мая 2019

То, что у вас есть, эффективно так же, как если бы вы слились, а затем отменили слияние.То есть git считает, что коммиты на ветке "учтены", но изменения отменены.(Разница в том, что само слияние отменяет изменения, а не последующую фиксацию, но эффект тот же.)

Чтобы исправить эту ситуацию, вам необходимо создать новые коммиты, которые имитируют изменения в ветви.Самый простой способ сделать это с помощью git rebase -f.

Единственный недостаток в том, что вам нужно определить коммит, в котором ваша ветвь отклоняется от master (или какой бы ни была ветка "выше по течению"; мы будем говорить master ради обсуждения) - и«очевидные» способы сделать это (например, merge-base) не будут работать так, как вы могли бы ожидать, поскольку вся ветвь теперь доступна с master.Но если вы знаете, что это всего лишь один коммит, это достаточно просто: 

git checkout branch
git rebase -f HEAD^

Теперь вы можете объединить branch снова.

0 голосов
/ 07 мая 2019

Я бы просто вручную пересоздал коммит с комментариями: 

git format-patch 6883dbbb --stdout | patch -p1
git commit -a -m 'Re-applied comments commit'
...