Xcode zmienia niezmodyfikowane storyboardy i pliki XIB

Scenorysy są raczej królewskim bólem z perspektywy przepływu pracy git, gdy wielu ludzi współpracuje z nimi. Na przykład zaczyna się XML w pliku .storyboard<document> tagtoolsVersion isystemVersion atrybuty zmienione przez dowolną konfigurację, którą uruchamia najnowszy manipulator plików. Wydaje się, że synchronizacja wszystkich wersji Xcode jest bardzo pomocnatoolsVersion, alesystemVersion zmiany bez względu na to, w zależności od konkretnej wersji Maca i / lub OS X, na której działa programista.

To jest idiotyczne, ale w większości nieszkodliwe. Martwi nas jednak to, że czasami inne zmiany są automatycznie wprowadzane do serii ujęć, po prostu otwierając je pogit pull. Oznacza to, że Alice wprowadza zmiany w serii ujęć, zatwierdza je i umieszcza w repozytorium. Następnie Bob ściąga zmiany Alice i otwiera storyboard, aby dokonać dalszych zmian. W momencie, gdy otwiera storyboard, ikona pliku natychmiast zmienia się w stan zmodyfikowany, ale niezapisany, agit status pokazuje, że wystąpiło wiele dziwnych zmian. Wszystko to bez zmiany Boba lub zapisania pliku.

Najczęstszą zautomatyzowaną zmianą, jaką widzimy, jest zniknięcie lub ponowne pojawienie się całej zmiany<classes> oznaczyć hierachy przy końcu pliku serii ujęć. Nie wiemy, co to powoduje. Możemy mieć kilka zlokalizowanych wersji storyboardu w różnych katalogach .lproj, a otwierając je 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. To powoduje dużo hałasugit diff, ale tak naprawdę nie przerywa żadnej funkcjonalności. Często wybiórczo dodamy rzeczywiste zmiany, które wprowadziliśmy do indeksu git, zatwierdzamy je, a następnie po prostu odrzucamy spontaniczne, bezsensowne<classes> zmiany. Ma to na celu zachowanie małych i miłych zobowiązań, tak jak powinny być. Ostatecznie jednak staje się to zbyt trudne, ponieważ Xcode ciągle zmienia te zmiany, a ktoś po prostu poleca je wraz z innymi rzeczami ... co jest w porządku, dopóki Xcode innej osoby nie zdecyduje się na zmianę z powrotem na nie pozorny powód. (Nasza historia popełnień ma wiele przekleństw.)

Czy ktoś inny widzi to zachowanie? Czy jest to błąd Xcode lub problem z konfiguracją jednego lub kilku naszych programistów Mac? Widzieliśmy podobne zachowanie podczas współpracy z plikami XIB, ale storyboardy wydają się na to bardziej podatne.

questionAnswers(5)

yourAnswerToTheQuestion