Storyboardy są raczej królewskim bólem z perspektywy przepływu pracy git, gdy współpracuje nad nimi wiele osób. Na przykład XML w pliku .storyboard ma swój początkowy <document>znacznik toolsVersioni systemVersionatrybuty zmienione przez dowolną konfigurację, w której działa najnowszy manipulator plików. Synchronizacja wszystkich wersji Xcode wydaje się pomagać toolsVersion, ale systemVersionzmienia się bez względu na to, w zależności od konkretnej wersji Mac i / lub OS X, na której działa programista.
To idiotyczne, ale w większości nieszkodliwe. Martwi nas jednak to, że w innych przypadkach niektóre inne zmiany są automatycznie wprowadzane do scenorysu, po prostu otwierając je po pliku git pull. Oznacza to, że Alicja wprowadza zmiany w scenorysie, zatwierdza je i wypycha do repozytorium. Następnie Bob pobiera zmiany Alice i otwiera scenorys, aby wprowadzić dalsze zmiany. W momencie, gdy otwiera scenorys, ikona pliku natychmiast zmienia się w zmodyfikowany, ale niezapisany stan, a ikona git statuspokazuje, że nastąpiła dowolna liczba dziwnych zmian. Wszystko to bez konieczności zmiany przez Boba lub samodzielnego zapisania pliku.
Najczęstszą automatyczną zmianą, którą widzimy, jest zniknięcie lub ponowne pojawienie się całej <classes>hierarchii tagów pod koniec pliku storyboardu. Nie ustaliliśmy, co to powoduje. Możemy mieć kilka zlokalizowanych wersji scenorysu w różnych katalogach .lproj, a po otwarciu ich w programie Interface Builder hierarchia klas może zostać spontanicznie usunięta z niektórych i dodana do innych lub pozostawiona sama w niektórych. Powoduje to dużo hałasu git diff, ale w rzeczywistości nie psuje żadnej funkcjonalności. Często będziemy selektywnie dodawać rzeczywiste zmiany, które wprowadziliśmy do indeksu gita, zatwierdzać je, a następnie po prostu odrzucać spontaniczne, bezsensowne<classes>zmiany. Ma to na celu zachowanie niewielkich i ładnych zatwierdzeń, tak jak powinny. W końcu jednak staje się to zbyt trudne, ponieważ Xcode nieustannie odtwarza zmiany, a ktoś po prostu raguje je wraz z innymi rzeczami ... co jest w porządku, dopóki czyjś Xcode nie zdecyduje się na zmianę z powrotem na nie pozorny powód. (W naszej historii zmian jest wiele przekleństw).
Czy ktoś jeszcze widzi takie zachowanie? Czy jest to błąd Xcode lub problem z konfiguracją na co najmniej jednym z naszych komputerów Mac dla programistów? Widzieliśmy podobne zachowanie podczas współpracy z plikami XIB, ale scenorysy wydają się na to bardziej podatne.
