I noticed that Xcode 7 creates a new .xcscmblueprint file in the xcshareddata folder. Will it be always auto generated? Should this file be added to the ignore list of the repository, or should it be checked in into repository?
Xcode 6 has the .xccheckout file, I've always gitignore'd that file.
I'm gitignoring them, for exactly the same reason as .xccheckout.
GitHub's maintained .gitignore added that too, for both Objective-C and Swift. https://github.com/github/gitignore
I think it depends. Just like #Ewan Mellor said the reason for ignore .xcscmblueprint is same with it for .xccheckout.
But whether ignore .xccheckout depends on your project . If you are using single project there is no need. If you are using workspace committing xccheckout file is need. For more the answer #Chris Hanson published is feed your need.
Back to the question. The content of the xcscmblueprint contains the main information about your project.
And I'm not sure it will change in the future. As the same reason for xccheckout I would like to commit this file.
The files seems to contain information pertaining to your source code repository. I think the "SCM" part of the filename stands for "Source Code Management". When looking at the one in my project, it indeed contains information about the GitHub repository that my XCode projects it (and also the git submodules that my repository uses, that's neat!). Of course, it also contains hashes so one could wonder if they are stable across developer, but I'd bet they are.
For that reason, I back up the advice given in many comments. You DO want to version this file.
Related
If I have an Xcode project that is version controlled and I want to keep related files together, would it be ok if I added them to a separate group in the project for as long as the files don't get included in any target? I am thinking Photoshop files and the like...
There is no technical reason why you couldn't do this. However, you should be aware that if you are using Git (which is likely since it sounds like you are using the Xcode integration), the Git doesn't deal well with binary files. It will cause your repository to be bloated, as well as the fact that you won't be able to merge these files at a later date.
That said, with tools like git-annex you can get around some of these limitations.
I am still pretty new to using git, and I am a little confused on how to ignore files. I know you make a file named .gitignore, and usually have it at the root directory of your project, but is that it?
Am I supposed to add it to my Xcode project in Xcode 5? Most of my research has shown what should be IN the .gitignore (like Gitignore/Objective-C.gitignore), but the closest I've found to my question is: How to add .gitignore file into Xcode project.
While that does say HOW to do it, is this what one does? Or do you just leave it in the base folder and it doesn't matter whether it is in the project or not?
.gitignore files are processed regardless of whether or not they're tracked. They're usually tracked, just as the main branch is usually called master, and since if they're not tracked they're vulnerable to e.g. git clean I can't figure why anyone would leave them untracked, but it's irrelevant. Only what's in them matters.
In Xcode, what's the best way to avoid Git conflict in the project file? (I am in manual git, not using Xcode interface for git)
I've cloned mapbox-ios-sdk from Github, hacked it, and now the remote master has changed. When I tried to pull the remote changes into my local, after merging there would be merge conflict in the project file. (Specifically, I mean the project.pbxproj in the .xcodeproj)
I do not really think project file should be put into the ignore, since if there are any new files the project file, the .pbxproj file seems to be changed. (Or am I just plain wrong and this file should be put to ignore? But obviously it wasn't on ignored in the mapbox-ios-sdk to begin with. People need the project file after all.) But I've also ran into this conflict before in my collaboration project with another collaborator and it's keeping me from using Git altogether.
Should I figure out how to manually resolve conflict or is there a better way to deal with this?
A lot of websites simply suggest to use a .gitattributes file with:
*.pbxproj merge=union
We're gonna try this approach before trying to use scripts. If we find any issues I'll be sure to update this post. Also if anyone else has comments to this approach please include.
.pbxproj will change when you add new files to the project. There will be conflicts if two or more collaborators add files at the same time (without getting one another's changes first). We are avoiding this in my project by following these steps before and after adding new files:
Before adding a file, commit your changes, then pull from the master so that you have the latest.If someone has added a file, you now have the latest .pbxproj
Add your file(s).
Immediately commit and push your changes up to the master (hopefully, before another collaborator has added another file).
It's wimpy, but we don't relish manually resolving .pbxproj conflicts.
Also, see this Stack Overflow question with excellent responses: How to use Git properly with XCode?
You should check my script xUnique, it is now the best solution to merge Xcode project file before Apple takes action on it.
What it does & How it works
convert project.pbxproj to JSON format
Iterate all objects in JSON and give every UUID an absolute path, and create a new UUID using MD5 hex digest of the path
All elements in this json object is actually connected as a tree
We give a path attribute to every node of the tree using its unique attribute; this path is the absolute path to the root node,
Apply MD5 hex digest to the path for the node
Replace all old UUIDs with the MD5 hex digest and also remove unused UUIDs that are not in the current node tree and UUIDs in wrong format
Sort the project file inlcuding children, files, PBXFileReference and PBXBuildFile list and remove all duplicated entries in these lists
see sort_pbxproj method in xUnique.py if you want to know the implementation;
It's ported from my modified sort-Xcode-project-file, with some differences in ordering PBXFileReference and PBXBuildFile
With different options, you can use xUnique with more flexibility
Check README file for more details.
In most case, you can fix the merge by following code, remove the lines which git adds:
#!/bin/bash
FILE={PRODUCT_NAME}.xcodeproj/project.pbxproj
sed '/======/d' $FILE | sed '/<<<<</d' | sed '/>>>>>/d' > temp
cat temp > $FILE
rm temp
but if you rename the group of your project and it leads to conflicts, you will manually delete the extra lines of your original group.
When this is caused by adding files from two or more collaborators/branches (which in my experience has always been the case to date and can be checked by looking at the diff) I do this:
Resolve the conflict by "use ours" or "use theirs" (whichever has added the most files).
Commit (this produces a repo that contains all the added files but some are not in the project).
Within Xcode use "Add Files To..." to add the missing files from the other collaborator/branch (they are easy to find as they are in the project directory and Xcode usefully highlights them for you).
Commit.
(I am not convinced step 2 is really necessary - but feels neater to me).
You can also use Mergepbx manually do it as follows
Install Mergepbx using brew.
brew install mergepbx
Run a command each time you have conflicts in your project file to automatically resolve them.
git mergetool --tool=mergepbx PROJECT.pbxproj
I need to get master code in my branch So, I was taking pull from master and I have a change in my .pbxproj file and master has different configuration. So, It was showing conflict in .pbxproj file. Follow these steps to resolve it
Open .pbxproj in Finder->
Right click on file Choose Show Package Contents->
Choose .pbxproj file and open it with TextEdit->
It will show conflict lines as below.
<<<<<<< HEAD"
// head changes
===========
// Your changes
>>>>>>>>
You have choose the right one from head Changes and your changes and Delete the rest.
Now commit you code
git add .
git commit -m"conflict resolved"
git status // Check you files status
If everything is fine the push you code.
git push
I made an app for fixing things in Xcode project files when these sort of things go wrong. You'd still have to do some manually merging first though, unfortunately.
https://itunes.apple.com/us/app/xsaviour/id1449886415?mt=12
If all else fails, while tedious. you can open your pbxproj in your git client, then manually, go file by file and ensure each one is either removed or has 4 lines (6 occurrences).
I had the same problem, so I wrote a tool in Swift that will resolve conflicts due to adding, deleting, moving, and renaming files and groups. You can set it up as a git merge driver so the script runs automatically when you merge a branch.
You can check it out here: XcodeMergeDriver
I am part of a project with multiple developers. The project contains multiple targets. VERY often, files are committed to the Xcode project repository with some targets not-included (careless programmers). So whenever i do a 'svn up', and run the app, my program crashes. I then have to look through all those files and see which one was committed with the missing target, then add the target, and recommit the file to the repository (for that careless programmer)
Is there some way through a script to either automatically add all .m to a particular target?
OR
list all the files that are missing for a particular target?
I have looked at Add files to an XCode project from a script for reference already.
My answer on this other thread shows you how to see all files that are not part of a target:
https://stackoverflow.com/a/12867723/591586
I did as Paul suggested and wrote a python script that inspects the .pbxproj and lists all the files and the targets they are included in.
You could easily modify that script so that it highlights the files that are not included in specific targets.
https://github.com/laurent74/XPFAT
This question has been asked before, but neither did that question got an answer.
As far as I know, XCode does not have any build in support for comparing targets. However, the project is nothing more than an set of XML files... very detailed XML files though.. but still XML.
What you could do (this is not something I recommend though) is read through the XML files of the project and try to understand how they are build.
I know this is not the answer you are looking for, but it might be a workaround.
Update
I read though project.pbxproj of a test project with two targets, and it seems as if the project is build up into references. Which is smart since one wouldn't have a huge file if you have many targets. However, it does mean that its really hard to read.
I would like two things:
to be able to change branches in git, and then Run or Build in Xcode without recompiling the entire project.
have git ignore intermediate build files during merge, so it won't ask me to resolve any conflicts.
Putting the intermediate builds folder outside the project, or using .gitignore to ignore that folder, accomplishes #2 but not #1; I have to rebuild the entire project when I change branches, even if I did not modify any files.
Well, you've answered #2 correctly yourself, so really your question only related to #1. I don't really see why Xcode would need to recompile things either - git won't change timestamp on unchanged files when switching branches.
Have you actually implemented the #2 solution, so that the entire problem isn't caused by git stomping on your build directory, which should be .gitignore'd?
You could define two variables:
MY_BRANCH_NAME = branch_foo (adapted in each branch)
TARGET_TEMP_DIR = $(CONFIGURATION_TEMP_DIR)/$(TARGET_NAME)$(MY_BRANCH_NAME).build (the same for all branches)
This way, the builds for your different branches will be made and keeped in separate folders, not needing to recompile everything because of a branch-to-branch config change.
You can do it in xcconfig files, or automatically define MY_BRANCH_NAME as an xcodebuild argument in a build script, among other means.
Xcode is going to do all of its data based on the timestamps of the files in question. If you replace the file with a newer file, then Xcode should notice that the timestamp of the file is newer than the timestamp of the build product and recompile it.
However, if you change it with an even older version of the source file, then it can't know that the build file isn't correct. It will just see that the build output is still newer than the source file, and so not recompile it.
In short, you can't know which files have definitely changed, and which have definitely not. You're better off doing a full clean+rebuild to make sure; otherwise you're going to lose time debugging when it doesn't work.