Вирішення конфлікту Git з бінарними файлами

Я використовую Git в Windows (msysgit) для відстеження змін для деяких дизайнерських робіт, які я робив.

Сьогодні я працюю на іншому ПК (з віддаленим репо brian) і зараз намагаюся об'єднати зміни, зроблені сьогодні, у свою звичайну локальну версію свого ноутбука.

На своєму ноутбуці я git pull brian masterвтягував зміни в свою локальну версію. Все було добре, крім основного документа InDesign - це показує як конфлікт.

Версія на ПК ( brian) - це остання версія, яку я хочу зберегти, але я не знаю, які команди вказують repo використовувати цю.

Я спробував безпосередньо скопіювати файл на свій ноутбук, але це, здається, порушило весь процес злиття.

Чи може хтось вказати мене в правильному напрямку?

git checkoutприймає --oursабо --theirsваріант для таких випадків. Отже, якщо у вас конфлікт злиття, і ви знаєте, що просто хочете, щоб файл із гілки, в яку ви зливаєтеся, ви можете:

$ git checkout --theirs -- path/to/conflicted-file.txt

використовувати цю версію файлу. Так само, якщо ви знаєте, що хочете, щоб ваша версія (а не та, в яку об’єдналася), ви можете використовувати

$ git checkout --ours -- path/to/conflicted-file.txt

Ви повинні вирішити конфлікт вручну (скопіювавши файл) і потім скопіювати файл (незалежно від того, скопіювали ви його чи використовували локальну версію), як це

git commit -a -m "Fix merge conflict in test.foo"

Git зазвичай автоматично з’єднується після злиття, але коли він виявляє конфлікти, він не може вирішити самостійно, він застосовує всі виправлені нами патчі, а решту залишає вам вирішувати та виконувати вручну. Сторінка " Git Merge Man" , курс збоїв у Git-SVN або цей запис у блозі можуть пролити деяке світло на те, як це має працювати.

Редагувати: Дивіться публікацію нижче, фактично не потрібно копіювати файли самостійно, але ви можете їх використовувати

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

щоб вибрати версію потрібного файлу. Копіювати / редагувати файл буде потрібно лише в тому випадку, якщо ви хочете поєднати обидві версії.

Будь ласка, позначте відповідь mipadis як правильну.

Ви також можете подолати цю проблему

git mergetool

що спричиняє gitстворення локальних копій конфліктуючого бінарного файлу та створює на них ваш редактор за замовчуванням:

• {conflicted}.HEAD
• {conflicted}
• {conflicted}.REMOTE

Очевидно, ви не можете корисно редагувати файли бінарних файлів у текстовому редакторі. Натомість ви копіюєте нове{conflicted}.REMOTE файл, {conflicted}не закриваючи редактор. Потім, коли ви закриєте редактор, gitви побачите, що незадекларована робоча копія була змінена і ваш конфлікт злиття вирішений звичайним чином.

