Question

I’ve got an Xcode project under git and I’ve got a “experimental” branch off of my “master” branch. Both branches have diverged since the branch (so no fast-forwarding!), and I am merging “experimental” into my “master” branch.

I’ve setup a .gitattributes file to treat a particular Xcode file (project.pbxproj) as binary, as it should be treated as such. However, I’m not sure exactly how to merge it. I’m not sure what that particular file does, but if for example it handled which files were added to the project there’s no way I can merge them, and therefore I’d have to manually add certain files back to the project (possibly not remembering them all). How do others handle this situation?

Also, I’ve read that you have to manually update binary files (obviously) or copy over different versions. However, once I’m into the merge process the file in my working copy is the “master” version. How can I access the “experimental” version? I can’t check it out as it would disrupt the merging process.

Thanks for your time!

Answer 1

In general, for binary files, I recommend a copy-merge type of .gitattribute directive.
That is, I just copy the file coming from the remote end of a merge.

For .pbxproj files however, that may not be a good option, as described here.

Wrapping these files would only make the problem worse as far as I can tell – as you wold be completely unable to merge changes.
While you can merge project files in some cases, it’s not something that you should
count on being able to do. The basic recommendation is to avoid editing the project files at the same time as someone else.

I like versionning projects files (like the ones for Eclipse), only if I know they are:

• not modified that often (certainly not by each developers)
• only using relative paths
• no data specifics to one workstation

In short, if those files are not to be merged (or will only be trivial to merge), I want them in a VCS. In your case, that may not be so useful to have them in said VCS in the first place.

---

Note: as mentioned in the Git manual:

During the merge, the index holds three versions of each file. Each of these three “file stages” represents a different version of the file:

$ git show :1:file.txt  # the file in a common ancestor of both branches
$ git show :2:file.txt  # the version from HEAD.
$ git show :3:file.txt  # the version from MERGE_HEAD