Jak scalać konflikty (Projekt pliku.pbxproj) w Xcode używać svn?

Używam Gita, ale widzimy ten sam problem - Jeśli dwie osoby dodają pliki, dochodzi do konfliktu scalania.

Zazwyczaj edycja jest bardzo łatwa. Po prostu przejdź do projektu.plik pbxproj z edytorem tekstu i poszukaj sekcji merge conflict-zazwyczaj jest to oznaczone czymś takim jak:

>>>>>>>
Stuff 1
======
Stuff 2
<<<<<<<<

W 99% przypadków konfliktu scalania projektu Xcode, po prostu chcesz zaakceptować obie strony scalania ( ponieważ dwie osoby dodały Różne pliki) - więc po prostu usuniesz znaczniki scalania, w powyższym przypadku kończyłoby się to następująco:

Stuff 1
Stuff 2

Jak mówiłem, to działa świetnie w większości przypadków. Jeśli Xcode nie odczyta pliku projektu po zakończeniu, po prostu weź najnowszą, nie scaloną wersję i ręcznie dodaj swoje pliki ponownie.

To rozwiązanie jest tylko dla git, ale możesz dodać plik .gitattributes do swojego projektu, a następnie w tym Pliku dodać następującą linię:

*.pbxproj merge=union

To powie gitowi, aby zachował obie strony połączenia, co będzie tym, czego chcesz przez większość czasu.

Szukałem prostego rozwiązania tego problemu, kiedy natknąłem się na inne pytanie/odpowiedź:

Https://stackoverflow.com/a/14180388/307217

Byłem całkowicie zdumiony tym, jak proste jest to rozwiązanie, próbowałem połączyć się w oddzielnej gałęzi funkcji, która była prawie 200 rewizji za bagażnikiem, XCode i Mercurial nie byli zadowoleni z tego. Próbowałem ręcznie połączyć plik pbxproj (który miał ponad 100 konfliktów) 8 razy przed wypróbowaniem tego rozwiązania.

W zasadzie rozwiązanie jest takie (zakładając, że używasz Mercurial, bo jest Super):

1. Spróbuj połączyć się w mercurial:

   hg update FEATURE_BRANCH
   hg merge default
   *mercurial gives you a ton of crap about the pbxproj file having merge conflicts*
   

2. Otwórz Xcode

3. z górnego paska narzędzi wybierz Xcode->Open Developer Tool - > FileMerge
4. po lewej, otwórz swój konfliktowy projekt.pbxproj ' plik (ten z Merge conflict markup)
5. po prawej stronie, otwórz swój 'projekt.pbxproj.orig"
6. wybierz File - >Save Merge i zapisz nad ' project.plik pbxproj

7. Następnie wróć do wiersza poleceń:

   hg resolve -m ProjectName.xcodeproj/project.pbxproj
   *merge any other broken files*
   hg commit -m "manually merged with trunk"
   

8. Jedz Ciasto, Bo Już Po Tobie

Jak wspomniano powyżej najczęstszym sposobem radzenia sobie z konfliktami jest

1. Zaakceptuj "wszystko"
2. Importuj ponownie pliki do projektu

Napisałem bash-script, który zajmuje się (1) powyżej.

zauważ, że rozwiąże to tylko najczęstszy przypadek konfliktów scalania!

#!/bin/bash
#
#
#
if [ $# -eq 0 ]
 then
    echo "File must be provided as argument, darnit!"
    exit 1
fi

if [ $# -eq 2 ]
 then
    echo "only ONE File must be provided as argument, darnit!"
    exit 1
fi


echo "Will remove lines from file:" $1
grep -v "<<<<<" $1  | grep -v ">>>>>>" | grep -v "====" > out.tmp;mv out.tmp $1
echo "Done removing lines from file:" $1

Czasami można odtworzyć jeden lub kilka plików (na przykład ManagedObjects) w różnych gałęziach, więc po scaleniu mogą być dwie deklaracje dla jednego pliku w jednym bloku. W takim przypadku należy usunąć jedną z deklaracji.

Aby ręcznie rozwiązać konflikty scalania, sprawdź UUID każdego elementu będącego w konflikcie.

Przykład:

<<<<<<< HEAD
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
=======
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };
>>>>>>> branch_to_merge

Sprawdź każdy UUID:

• jeśli występuje w obu wersjach, usuń go w jednej wersji: ExistingFile.swift
• Jeśli nie występuje na porównującej gałęzi, zachowaj ją: NewFileA.swift i NewFileB.swift
• Jeśli nie jest odwołany nigdzie indziej w pliku, tzn. można znaleźć tylko jedno wystąpienie w całym pliku project.pbxproj, zakładam, że jest to artefakt i można go bezpiecznie usunąć to.

Wynik będzie:

    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };

Uwaga: nie polecam dodawania *.pbxproj merge=union do pliku .gitattribues, aby w zasadzie ignorować konflikty scalania, ponieważ konfliktowe scalanie powinno być zawsze sprawdzane ręcznie, chyba że istnieje zaawansowany skrypt, który robi to za Ciebie.

Założyłem narzędzie "xUnique" https://github.com/truebit/xUnique , to działa!

Najlepszą rzeczą do zrobienia może być po prostu zaakceptować albo twoją wersję lub jego wersję w całości, bez próby połączenia tych dwóch. Zastanów się również, czy dany plik jest czymś, co w ogóle powinno znajdować się w repozytorium; może być bardziej odpowiednie, aby każda osoba miała jego własną wersję.

Zapoznaj się z dokumentacją , Jak rozwiązywać konflikty.