Git merge путают про пробелы внутри строки

Question

Недавно я столкнулся с действительно загадочной проблемой с Git при слиянии двух ветвей. Проблема возникла, когда авто-слияние попыталось объединить 2 файла, которые содержат «в основном» пробел, вставляя INSIDE строку. Для Exemple, посмотрите на этот файл после мерзавца слияния (или GIT Rebase):

<<<<<<< f03b9ee0db23cbe39ff231d8fcc3b37bac20cc3d¬                      
1 public static function findTopParent($tid, $domaine_tree) {¬     
2 =======¬                   
3 public static function findTopParent($tid,$domaine_tree) {¬      
4 >>>>>>> Version 8 - last extraction¬ 

(Обратите внимание на пробел после $ TID,) Цель этого «света» редактировать был только играть хорошо с Drupal кодирования конвенции (просить оставить пробел после комы в параметрах функции).

Я должен добавить, что это был один случай, когда merge left revision mark. Но есть много случаев, когда автоматическое слияние работает без ошибок, но делает ужасную работу по объединению файлов с куском кода сверху (без пространства внутри) и фрагментом кода ниже (с пробелом)

Но запустив мое обычное git-объединение без особого предупреждения или ошибок, мой сайт перестает работать со всеми типами ошибок переопределения функций. Открыв файлы, я увидел, что фрагменты кода повторяются повсюду, оригинальный код выше и «новый» код с косой минутой в функциях ниже. Так что, черт возьми ????? Почему простая модификация, подобная этой, интерпретируется Git как новая строка или, что еще хуже, новые куски кода?

Я измотал то, что меняются повсюду на пару дней, и теперь у меня очень плохое время, сливаясь с моей основной веткой. И теперь я как бы напуган, чтобы сделать это «маленькое» изменение в моих файлах, опасаясь создания причудливых ошибок, скрывающихся в реплицируемом коде. Я проверяю git merge doc, но только нахожу пробельные проблемы, связанные с пространством в конце строки, началом строки (вместо вкладок) или пробелами для табуляции (core.whitespace). Но ничего о проблеме с пространством не добавлено INSIDE. :-(нужны свежие глаза на это

EDIT:.

Чтобы быть ясным и легче понять здесь один отрывок из реального файла, до и после

В мастер перед слиянием:

// Menu Link MLID des pages HUB (statiques) du main-menu 
// Requête BD : SELECT * FROM menu_links where plid = 999 
// 726 = Loi et Réglements 
// 728 = Aide financière de dernier recours 
define ('LOI_AIDE_PAGE_MLID',934); 
define ('REGLEMENT_PAGE_MLID',935); 
define ('AFDR_PAGE_MLID',894); 

// Taxonomy VID 
define ('DOMAINE_VID',3); 

в особенности перед слиянием (обратите внимание на дополнительное пространство после комы):

// Menu Link MLID des pages HUB (statiques) du main-menu 
// Requête BD : SELECT * FROM menu_links where plid = 999 
// 726 = Loi et Réglements 
// 728 = Aide financière de dernier recours 
define ('LOI_AIDE_PAGE_MLID', 934); 
define ('REGLEMENT_PAGE_MLID', 935); 
define ('AFDR_PAGE_MLID', 894); 

// Taxonomy VID 
define ('DOMAINE_VID', 3); 

Затем в отделении:

git commit "blablabla" 
git pull --rebase origin master (no message, everythings look cool) 
git checkout master 
git merge feature (fast-forward, no message) 
... 
run the site... error duplicate constant !?!? 

открытые файлы и теперь это!?!

// Menu Link MLID des pages HUB (statiques) du main-menu 
// Requête BD : SELECT * FROM menu_links where plid = 999 
// 726 = Loi et Réglements 
// 728 = Aide financière de dernier recours 
define ('LOI_AIDE_PAGE_MLID',934); 
define ('REGLEMENT_PAGE_MLID',935); 
define ('AFDR_PAGE_MLID',894); 

// Taxonomy VID 
define ('DOMAINE_VID',3); 

// Menu Link MLID des pages HUB (statiques) du main-menu 
// Requête BD : SELECT * FROM menu_links where plid = 999 
// 726 = Loi et Réglements 
// 728 = Aide financière de dernier recours 
define ('LOI_AIDE_PAGE_MLID', 934); 
define ('REGLEMENT_PAGE_MLID', 935); 
define ('AFDR_PAGE_MLID', 894); 

// Taxonomy VID 
define ('DOMAINE_VID', 3); 

А также найдено файла с меткой пересмотра, но изменение также является лишь ОДНОЙ пробелом.

Answer 1

У вас конфликт слияния. Это нормально и будет происходить время от времени. Именно тогда две ветки изменили одну и ту же строку (или соседние строки), чтобы компьютер не знал, какой из них использовать. Это может вызвать даже небольшое изменение пробела.

Вы говорите, что вы сделали что-то вроде этого:

git checkout -b feature 
...work commit work commit... 
git checkout master 
git merge feature 

Но это не может привести к конфликту, потому что слияния master никогда не изменял. Я думаю, вы сделали это ...

git checkout -b feature 
...make some commits on feature... 
git checkout master 
...make some commits on master (or maybe a pull)... 
git checkout feature 
...make some more commits on feature... 
git checkout master 
git merge feature 

Обычно, когда вы объединяете Git, оно автоматически и фиксирует изменение. На этот раз автоматическое слияние не удалось, и вы столкнулись с конфликтом слияния. Никакой фиксации не произошло. Гит сделал все возможное, чтобы отредактировать и добавить код, а затем поднял руки, сказав «помощь, мне нужен человек!». и оставил вас иметь дело с остальными.

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

Неустановленные файлы будут иметь маркеры конфликтов, показывающие, какие линии конфликтуют между двумя ветвями. Вот и все.

<<<<<<< f03b9ee0db23cbe39ff231d8fcc3b37bac20cc3d¬                      
1 public static function findTopParent($tid, $domaine_tree) {¬     
2 =======¬                  
3 public static function findTopParent($tid,$domaine_tree) {¬      
4 >>>>>>> Version 8 - last extraction¬ 

Вы должны решить, какую версию этой линии вы собираетесь выбрать, или вы можете переписать строку целиком. Первый - от фиксации f03b9ee0, второй - от ветки Version 8. Просто удалите все элементы маркера конфликта и версию строки, которую вы не хотите. Или напишите новую строку.

public static function findTopParent($tid, $domaine_tree) { 

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

После того, как вы сделали это для всех конфликтов в файле, git add файла.

Повторяйте, пока не будет больше конфликтов файлов и все будет добавлено. Затем зафиксируйте.

You can read more about merge conflicts in the Pro Git. И here's another question covering resolving conflicts in Git.