Storyboards sind aus Sicht des Git-Workflows eher ein königlicher Schmerz, wenn mehrere Personen an ihnen zusammenarbeiten. Beispielsweise hat das XML in der .storyboard-Datei seinen Anfang<document> StichwortetoolsVersion undsystemVersion Attribute, die durch die Konfiguration des zuletzt ausgeführten Dateimanipulators geändert wurden. Die genaue Synchronisierung der Xcode-Versionen aller scheint dabei zu helfentoolsVersion, abersystemVersion ändert sich unabhängig von der jeweiligen Mac- und / oder OS X-Version, die der Entwickler ausführt.

Das ist idiotisch, aber meistens harmlos. Was uns jedoch beunruhigt, ist, dass zu anderen Zeiten einige andere Änderungen automatisch am Storyboard vorgenommen werden, indem sie nach einemgit pull. Das heißt, Alice nimmt Änderungen an einem Storyboard vor, schreibt sie fest und legt sie im Repository ab. Bob zieht dann Alice Änderungen und öffnet das Storyboard, um weitere Änderungen vorzunehmen. In dem Moment, in dem er das Storyboard öffnet, wechselt das Dateisymbol sofort in einen geänderten, aber nicht gespeicherten Status und agit status zeigt, dass eine beliebige Anzahl von seltsamen Änderungen aufgetreten sind. All dies, ohne dass Bob irgendetwas geändert oder die Datei selbst gespeichert hat.

Die häufigste automatisierte Änderung, die wir sehen, ist das Verschwinden oder Wiederauftreten des Ganzen<classes> Tag-Hierarchie am Ende einer Storyboard-Datei. Wir haben nicht herausgefunden, was das verursacht. Möglicherweise befinden sich mehrere lokalisierte Versionen eines Storyboards in verschiedenen .lproj-Verzeichnissen. Wenn Sie diese in Interface Builder öffnen, wird die Klassenhierarchie möglicherweise spontan von einigen entfernt und zu anderen hinzugefügt oder in einigen alleine gelassen. Dies verursacht viel Lärm ingit diff, aber es bricht eigentlich keine Funktionalität. Wir werden die tatsächlichen Änderungen, die wir am git-Index vorgenommen haben, oft selektiv hinzufügen, diese festschreiben und dann einfach das spontane, unsinnige verwerfen<classes> Änderungen. Dies soll Commits klein und nett halten, wie sie sein sollten. Irgendwann wird es jedoch einfach zu viel, da Xcode die Änderungen immer wieder wiederholt und jemand sie nur mit ein paar anderen Dingen erneut festschreibt. Das ist in Ordnung, bis sich der Xcode eines anderen dafür entscheidet, die Änderungen zurückzunehmen ersichtlichen Grund. (Unsere Commit-Geschichte hat viel Schwur darüber.)

Ist jemand anderes dieses Verhalten zu sehen? Handelt es sich um einen Xcode-Fehler oder ein Konfigurationsproblem auf einem oder mehreren unserer Entwickler-Macs? Wir haben ein ähnliches Verhalten bei der Zusammenarbeit mit XIB-Dateien festgestellt, aber Storyboards scheinen dafür anfälliger zu sein.