Щоб вирішити проблему, зберігаючи версію у вашій поточній гілці (ігноруйте версію з гілки, в яку ви об'єднуєтесь), просто додайте та введіть файл:

git commit -a

Щоб вирішити проблему, замінивши версію у вашій поточній гілці та версію з гілки, в яку ви об'єдналися, потрібно спочатку завантажити цю версію у свій робочий каталог, а потім додати / ввести її:

git checkout otherbranch theconflictedfile
git commit -a

Пояснюється більш докладно

Відповідь mipadi не дуже працювала для мене, мені потрібно було це зробити:

git checkout - ваш шлях / до / file.bin

або, щоб зберегти версію об'єднання в:

git checkout - їх шлях / до / file.bin

тоді

git додати шлях / до / file.bin

І тоді мені вдалося знову зробити "git mergetool" і продовжити наступний конфлікт.

Від git checkoutдок

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

--ours
--theirs
Перевіряючи шляхи з індексу, перевірте етап №2 ( ours) або №3 (theirs ) для безперебійних шляхів.

Індекс може містити незаряджені записи через попереднє невдале злиття. За замовчуванням, якщо ви спробуєте перевірити такий запис з індексу, операція оформлення каси завершиться невдало, і нічого не буде перевірено. Використання -fбуде ігнорувати ці незареєстровані записи. Вміст з певної сторони злиття можна перевірити з індексу за допомогою --oursабо --theirs. З -m, зміни, внесені до файлу робочого дерева, можуть бути відхилені, щоб відновити вихідний конфліктний результат злиття.

Я зіткнувся з подібною проблемою (бажаючи виконати комісію, яка включала деякі бінарні файли, які спричинили конфлікти при об'єднанні), але я натрапив на інше рішення, яке можна зробити повністю за допомогою git (тобто не потрібно копіювати файли вручну). Я подумав, що включу його сюди, принаймні, я можу згадати його наступного разу, коли мені це потрібно. :) Сходи виглядають так:

% git fetch

Це вибирає останні віддані комісії з віддаленого сховища (можливо, вам потрібно буде вказати назву віддаленої гілки залежно від вашої установки), але не намагається їх об'єднати. Він записує фіксацію в FETCH_HEAD

% git checkout FETCH_HEAD stuff/to/update

Для цього потрібна копія бінарних файлів, які я хочу, і перезаписується те, що знаходиться в робочому дереві, з версією, отриманою з віддаленої гілки. git не намагається робити злиття, тому ви просто отримаєте точну копію бінарного файлу з віддаленої гілки. Після цього ви можете додати / ввести нову копію так само, як звичайну.

Ця процедура полягає у вирішенні конфліктів бінарних файлів після того, як ви надіслали Github запит на витягнення:

1. Тож у Github ви виявили, що у вашому запиті на виклик є конфлікт у двійковому файлі.
2. Тепер поверніться до тієї ж гілки git на вашому локальному комп’ютері.
3. Ви (a) повторно зробите / перетворите цей бінарний файл знову і (b) зафіксуєте отриманий бінарний файл у цій самій гітці git.
4. Потім ви знову натискаєте цю саму гіт-гіт до Github.

У Github, на ваш запит на притягнення, конфлікт повинен зникнути.

Якщо двійковий файл - це щось більше, ніж dll або щось, що можна редагувати безпосередньо як зображення або файл суміші (і вам не потрібно перебирати / вибирати один чи інший файл), справжнє злиття буде таким, як:

Я пропоную шукати різний інструмент, орієнтований на те, який ви двійковий файл, наприклад, є кілька безкоштовних файлів для зображень, наприклад

• npm install -g imagediff IIRC від https://github.com/uber/image-diff
• або python https://github.com/kaikuehne/mirror.git
• там є інші

і порівняти їх.

Якщо там не існує різного інструменту для порівняння ваших файлів, то якщо у вас є оригінальний генератор бін-файлу (тобто існує редактор для нього ... як blender 3d, ви можете вручну перевірити ці файли, також перегляньте журнали та запитайте іншу особу, що ви повинні включити) та зробіть вихід файлів за допомогою https://git-scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge

$ git show :1:hello.blend > hello.common.blend $ git show :2:hello.blend > hello.ours.blend $ git show :3:hello.blend > hello.theirs.blend

Я зіткнувся з двома стратегіями управління різними / об'єднаними бінарними файлами з Git на windows.

1. Tortoise git дозволяє налаштувати інструменти diff / merge для різних типів файлів на основі їх розширень. Див. 2.35.4.3. Розширені налаштування відмінності / об'єднання http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html . Ця стратегія, звичайно, спирається на наявні підходящі інструменти різного / злиття.

2. Використовуючи атрибути git, ви можете вказати інструмент / команду для перетворення вашого бінарного файлу в текст, а потім дозволити вашому інструменту diff / spajanje за замовчуванням зробити це річ. Див. Http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes . У статті навіть наведено приклад використання метаданих для розходження зображень.

У мене були обидві стратегії роботи з бінарними файлами моделей програмного забезпечення, але ми працювали з черепаховим git, оскільки конфігурація була простою.

Я використовую Git Workflow для Excel - https://www.xltrail.com/blog/git-workflow-for-excel, щоб вирішити більшість моїх бінарних файлів, пов'язаних з проблемами злиття. Цей додаток з відкритим кодом допомагає мені продуктивно вирішувати проблеми, не витрачаючи занадто багато часу, і дозволяє мені вишнево без будь-якої плутанини вибрати правильну версію файлу.

мій випадок здається помилкою .... за допомогою git 2.21.0

Я зробив тяг ... скаржився на бінарні файли:

warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.

І тоді нічого в жодній із відповідей тут не призвело до жодного результату, який мав би сенс.

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

git checkout --theirs -- <path>
git checkout --ours -- <path>

Я отримую вихід:

Updated 0 paths from the index

і я все ще маю свою версію файлу. Якщо я rm, а потім замовити, він замість цього скаже 1, але він все ще надає мені свою версію файлу.

git mergetool каже

No files need merging

і статус git говорить

    All conflicts fixed but you are still merging.
    (use "git commit" to conclude merge)

Один із варіантів - скасувати комісію ... але мені не пощастило і у мене було багато комітів, і цей поганий був першим. Я не хочу витрачати час на це повторення.

щоб вирішити це безумство:

Я просто бігав

git commit

яка втрачає віддалену версію і, ймовірно, витрачає місце, зберігаючи додатковий бінарний файл ... тоді

git checkout <commit where the remote version exists> <path>

що повертає мені віддалену версію

потім знову відредагував файл ..., а потім здійснити і натиснути, що, ймовірно, означає витратити місце на іншу копію бінарного файлу.