Background: git -- or any other SCM -- can "successfully" merge Storyboards, xib's, and pbxproj files as at their core they are just xml. Sometimes there are conflicts which can be resolved by the usual conflict resolution strategies. But xib's and Storyboards are serialized formats of some pretty complex data structures, so the fun begins.
Just as with other source code, a successful merge doesn't guarantee all the merged changes work correctly together. With the files in question, git can successfully merge but Xcode sometimes displays a "Could not read archive" error when you try to open it - i.e., the merge corrupted the xib.
I've seen suggestions about having git ignore .xibs (not practical), or in .gitattributes disable diff by setting
*.xib -crlf -diff
Technically, that fixes the merge conflict/corrupted xib problem - but now somebody's changes are lost?
Similarly, the best recommendation I've seen for the project file is merge=union in .gitattributes:
*.pbxproj merge=union
Question: I've searched quite a bit and there doesn't seem to be a good solution. Can people with experience tell me what happens in a few use cases?
In the project I rename a file from x to y, and delete fileA. Meanwhile, another programmer committed changes to add fileC and delete fileD. What is the result of merge? I'm sure the actual file system changes will be correct, but in the Xcode navigator panel:
Will I see both x and Y?
Will fileA reappear because it's still in the other programmer's .pbxproj?
Will fileD still be there because it's still in my .pbxproj?
If git is ignoring .xib files - will I at least get a warning that a file was changed and is not being handled?
I wouldn't set any specific .gitattributes for project files or nibs these days.
Your problems merging concurrent changes to Xcode projects and xibs/storyboards exist in every team with more than one developer.
Xcode projects
A few tricks for dealing with Xcode project conflicts:
Take one side of the merge and manually apply the other changes after the merge. If you've deleted files they'll be in red, if you need to add them they'll be available to add.
When adding files to your targets they will go at the bottom of the 'Compile Sources' build phase. Avoid conflicts with other people by dragging them up this list to a random position.
Use .xcconfig files to configure your projects rather than the build settings section. Config files are trivial to merge.
My best advice if in doubt is to take one side of the merge, relax, and replay your additions.
XIBs and Storyboards
The format of XIBs (and therefor storyboards) has change significantly in recent months. I've found that additional objects are appended to the file's internal collections and merges can be done easily. If you're making changes to the same object, you may have to get in there manually.
This post from Itty Bitty Apps highlights the main changes:
The benefits of this new XIB XML format are many fold:
XIBs are much smaller (fewer lines of code).
A developer can easily read the XML and understand what it specifies in the user interface.
Merging XIBs is now much less likely to lead to broken XIBs. Before we would rarely even bother to try and merge a XIB or Storyboard.
Related
We are coding for senior project. But when I pull project on Xcode, main.storyboard gives an error like in picture. I discarded all changes and cleaned my project, but it did not work. Half of project is on my friend computer, half of is on mine. How can I fix this GitHub error and how can we compound this parts ? Ps : I have backup of my project in another folder.
Storyboards are .xml files. The issue you have recently happened to me after I didn't properly resolve GitHub merge conflicts. When you don't edit the stuff in the <<<<< >>>>>> brackets properly, inside the file that has merge conflicts, you can generate the ID conflicts.
You either have to open the xml file of the storyboard with Xcode itself (or with a Texteditor like Sublime) and fix it manually (if you know what you are doing and where the duplicate elements are, as the file xml-structure is quite complex). The BEST way (especially since you have a backup) would be to go inside the project folder and replace the storyboard file with the old one. You will loose changes made since the backup, but if you commit frequently, it should not be too far behind.
EDIT: If the rest of the stuff you merged relies on a newer version of the storyboard (e.g. IBOutlets or IBActions), you will have to recreate those assets in the storyboard and re-connect them to your code.
Another route instead of replacing the storyboard file would be to do a git hard reset to your last commit before the merge and then attempt to merge again. At that point try to resolve the storyboard conflicts better, which may be very difficult. Don't worry, storyboard merge conflicts are a big pain to every developer. If nothing helps, resetting by replacing the file above should always work.
GENERAL RULE: Try to use multiple storyboards for your viewcontrollers. Group them into storyboards as you see fit. That way if one storyboard gets conflicted, it will easier to reset it and then manually adjust it to the latest state. It is also less likely to get merge conflicts in the first place because it's unlikely that two coders will work on the same storyboard file. Usually working on the same file is fine, when editing different lines but storyboards are different. As soon as you open them you get all sorts of view misplaced stuff and other things edited into the xml automatically. So if you open one and didn't actually change anything, reset the changes and don't commit it.
Although I already read similar comments here, in this forum, I haven't found an approach that may be suitable for teamwork in a seamless way.
If you know what I mean, you already may found tricky working with git and the project.pbxproj file in Xcode, even when you are working in a different file.
Say,
A developer: created Foo folder, adding foo.swift to the project.
B developer: created Bar folder, adding bar.swift to the project.
Different paths... but you know, conflict! And as you may also noticed, leaving project.pbxproj out is not an option.
So my question is: How do you handle this in a professional manner, Git flow ready and easiest way.
Thank you all very much.
PS: I'm using currently Bitbucket and SourceTree if matters.
PS2: I'd like to avoid command line and manually file editing if possible.
Create a .gitattributes file and adding the following line:
*.pbxproj merge=union
Merges will happen automatically and without you having to touch anything.
Alternatively, you might try mergepbx, which does a more intelligent merge.
New files are created by only one developer on "main-develop" branch.
Push new files to "main-develop"
Those files are implemented by other developers after pull
I'm one of the maintainers of Kintsugi, a tool that intelligently merges the conflicts and promises to automatically solve 99.9% of the conflicts that occur in project.pbxproj files.
The readme also contains instructions on how to set it up as Git merge driver, so it will be applied automatically whenever a conflict in a *.pbxproj file occurs. I don't know of a way to do that from Sourcetree, but for most conflicts after setup you won't have to touch the command line again.
Storyboards are rather a royal pain from a git workflow perspective when multiple people are collaborating on them. For example, the XML in the .storyboard file has its starting <document> tag's toolsVersion and systemVersion attributes altered by whatever configuration the most recent file manipulator happens to be running. Synchronizing everybody's Xcode versions precisely seems to help with toolsVersion, but systemVersion changes no matter what, depending on the specific Mac and/or OS X version the developer is running.
This is idiotic, but mostly harmless. What worries us, though, is that at other times some other changes are automatically made to the storyboard just by opening them after a git pull. That is to say, Alice makes changes to a storyboard, commits and pushes them to the repository. Bob then pulls Alice's changes and opens up the storyboard to make further changes. The moment he opens the storyboard, the file icon immediately changes to a modified-but-unsaved state, and a git status shows that any number of weird changes have occurred. All this without Bob having changed anything or saved the file himself.
The most common automated change we're seeing is the disappearance or reappearance of the entire <classes> tag hierachy near the end of a storyboard file. We haven't figured out what is causing this. We may have several localized versions of a storyboard in various .lproj directories, and when opening them inside Interface Builder, the class hierarchy may spontaneously be removed from some and added into others, or left alone in some. This causes a lot of noise in git diff, but it doesn't actually break any functionality. We will often selectively add the actual changes we made into git's index, commit those, and then just discard the spontaneous, nonsensical <classes> changes. This is to keep commits small and nice, as they should be. Eventually, though, it just becomes too much to bother with since Xcode keeps re-doing the changes, and someone just ragecommits them along with some other stuff... which is fine until someone else's Xcode decides to want to change them back for no apparent reason. (Our commit history has a lot of swearing over this.)
Is anyone else seeing this behaviour? Is this an Xcode bug or a configuration issue on one or more of our developer Macs? We've seen some similar behaviour when collaborating with XIB files, but storyboards seem more susceptible to this.
This is not a bug, this is a consequence of how Xcode processes storyboard files.
I am writing a diff and merge program for storyboard files (GitHub link) and I have spent hours analyzing the storyboard files logic and how Xcode processes it. This is what I discovered:
Why do weird changes occur in storyboard files?
Xcode uses the NSXML API to parse storyboard files into some NSSet-based logical tree structure. When Xcode needs to write changes it creates an NSXMLDocument based on the logical tree structure, clears the storyboard file and calls XMLDataWithOptions: to fill the file again. Because sets do not preserve the order of their elements, even the slightest modification could change the whole storyboard XML file.
Why does the class tag disappear or reappear randomly?
The <class> section is nothing more than an internal Xcode cache. Xcode use it to cache information about classes. The cache changes often. Elements are added when class .h/.m files are opened and removed when Xcode suspects they are outdated (at least older Xcodes behave like this). When you save the storyboard, the current version of the cache is dumped, which is why the <class> section often changes or even disappears.
I have not reverse-engineered Xcode; I made these observations by experimenting with Xcode and storyboard files. Nevertheless, I am almost 100% sure it works this way.
Conclusions:
Cache section is unimportant; you can safely ignore any change in it.
Contrary to what you can find on all forums, merging storyboards files is not a complicated task. For example, let’s assume you changed MyController1 view controller in a storyboard document. Open the storyboard file, and find something like this
<viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>.
You can safely commit only changes in this section and ignore everything else. If you changed segues or constraints, also commit anything that has “ory-XY-OBM” inside. Simple!
This is a bug in XCode 4.5+, I hope it gets fixed, and yes its a PITA.
Here's the full bug at Apple
How to avoid Xcode gratuitous edits to storyboard files?
This issue can be mitigated somewhat by extremely judicious use of git add -p on any of Xcode's generated files, including storyboards, XIBs, Core Data models, and project files, all of which suffer from similar transient modifications that have no impact on the actual interface/model/project.
The most common junk changes I've seen on storyboards are the system version numbers (as you mention) and the constant addition and removal of the <classes> section, the omission of which I have never seen cause problems. For XIBs, it's the addition and removal of <reference key="NSWindow"/>, which isn't even a class in Cocoa Touch. Just wow.
Think of it like the sea: there is both a high and low tide. Let it wash over you.
Ahh. That's it.
You can ignore these modifications when staging your changes, reset the junk changes, and make a clean commit.
The single advantage I've seen with storyboards over XIBs from a technical standpoint is that Apple has not yet neutered FileMerge to refuse to merge conflicted storyboards. (FileMerge used to be able to merge XIBs, but newer versions broke that. Thxxxx guys 💜!!!)
Please file lots of bugs about all of these problems at http://bugreporter.apple.com/! And don't forget to create entries on OpenRadar.
Throwing on another answer here because this situation has improved greatly. The XML for the XIB file that represents the StoryBoard has been greatly simplified.
I have also recently bitten the bullet and started to use the interface in Xcode to Source Control. I have been on the command line for years and happy there, but the interface is nice and it lets you split commits, which is really important if you use a ticketing system that links to commits.
Anyway, I noticed today that there was a change on the storyboard and the built in diff showed me it was a single attribute in the document tag (systemVersion). So not a big deal.
I have read articles where people say SBs were outlawed on their teams because of merging issues. Total madness. They are so amazing, especially now that they have intelligent autolayout built in, you are really missing out if you are not using them.
It's helpful to know why this insanity is happening, but for those who believe in keeping their projects free of warnings and who just want a quick-and-dirty to get their projects back to a healthy state:
Don't commit anything until explicitly instructed.
Open Xcode and create a new storyboard (Command+N > iOS > User Interface > Storyboard). I'll assume you call it the default name of Storyboard.storyboard.
Open the storyboard that Xcode has violated. I'll assume this is Base.lproj/Main.storyboard.
Select and copy everything on the storyboard (Command+A then Command+C).
Open Storyboard.storyboard.
Copy and paste everything into Storyboard.storyboard.
Close Xcode.
Open a terminal and change directories to your repository.
Replace Main.storyboard with Storyboard.storyboard (mv Storyboard.storyboard Base.lproj/Main.storyboard).
git add Base.lproj/Main.storyboard; git commit -m "Fix Xcode's insanity."
Disregard the changes to project.pbxproj via git checkout -- project.pbxproj. If you git diff the file, you'll see that it has just added information about our temporary storyboard (which no longer exists).
Open Xcode back up and see that the warnings has disappeared.
Breathe.
Working on same storyboard is not a problem. But working on same viewcontroller which creates conflicts on pull/merge is frightening. we can not really avoid that working in same viewcontroller for a large team.
Good thing is, most of the time we can fixed the same viewcontroller conflicts if we understand the xml structure. I never failed to merge these while working in team. Suppose you are working with a viewcontroller. Your view is blank currently. Please ,have a look at the viewcontroller's xml structure from source code option.
Storyboard is xml bounded by document type tag. Everything in the storyboard contains in scene sceneID= tag. scene tag holds every viewcontrollers. Thats the basic.
Now we added a UILabel and a UIButton on the view. Also set the autolayout of the elements. Now it's looks like :
Adding a level/button to viewcontroller added some new code inside the subview tag of the view. Same thing will go for further element addition or any UI changes. Carefully check the tag structure which is really important to fix any conflicts.
Now we add another viewcontroller in the storyboard name Homeviewcontroller. Adding a new viewcontroller means it adds a new scene under scenes tag. Look at this:
At this point, we will change the structure randomly and observe the issues/warnings. We change first viewcontroller label end tag and save the file. Now run it and look at the warning. Error says end tag is not correct which created from line 23. In line 23 , we see a label constrains is set with no end tag. That's the problem. Now we put the end tag and build the project. After setting end tag, we can view the storyboard successfully.
When face any warning of conflicts , please compare with your previous source and changes source. We remove the old/redundant code , keep the new code with proper tag start-end and get things fixed.
[N.B , i will update the answer with some more test cases when get times]
This is a problem we never had to deal with until storyboards were introduced - Whenever there was a chance of conflict in UI, we just made sure that no 2 developers ever worked on the same XIB file simultaneously. The reason we refrained from resolving XIB conflicts is that there may be problematic side-effects (XIB is represented in XML format so there isn't a "good" way to merge 2 versions).
Now we are facing this issue because all of our UI elements are within the same .storyboard file - prevention of simultaneous work on any 2 UI elements in the project makes working in parallel very difficult.
Any suggestions as to how to tackle this issue? Thanks in advance for your efforts.
Break up your storyboard into multiple storyboards.
There is no reason for your app to contain only one storyboard. Break your storyboard up into module storyboards. You can use +storyboardWithName:bundle: to load storyboard modules.
See: UIStoryboard Best Practices for other good storyboard ideas.
Update
It's important to note this is not a complete solution to the problem. In the same way you cannot completely avoid the possibility of merge conflicts in source code decomposing a giant class into smaller modules, you can't avoid the possibility storyboard merge conflicts either. The idea is to reduce the likelihood until it becomes a manageable problem.
There will alway be tricky merge situations in a large codebase. A properly decomposed solution will reduce the number of conflicts and minimize the number of lock out needed.
Here's something I came up with when I was just messing around, trying to find a solution.
If you right click your storyboard file in Xcode and navigate to "Open As" you'll see that there are multiple options - the default is "Interface Builder - iOS Storyboard". However, you can also select "source code".
If you open storyboard up in source code mode, it's possible to make changes (although kind of a pain). But you can add code from other storyboards and make changes in your own - I haven't used SVN but with a git repository I can view other versions of the storyboard and copy code in.
I wouldn't say that this is a great solution - I've had some trouble with Xcode randomly crashing when I try to reopen the storyboard in IB. Sometimes pasting code in works, sometimes it doesn't. A few times I had to change the <scene> tag's value. In my experience it's pretty hit-or-miss but if you back up your files before you try anything it might work.
If it does work, let me know - I'm interested in seeing whether a solution can be found to this problem.
Is this about merging XML files?
Fortunately, SVN allows you to change the merge tool you use to perform merging for different types of file. (eg tutorial for using P4Merge)
So now you just need to find a great tool for merging XML files (good luck :) )
there's WinMerge (with the DisplayXMLFiles prefilter), or diffxml, or XMLMerger or a java xmlmerge tool
You can also have a look at a modern source code management tool. Git for example has intelligent merge features. See this link for why you should consider upgrading your workflow.
I have been an iphone developer for a while, and I have recently been including git in my workflow. I have used git settings found on http://shanesbrain.net/2008/7/9/using-xcode-with-git for my workflow so far.
Those settings tell git to exclude *.pbxproj from merges? Is there a real reason for doing this? For example, when I add a file to the project and push to origin, my fellow developers will not have that file added to their xcode project when they pull. Then if one of them builds a release this file may not be included. Shouldn't I just let git handle the merges for the project file? Why or why not this file should be in merges and how to properly handle the situation when files are added to the project?
I have worked on iPhone applications full time since the SDK launch, most of that time spent working on teams with multiple developers.
The truth is that it's way more harmful to disallow merging of that .pbxproj file than it is helpful. As you say, when you add a file unless other people get that file, they have to also add it to their project - in an application of any size, that sucks and it also takes away a huge benefit of source code control in that you cannot really revert to a complete earlier project state just through git.
The .pbxproj file is simply a property list (similar to XML). From experience, just about the ONLY merge conflict you were ever get is if two people have added files at the same time. The solution in 99% of the merge conflict cases is to keep both sides of the merge, which for git at least simply involves removing any >>>>, <<<<, and ==== lines. In fact this is so common that I have created a simple shell script to fix a .pbxproj file in a merge state from git, I run this from within the project directory (at the Classes level):
#!/bin/sh
projectfile=`find -d . -name 'project.pbxproj'`
projectdir=`echo *.xcodeproj`
projectfile="${projectdir}/project.pbxproj"
tempfile="${projectdir}/project.pbxproj.out"
savefile="${projectdir}/project.pbxproj.mergesave"
cat $projectfile | grep -v "<<<<<<< HEAD" | grep -v "=======" | grep -v "^>>>>>>> " > $tempfile
cp $projectfile $savefile
mv $tempfile $projectfile
Worst case if it fails (you ask XCode to load the project and it fails to load), you simply delete the .pbxproj file, check out the master from git, and re-add your files. But I've never had that happen in many months of use with this script, again working full time on iPhone applications with several other developers.
Another option (pointed out in comments below) that you can try using in place of the script, is to add this line to a .gitattributes file:
*.pbxproj text -crlf -diff -merge=union
Then git will always take both sides of a merge for the .pbxproject files, having the same effect as the script I provided only without any extra work.
Lastly, here is my complete .gitignore file, showing what I do have it set to ignore as there are a few things you don't want - in my case really just emacs remnants and the whole build directory:
# xcode noise
build/*
*.pbxuser
*.mode1v3
*~
# old skool
.svn
# osx noise
.DS_Store
profile
This works for me in Xcode 4.6 and Git 1.7.5.
Add and commit .gitattributes file with this:
*.pbxproj binary merge=union
I've tested this with another team member and works great.
Taken from:
http://robots.thoughtbot.com/post/33796217972/xcode-and-git-bridging-the-gap
Frankly, the existing answers are misleading.
If you never delete or rename files, then using the merge=union strategy, which just combines the differences in different commits directly, is a good idea.
However, in the real world, we do need to delete or rename files sometimes. Merging the differences without any modification would make a lot of problems under these situations, and these problems usually lead to the "Workspace Integrity - Couldn't load project" issue, which makes you even not able to run the project.
The best solution I got so far:
1) Design the project well and add all the needed files at the beginning, so you would seldom need to change the project.pbxproj.
2) Make your features tiny. Don't do too many things in a branch.
3) For any reason, if you need to modify the file structure and get conflicts in project.pbxproj, use your favorite text editor to solve them manually. As you make your tasks tiny, the conflicts might be easy to solve.
The short answer is that even if you don't include that line in .gitattributes, you may not be able to easily merge two modified versions of a .pbxproj. It's better for git to treat it as a binary.
See here for details: Git and pbxproj
Update: Even though the git book still agrees with this answer, I no longer do. I version control my .pbxproj just like any other non-binary source file.
I did create a Python script that can handle merge conflicts in XCode Project files.
If you want to try it, you can check it out here: https://github.com/simonwagner/mergepbx
You will have to install it as a merge driver, so it gets called automatically when you have a merge conflict in your project file (the README.md will tell you how to do that).
It should work much better than using merge=union as mergepbx understands the semantics of your project file and therefore will resolve the conflict correctly.
However the project is still alpha, don't expect it to understand every project file that is out there.