2010-01-18 21 views
13

Mam plik binarny w my_branch, a gdy będę musiał dokonać zmian, git oczywiście go nie scali.Jak scalić plik binarny?

Więc co mam teraz zrobić, to:

git checkout my_branch 
# make a change to gui.bin 
mv gui.bin ~/ 
git commit -a 
mv ~/gui.bin . 
git commit -a 
# git rebase to 1 commit 
git checkout master 
git merge my_branch 

Ale czy istnieje prostszy sposób?

+0

Zobacz także http: // stackoverflow.com/questions/1910444/git-merge-s-one-needed-but-i-know-it-doesnt exist/1910479 # 1910479 – VonC

Odpowiedz

17

Nie jestem do końca pewien, o co chodzi w twoim przypadku testowym. Wydaje się, że przesuwasz gui.bin na bok, a następnie odkładasz z powrotem tak, jak było ...

Często pliki binarne nie muszą być łączone, po prostu chcesz wybrać wersję ostateczną od jednej miejsce lub inny. Tam, gdzie naprawdę trzeba je scalić, potrzebujesz niestandardowego narzędzia do scalania lub użyj jakiegoś edytora i wielu ręcznych interwencji.

Zauważyłem, że w swoim przykładzie używasz commit -a. Pierwszym krokiem do uniknięcia niepotrzebnych konfliktów jest niewprowadzanie żadnych plików binarnych, które mogłyby zostać przypadkowo dotknięte, chyba że chcesz je zatwierdzić. Jeśli po prostu git add pliki, które trzeba zatwierdzić i zatwierdzić bez -a to pomoże. Alternatywnie, jeśli istnieje tylko jeden plik, którego nie chcesz zatwierdzić, możesz go zresetować przed wykonaniem zatwierdzenia.

git add -u 
git reset -- dontcommit.dat 
git commit 

Po scaleniu gałęzi, które mają obie zmiany binarne, możesz zachować jedną wersję, a nie drugą. Po scaleniu gdzie git mówi, że ich są konflikty w binarnym można powiedzieć git użyć wersji w branży, że jesteś na to tak:

git checkout --ours binary.dat 
git add binary.dat 

lub z gałęzi, które łączą się ze sobą w ten sposób :

git checkout --theirs binary.dat 
git add binary.dat 
+0

Teraz ten wygląd naprawdę dobrze. Tak więc, aby wyjaśnić. Jeśli zrobiłem "git checkout master". Następnie powinienem użyć ostatniego bloku kodu z "ich", a następnie scalić? – Louise

+0

Twoje pytanie nie jest dla mnie jasne. Jeśli jesteś na 'master' (po udanym kasie) i' git fge otherbranch', jeśli to powoduje konflikty w 'binary.dat', to ostatnie dwa polecenia w mojej odpowiedzi wybiorą wersję z' otherbranch' i oznacz konflikt jako rozwiązany. Możesz wtedy "git commit" zatwierdzić rozwiązany konflikt. –

+0

Doskonały. Dzięki =) – Louise

10

można użyć wbudowanego sterownika binary seryjnej:

binary: Keep the version from your branch in the work tree, but 
leave the path in the conflicted state for the user to sort out. 

przykład .gitattributes linia:

*.bin -crlf -diff merge=binary 

mówi git nie dodawać zakończeń linii, nie diff, i aby utrzymać wersja lokalna

http://git-scm.com/docs/gitattributes

że Tylko konserwy kopia robocza ...

Innym sposobem jest użycie niestandardowego sterownika Merge:

[merge "binmerge"] 
    name = my binary merge script 
    driver = binmerge.sh %O %A %B 

To może sprawdzić konflikt plik z listą plików, które zawsze powinny być nadpisane przez lokalną wersję. ..

użyć sterownika scalania, zdefiniować go w config, a następnie określić, jakie ścieżki powinny być wykorzystywane na w .gitattributes, tak:

*.bin -crlf -diff merge=binmerge 

binmerge.s h zostanie wezwany do obsługi scalania. może zasadniczo zrobić coś takiego:

#!/bin/sh 
echo "Performing merge of binary object ($1, $2, $3)" 
touch $2 
exit 0 
+0

Dobra, sterowniki dla gita są dla mnie zupełnie nowe. Czy jest to coś, co umieściłem w pliku konfiguracyjnym .git? – Louise

+1

Tak, to byłoby w ~/.gitconfig lub .git/config – jspcal

+0

Bardzo interesujące. Czy powinienem po prostu zmienić driver = gui.bin? – Louise

Powiązane problemy