Using Xcode with Git, from: http://shanesbrain.net/2008/7/9/using-xcode-with-git and suggestions from http://stackoverflow.com/questions/456403/can-git-be-integrated-with-xcode

.gitattributes

*.pbxproj -crlf -diff -merge

.gitignore

# xcode noise
*.mode1v3
*.pbxuser
*.perspective 
*.perspectivev3
*.pyc 
*~.nib/
build/*

# Textmate - if you build your xcode projects with it
*.tm_build_errors

# old skool
.svn

# osx noise
.DS_Store
profile

.DS_Store shouldn’t be in the project’s versioned .gitignore file; it should be in the clone-specific .git/ignore file, and then only for users which are using Macs (and thus deal with that file). (Of course, this is less of an issue with an Xcode project, as everybody’s guaranteed to be on a Mac; but still, it’s good practice.)

Could you explain the gitattributes settings? Why are you treating the pbxproj file as binary?

Because they are. Many of Apple’s XML files are not actually introspectable; they are textually-serialized binary representations of memoryspace. You, the user, cannot safely “mess with” those files (which includes allowing git to “mess with” them on your behalf, such as merging them during tree merges.)

Now, that ^^ is all the traditional wisdom. The truth is, you actually can, but it is an absolutely massive pain in the ass to do, and you have to do it all by hand, no via git-magic. I can give you more information about that if you like, or you can look at my cocoa_play repo, wherein I manually comitted every single change I made to the project, along with an explanatory commit message about what those changes involved in the Xcode UI. (Most of that is only applicable to Xcode v3, unfortunately.)

Correct. I've found messing with those files manually a huge PITA. I believe Xcode 4 with better git integration ignores tracking changes in those files, and so should you (unless you really really need to). Let Xcode do it.

…

On Jun 22, 2011, at 2:07 PM, elliottcable ***@***.*** wrote: Because they _are_. Many of Apple’s XML files are not _actually_ introspectable; they are textually-serialized binary representations of memoryspace. You, the user, cannot safely “mess with” those files (which includes allowing git to “mess with” them on your behalf, such as merging them during tree merges.) Now, that `^^` is all the traditional wisdom. The truth is, you actually _can_, but it is an absolutely **massive** pain in the ass to do, and you have to do it all by hand, no via git-magic. I can give you more information about that if you like, or you can look at my [cocoa_play](http://github.com/elliottcable/cocoa_play) repo, wherein I manually comitted every single change I made to the project, along with an explanatory commit message about what those changes involved in the Xcode UI. (Most of that is only applicable to Xcode v3, unfortunately.) ## Reply to this email directly or view it on GitHub: https://gist.github.com/137348

Then how do you handle branching to a topic branch, creating some new files, committing, switching back to master, adding some more different files, and then merging in the topic branch?
I get a merge conflict, but have a script that fixes it by removing the >>>>>>> and <<<<<< stuff that git inserts, since I most likely want to keep all the files anyway.
If treating that file as binary fixes those issues, more power to you, and I will gladly do so as well. Just don't understand how it could.

Sounds like you've created a project, and then added it to a .git repo after the fact. You may be better off, letting Xcode (4) do the work of merging/branching within it's interface, it will do the right things, and then you won't get the merge conflicts with those files.

You can view the documentation here: http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html#//apple_ref/doc/uid/TP40010215-CH7-SW9

Also the Developer forums is a good place to get help if you're an official iOS/Mac developer.

Yeah that's right. I'm oldschool like that :)
That's good to know though, so I will give it a shot after reading the docs. Thanks for the pointers!