开发者

Merging Xcode project files

开发者 https://www.devze.com 2023-01-21 19:39 出处:网络
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) 开发者_运维技巧when merging branches (I\'m using git). Sometimes it\'s easy, but at times I end up with a corrup

There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) 开发者_运维技巧when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.

Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?


EDIT-- Some related questions:

Git and pbxproj

Should I merge .pbxproj files with git using merge=union?

RESOURCES:

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/


  1. Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.

  2. Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.

  3. Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.

  4. Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.

  5. For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.

  6. Define a common "Source Tree" for your code, and a second for 3rd party sources.

  7. There are external build tools available. This may be an option for you (at least, for some of your targets).

At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.


You might want to try https://github.com/simonwagner/mergepbx/

It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.

Disclaimer: I am the author of mergepbx.


The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.

Add this to your .gitatributes file:

*.pbxproj -crlf -diff -merge


To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge). now click "left" button and open xcode project main directory. click "right" button and open xcode project main directory to compare.

Now click "merge" button!

Thats it!


Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch. Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.

0

精彩评论

暂无评论...
验证码 换一张
取 消