I have a file called Authentication.plist in my Xcode project and added it to my .gitignore file. However, I can't stop it from being committed to git automatically when doing so via the xcode source control menu. Is there a more effective way to ensure it doesn't get committed?
Use command git rm --cached Authentication.plist to untrack the file.
The problem is that Xcode's git support sucks. It's probably not even seeing that .gitignore file (you didn't say which one it was, global, user level, repo level, etc.). Your best bet is to turn Xcode's git support off altogether and use SourceTree or the command line. Or, you can at least reduce some of Xcode's automatic behavior:
Notice that I've unchecked "Add and remove files automatically". That will at least help work around this kind of annoying behavior.
Related
I've read that developers really need source control. Now I never used it before and I'm a bit lost with my existing projects.
How do I setup it?
There's already a File path inside of it, but it goes to nothing? I don't even know what it does in there.. I want a local git for my own. I found how to set it up with Terminal. But I think there should be a right way on doing this with Xcode and not with Terminal?
I'm sorry to say that Xcode does not have an option to place an existing project under version control. You can however use GitHub for Mac which will allow you to do this. It also has convenient merging tools and lets you push your code to GitHub.com if you like, all at the touch of a button: https://mac.github.com
It's easy enough to create a git repo from the command line though: open Terminal and navigate to the root folder of your project. Then type the following:
git init
git add .
git commit -m "initial commit"
Note that this approach as well as GitHub for Mac will version control every file in your project - which is not what Xcode does when you start a new project with Git enabled. You may run into trouble because your user interface state changes once every second - which can make committing and merging difficult.
The following article discusses this in detail:
http://pinkstone.co.uk/how-to-place-an-exiting-xcode-project-under-version-control-with-git-and-ignore-files-you-dont-want-to-track/
I can create a repo and use GitHub / BitBucket fine for my own projects. I have had problems when collaborating with other developers or trying to fork a project on GitHub.
I am aware of other answers like Best practices for git repositories on open source projects but there are OSX / Xcode specific problems I want to know how to solve.
.DS_Store files can be a pain. You can use .gitignore to prevent, but what happens if they have already been included, or another developer adds them back in through a clumsy git command?
The .xcodeproj will have changes to the directory names and developer profiles for the other person. What's the best way to do merges or to avoid conflicts?
If I have forked or pulled from a github project, how can I clean up these issues and also minimise merge conflicts for the maintainer?
If people have an example .gitignore created for Xcode, or scripts they use to initialise their repos then that would be great!
Put .DS_Store in .gitignore. Then, if you haven't already, add .gitignore to the repo. (You should not ignore .gitignore.) Now all developers will ignore .DS_Store files. If any were added to the repo erroneously before you put .DS_Store in .gitignore, you can now remove them (in a commit) and they should stay out.
The xcodeproj is a directory. The only file in this directory that must be in the repository is the project.pbxproj file. I generally ignore all of the others by putting these lines in my .gitignore:
*.xcuserstate
project.xcworkspace/
xcuserdata/
You should avoid putting absolute paths in your build settings. Use relative paths.
Your Debug and Release builds should use iPhone Developer as the code signing identity, so that Xcode will automatically select the local developer's profile. When you want to create an IPA (for distribution), Xcode will offer to re-sign it with a different identity, at which point you can choose your distribution profile if you need to.
If you're trying to use a project from github that has made these mistakes, you can try to get the maintainer to fix them, or you can make sure you don't touch the .DS_Store files and the code signing identities in the same commits that you want to send upstream.
For the 2nd issue regarding the .xcodeproj and merge conflicts.
Using a .gitattributes file to specify that merge conflicts for all .pbxproj files should be handled using the merge=union strategy, which should mean that Git knows to merge in the changes from both sides of the conflict, taking the upstream changes first.
This article explains it in a bit more depth
I'll try one by one:
I. You need to use git filter-branch only if you need to remove the files from your history completely. If those files do not contain any credit card information, then i think the following should be enough:
git rm --cached .DS_Store
git commit -m "{Your message}"
then add this file to .gitignore and commit it.
This will commit the removal of the file from the repository but will keep the file in working directory. If you push it though and then somebody else will pull this commit, they might have their file removed, so you MUST communicate this.
By committing .gitignore you will prevent other developers from adding this file again.
If you're not a maintainer, then i don't think you should do anything, but address this issue to the maintainer.
II. I'm a strong believer that hidden files of any nature are most of the time not supposed to be put into the repository exactly for that reason. Therefore i think that you should do the same thing with .xcodeproj as with .DS_Store and put it into .gitignore and commit it. .gitignore is the exception for the rule above.
III. If those files are properly ignored , then there will be no issues in future with them. If they are already in the repo and somebody wants do such cleanup it should be done by maintainer and communicated inside the team.
Hope that helps!
git filter-branch might help you to remove unwanted files (.DS_Store files) from your repository -- see e.g. https://help.github.com/articles/remove-sensitive-data
If a clumsy git commit has added files you should be able to replay the corrected changesets onto a clean repository.
You're right in the sense that if a .DS_Store is already added the .gitignore won't be of much help however I think this is still a good resource for you and others.
When I start a project, I normally look at this list to see if there is a good .gitignore already existing. More specifically for you, this one is the Objective-C .gitignore.
Hopefully those resources are of some use.
As a Mac user you should download a tool like SourceTree which supports Git Flow. Git Flow will help you establish some best practices around how your collaborators will commit code to the repo and at the very least make merge conflicts less frequent and more manageable. For a set of gitignore files for various project types you can go to GitHub and download one that is ready to go. For Xcode they have it listed as Objective-C.gitignore. That is a good starting place and it even covers Cocoapods. If you're using external libraries, your project should use CocoaPods so that you can isolate that code and keep it outside of your repo and avoid git submodules.
Now when you find a file has made it into your repo like .DS_Store just remove it, and move on. Make sure you add it to the .gitignore file that is checked into the project.
As for xcodeproj... there shouldn't be that much customization within the file that is user specific since the above mentioned gitignore filters that out. If a scheme is to be shared make sure you check shared under Manage Schemes and you will check in files in that subdirectory. You should be using automatic selection of certificates so the only real choice is Developer or Distribution. You should also take advantage of variables provided within Xcode that avoid hardcoding complete paths. When trying to think of an example Plists came to mind, in this case, you might have written /Users/me/MyProject/Resources/MyProject.plist, but instead should use $(SRCROOT)/resources/MyProject.plist.
So, I am working on a project with XCode. Happily, I found out that it keeps an Git repository within every project. So, after a mistake on a code, i just used
git checkout aux.c
to move back from theses mistakes. Unfortunately, as i just found out, Xcode does not auto-commit, so, I ended up with a blank file.
I didn't commited anything after this, but still can't figure out how to undo this checkout.
Sorry, you can't. :-( You're going to have to replace the file some other way.
There are two places where git tracks your files - commits, and the index/staging area. Since there was no commit, and you checked the version of the file out of the staging area, there's no other place it would be.
Do run git status just in case, to make sure it doesn't still show staged changes to that file.
Any chance you had it open in an editor still and could undo the changes to the file that git checkout made? Some editors like Textmate and SublimeText will allow that; others don't.
If the file has never been committed to the repository then unfortunately you are out of luck.
From the sounds of it, you simply have an empty git repository, which will mean your file has been lost and something Versions (which comes with Lion) or Time Machine may be your best bet at recovering from your mistake.
To confirm if anything has been committed to the repository, use git log. If you get an empty response then you're out of luck on the git front.
Unfortunately, this probably this isn't the answer you were looking for.
In fact, undoing a first commit on git is impossible. So, if you are running Xcode, commit manually frequently.
But, there is another way.
If you are running OS X 10.7 Lion or latter (not sure about Snow Leopard), you can try to use the versions feature from OS X to recover any file. Too late for me, but it should work
Best way to recover if your uncommitted changes would be to go to (Left Pane) Source Control Navigator -> Stashed Changes -> Look for a file which dated/timed earlier than your commit which you would like to reverse and click to apply stash changes to the file. That would bring back all the unsaved files back.
When committing changes to GIT repo, i see constant updates coming from the xcuserstate files.
What are those?
xcuserstate files are generated from within Xcode and saved in your project bundle to remember your last opened file, the open state of any group folders, open tabs, and any other user setting your project might need to remember. For purposes of revision control, you should ignore them or leave them out if at all possible.
I'm seeing some strange behavior with Xcode 4 and git.
Create a new project
Right click on files - choose source control then commit. Add a comment.
Choose source control then push from the file menu.
Xcode returns an error complaining about uncommitted changes?!?
Calling git status from the command line, I can see that some of the internal userdata files are not committed. Shouldn't Xcode know to either skip or include those? There is no indication in Xcode that there are any uncommitted files. The only way to find them is from the command line.
One thought would be to manually create a .gitignore file, but I would assume that Xcode handles all that internally.
Did I just stumble onto a bug, or is there some standard step that I'm missing?
Thanks!
Well, a bug is in the eyes of the beholder, isn't it. Yes, you need to Setup your git ignores for xcode.