Git ignore file for Xcode projects

Question

Which files should I include in .gitignore when using Git in conjunction with Xcode?

Check `https://www.gitignore.io/api/swift,xcode,Cobjective-c,osx` — geekay, Jul 27 '16 at 04:30
Above link produces an error: https://www.gitignore.io/api/swift,xcode,objective-c,osx — the Reverend, May 28 '19 at 15:45

score 729 · Accepted Answer · edited Aug 04 '19 at 19:51

729

I was previously using the top-voted answer, but it needs a bit of cleanup, so here it is redone for Xcode 4, with some improvements.

I've researched every file in this list, but several of them do not exist in Apple's official Xcode documentation, so I had to go on Apple mailing lists.

Apple continues to add undocumented files, potentially corrupting our live projects. This IMHO is unacceptable, and I've now started logging bugs against it each time they do so. I know they don't care, but maybe it'll shame one of them into treating developers more fairly.

If you need to customize, here's a gist you can fork: https://gist.github.com/3786883

#########################
# .gitignore file for Xcode4 and Xcode5 Source projects
#
# Apple bugs, waiting for Apple to fix/respond:
#
#    15564624 - what does the xccheckout file in Xcode5 do? Where's the documentation?
#
# Version 2.6
# For latest version, see: http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects
#
# 2015 updates:
# - Fixed typo in "xccheckout" line - thanks to @lyck for pointing it out!
# - Fixed the .idea optional ignore. Thanks to @hashier for pointing this out
# - Finally added "xccheckout" to the ignore. Apple still refuses to answer support requests about this, but in practice it seems you should ignore it.
# - minor tweaks from Jona and Coeur (slightly more precise xc* filtering/names)
# 2014 updates:
# - appended non-standard items DISABLED by default (uncomment if you use those tools)
# - removed the edit that an SO.com moderator made without bothering to ask me
# - researched CocoaPods .lock more carefully, thanks to Gokhan Celiker
# 2013 updates:
# - fixed the broken "save personal Schemes"
# - added line-by-line explanations for EVERYTHING (some were missing)
#
# NB: if you are storing "built" products, this WILL NOT WORK,
# and you should use a different .gitignore (or none at all)
# This file is for SOURCE projects, where there are many extra
# files that we want to exclude
#
#########################

#####
# OS X temporary files that should never be committed
#
# c.f. http://www.westwind.com/reference/os-x/invisibles.html

.DS_Store

# c.f. http://www.westwind.com/reference/os-x/invisibles.html

.Trashes

# c.f. http://www.westwind.com/reference/os-x/invisibles.html

*.swp

#
# *.lock - this is used and abused by many editors for many different things.
#    For the main ones I use (e.g. Eclipse), it should be excluded
#    from source-control, but YMMV.
#   (lock files are usually local-only file-synchronization on the local FS that should NOT go in git)
# c.f. the "OPTIONAL" section at bottom though, for tool-specific variations!
#
# In particular, if you're using CocoaPods, you'll want to comment-out this line:
*.lock


#
# profile - REMOVED temporarily (on double-checking, I can't find it in OS X docs?)
#profile


####
# Xcode temporary files that should never be committed
# 
# NB: NIB/XIB files still exist even on Storyboard projects, so we want this...

*~.nib


####
# Xcode build files -
#
# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "DerivedData"

DerivedData/

# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "build"

build/


#####
# Xcode private settings (window sizes, bookmarks, breakpoints, custom executables, smart groups)
#
# This is complicated:
#
# SOMETIMES you need to put this file in version control.
# Apple designed it poorly - if you use "custom executables", they are
#  saved in this file.
# 99% of projects do NOT use those, so they do NOT want to version control this file.
#  ..but if you're in the 1%, comment out the line "*.pbxuser"

# .pbxuser: http://lists.apple.com/archives/xcode-users/2004/Jan/msg00193.html

*.pbxuser

# .mode1v3: http://lists.apple.com/archives/xcode-users/2007/Oct/msg00465.html

*.mode1v3

# .mode2v3: http://lists.apple.com/archives/xcode-users/2007/Oct/msg00465.html

*.mode2v3

# .perspectivev3: http://stackoverflow.com/questions/5223297/xcode-projects-what-is-a-perspectivev3-file

*.perspectivev3

#    NB: also, whitelist the default ones, some projects need to use these
!default.pbxuser
!default.mode1v3
!default.mode2v3
!default.perspectivev3


####
# Xcode 4 - semi-personal settings
#
# Apple Shared data that Apple put in the wrong folder
# c.f. http://stackoverflow.com/a/19260712/153422
#     FROM ANSWER: Apple says "don't ignore it"
#     FROM COMMENTS: Apple is wrong; Apple code is too buggy to trust; there are no known negative side-effects to ignoring Apple's unofficial advice and instead doing the thing that actively fixes bugs in Xcode
# Up to you, but ... current advice: ignore it.
*.xccheckout

#
#
# OPTION 1: ---------------------------------
#     throw away ALL personal settings (including custom schemes!
#     - unless they are "shared")
# As per build/ and DerivedData/, this ought to have a trailing slash
#
# NB: this is exclusive with OPTION 2 below
xcuserdata/

# OPTION 2: ---------------------------------
#     get rid of ALL personal settings, but KEEP SOME OF THEM
#     - NB: you must manually uncomment the bits you want to keep
#
# NB: this *requires* git v1.8.2 or above; you may need to upgrade to latest OS X,
#    or manually install git over the top of the OS X version
# NB: this is exclusive with OPTION 1 above
#
#xcuserdata/**/*

#     (requires option 2 above): Personal Schemes
#
#!xcuserdata/**/xcschemes/*

####
# Xcode 4 workspaces - more detailed
#
# Workspaces are important! They are a core feature of Xcode - don't exclude them :)
#
# Workspace layout is quite spammy. For reference:
#
# /(root)/
#   /(project-name).xcodeproj/
#     project.pbxproj
#     /project.xcworkspace/
#       contents.xcworkspacedata
#       /xcuserdata/
#         /(your name)/xcuserdatad/
#           UserInterfaceState.xcuserstate
#     /xcshareddata/
#       /xcschemes/
#         (shared scheme name).xcscheme
#     /xcuserdata/
#       /(your name)/xcuserdatad/
#         (private scheme).xcscheme
#         xcschememanagement.plist
#
#

####
# Xcode 4 - Deprecated classes
#
# Allegedly, if you manually "deprecate" your classes, they get moved here.
#
# We're using source-control, so this is a "feature" that we do not want!

*.moved-aside

####
# OPTIONAL: Some well-known tools that people use side-by-side with Xcode / iOS development
#
# NB: I'd rather not include these here, but gitignore's design is weak and doesn't allow
#     modular gitignore: you have to put EVERYTHING in one file.
#
# COCOAPODS:
#
# c.f. http://guides.cocoapods.org/using/using-cocoapods.html#what-is-a-podfilelock
# c.f. http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
#
#!Podfile.lock
#
# RUBY:
#
# c.f. http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
#
#!Gemfile.lock
#
# IDEA:
#
# c.f. https://www.jetbrains.com/objc/help/managing-projects-under-version-control.html?search=workspace.xml
# 
#.idea/workspace.xml
#
# TEXTMATE:
#
# -- UNVERIFIED: c.f. http://stackoverflow.com/a/50283/153422
#
#tm_build_errors

####
# UNKNOWN: recommended by others, but I can't discover what these files are
#

edited Aug 04 '19 at 19:51

Peter Mortensen

30,738
21
105
131

answered Aug 18 '12 at 19:22

Adam

32,900
16
126
153

I assumed you meant a gist - seeing as the official github project for .gitignores was unmaintained and refusing submissions last time I looked (IIRC there were 200 ignored pull requests, and a huge number of Issues that were being ignored) – Adam Sep 26 '12 at 08:52
1

Ok, I just noticed a problem with this. I was doing some git acrobatics, and when I checkout out back to master and applied my stashed changes, I had lost my saved build schemes! fortunately, I had backed them up, just in case... but the solution is to ignore a little more specifically inside the xcuserdata directory. I changed `xcuserdata` to `xcdebugger` and `UserInterfaceState.xcuserstate`, which are really the offensive ones to commit. – samson Nov 02 '12 at 21:45
I also suggest to add .svn for projects that work with both source control systems – Michael Kessler Nov 07 '12 at 17:08
@samson - " I had lost my saved build schemes! " -- argh! That's what I was trying to avoid! Sorry :(. I've added an exception for "xcschemes" which seems to be what my Xcode is using – Adam Nov 08 '12 at 17:09
@MichaelKessler I can see that helping for some projects, but using one project with two SCM's sounds very unusual (dangerous in many ways). I've been on projects where we did it deliberately - but 9 times in 10 when I've seen it, it was an accident. In most cases, I think it's a major bug / mistake to have two SCM's versioning one set of files, so I'd rather leave the .svn folder in there -- for most people, they'll see all the .svn files appear and go "WTF?" and realise their mistake. – Adam Nov 11 '12 at 16:34
@Adam, In general you are right - there is almost no reason to work with 2 SCMs on one project. But I have personally used this approach several times. The most common (for me) case was when a client gives me his existing project with SVN. I work with GIT. I think that there was no project where SVN worked 100% well for me - there are always problems with it. This is why I always create my own git repository for all the ongoing commits and ignore the .svn folders. Eventually I commit all the changes to client's SVN and forget about it. – Michael Kessler Nov 12 '12 at 08:26
I added cocoapods to the mix – cannyboy Feb 08 '13 at 12:40
76

You shouldn't be ignoring `*.lock` or `Podfile.lock` (never mind the redundancy). You want the exact same versions installed in all workspaces, you don't want the "latest version". – tvon Apr 17 '13 at 13:58
10

I have removed the Podfile part. I didn't add that originally, SO says someone else added it and I carelessly copy/pasted it into the gist. My apologies for any/all confusion and misunderstanding. I really dislike the way StackOverflow lets anyone edit your answers :(. – Adam Apr 17 '13 at 14:22
@Adam Thanks, though the `*.lock` line will still cause problems. If you are using bundler then a Gemfile.lock is important (and I'm not sure what that line is trying to do anyway, I've never had random `.lock` files show up). – tvon Apr 17 '13 at 14:37
6

There's now an explanation line for EVERYTHING, line by line. This should make it much clearer, and make it easier to customize for your own projects. – Adam Apr 19 '13 at 13:21
@Adam: Thanks for this! Notice that the gist link still points to v2.0 instead of v2.1. – Ricardo Sanchez-Saez Aug 15 '13 at 22:18
1

@skywinder - do you have a reference to Xcode docs on this? Ideally a URL to a paragraph in Apple's docs that states what xccheckout files contain. I'm being hyper-cautious about adding more files to gitignore - one mistake, and we could cause someone to lose their important work! – Adam Nov 13 '13 at 01:09
3

@Adam As I can see, this file contains VCS metadata, and should therefore not be checked into the VCS. No, there no mentions on `developer.apple.com` about `xccheckout`. But on official github page, this file included already in the gitignore file. `https://github.com/github/gitignore/blob/master/Objective-C.gitignore` – skywinder Nov 13 '13 at 04:20
2

@skywinder According to this answer on SO you may be wrong: http://stackoverflow.com/a/19260712/153422 - that file is important. I will NOT ignore files until you can prove they are irrelevant - if we get it wrong, the damage is great. The "official github page" IS CONSISTENTLY WRONG (you really shouldn't use it), and is definitely NOT an argument for doing it right! – Adam Dec 02 '13 at 15:04
1

6 weeks later, and Apple still hasn't replied to my request for docs on "what" xccheckout file contains :(. I guess we won't be getting any docs. – Adam Jan 19 '14 at 23:26
Update: It's been 4 *months* and ... Apple still hasn't responded to the bug report. Recommendation: don't file bug reports with Apple, it's a waste of your time :( – Adam Apr 07 '14 at 15:41
i have added all the above code in .gitignore file.. still i get the same error "uncommited changes" with the file UserInterfaceState.xcuserstate – Mano May 21 '14 at 16:42
@ManojEllappan If you've previously committed a file, Git will "ignore the ignore" and continue to track it (this is a slightly annoying feature of git). There's SO.com answers on how to fix this, look for "remove ignored files from git" or similar. – Adam Jul 11 '14 at 14:56
1

NB: current version has some improvemetns and more "optional" features. TODAY we can safely add CocoaPods and Ruby, even for people that don't use them - but I don't want to add sections for every non-Apple programming language just because "someone might" use it - if you're using non-Apple tools with Xcode, that's your responsibility. But we CAN make it easier for you: I've added an "optionals" section at bottom. Uncomment lines for your specific setup. BUT NOTE: this will be less-well tested than the main gitignore - use at own risk! – Adam Oct 11 '14 at 14:14
1

ALSO: anyone else that is regularly using non-Apple tools with Xcode, and has ignore lines to add - please add comments and/or comment on the GitHub gist, and I'll add them (commented out by default) to the OPTIONALS section. As always, I'll need a URL from you that has docs explaining why you want that change :) – Adam Oct 11 '14 at 14:15
Help me understand why we would be ignoring *.nib files please. – Alex Zavatone Dec 09 '14 at 18:13
@AlexZavatone We're not. Look at that line carefully - there's an extra character. As per the comment above. – Adam Dec 12 '14 at 14:22
Not understanding how the comment about xib and nib files is relevant to the *~.nib files. You just say "so we want this", you don't say what the *~.nib files are. I'm inferring that these are some type of temp file for a .nib file when the file is being saved. Am I correct here? What is a *~.nib file? – Alex Zavatone Dec 12 '14 at 17:57
@AlexZavatone AFAIAA, *~.nib will, by (Apple's) definition, never match a NIB file, unless you happened to rename a NIB file to (from Apple's definition) an illegal name. This is all Apple standard stuff, if you googled tilde-filenames in OS X I'm sure you'd find lots of info. – Adam Dec 14 '14 at 19:57
Yeah, I have looked for it. I've never seen it. What is it? Why would we have to ignore it? Simply, what is it? I've looked, trust me. Wasted too much time looking and Google doesn't return anything useful. – Alex Zavatone Dec 15 '14 at 03:47
1

What about the `.original` files that file merge creates? – Robert Jan 28 '15 at 17:48
@robert - link? Happy to add if appropriate, but need primary evidence / official docs to reference in each case. I haven't seen .original before, maybe because using different workflow on merging? – Adam Feb 15 '15 at 22:05
@Adam a little typo: "xcsshareddata" should be "xcshareddata". Thanks for the great answer! – jcsahnwaldt Reinstate Monica May 10 '15 at 03:48
@Adam xcuserdata should be xcuserdata/ – Cœur May 13 '15 at 03:46
@skywinder More than a year later, still no reply from Apple, and in practice the .xccheckout file seems to cause more harm than good (I've seen a few people get bitten by it). So I've added it to ignore, but with lengthy explanation. If anyone has a problem with this, please shout! I asked-around but no-one had had problems with ignoring it, so I believe it's safe to ignore. – Adam May 15 '15 at 09:45
@SteveSchwarcz I've not been doing much with Xcode6 (mostly maintenance updates of existing apps), but so far this gitignore has been working fine for me. If you have any specific issues/tweaks, please share links and I'll review them. – Adam May 15 '15 at 09:46
@Adam Confirm! `xccheckout` is dummy and cause a lot of redundant changes in case of forking repo! Get rid of this! – skywinder May 15 '15 at 12:31
It's better to just ignore `.idea/workspace.xml` instead of the whole directory since you find a lot of project related settings in the `.idea` folder. For example code styling, shared search settings, code inspection settings, all of these should be shared within the team. – hashier Jun 29 '15 at 16:11
@hashier can you provide a link explaining that? – Adam Jul 01 '15 at 08:32
@adam It's mostly found out by testing and bits and pieces from the documentation. If you define `coding styles` or `search paths` and mark them as shared they end up in the `.idea` folder in respectively file names. If you don't mark them `shared` they are added to the workspace file. Here are two helpful links: https://www.jetbrains.com/objc/help/managing-projects-under-version-control.html?search=workspace.xml and https://www.jetbrains.com/objc/help/synchronizing-and-sharing-preferences.html?search=workspace.xml so apparently `.idea/tasks.xml` and some others should be excluded as well – hashier Jul 01 '15 at 09:10
@adam I could only get xccheckout ignored in XCode by prefixing it with an asterisk - just like it's done in the last line of the file. The stuff about xccheckout at the bottom should really be removed or moved up to the place where it's ignored as the file is now - it's a duplicate. – Lyck Jul 24 '15 at 11:59
@lyck thanks - I thought I'd already edited that out, but apparently I didn't hit save. Stupid mistake, my bad. – Adam Aug 02 '15 at 12:12
@adam After seeing links like this: https://github.com/search?utf8=✓&q=filename%3Aid_rsa&type=Code&ref=searchresults I've started ignoring .ssh/* id_rsa* id_dsa* as well. Just to avoid accidental inclusion. – Dave Wood Sep 03 '15 at 07:04
@Adam - your gist is still on v2.5, perhaps you should update (currently v2.6 here) – foundry Sep 19 '15 at 13:46
@scottyb - I haven't seen any problems yet, but Apple has probably added some additional files we need to consider carefully. Please be careful and if you notice any problems with xcode, check if there's files outside git that are unexpected – Adam Sep 25 '15 at 13:51
@Adam It'd be nice to get *.xcscmblueprint added to this document. ( http://stackoverflow.com/questions/31584297/xcode-7-ignore-xcscmblueprint-in-repository ) And thank you for maintaining such a useful document! – Nate Chandler Nov 11 '15 at 17:13
This just drives me crazy. Breakpoints_v2.xcbkptlist still gets tracked and commited. Incredible annoying and I cannot do anything about it. – Teddy Dec 19 '15 at 15:33
@Teddy - if you can find a URL to official page describing that file and its contents, or a 3rd party detailed investigation (so we can be 99% sure we've understood it correctly), I'll add some sections for it, and whatever variants there are. – Adam Dec 28 '15 at 13:46
@Adam: I am not sure what you want from me. An example of "Breakpoints_v2.xcbkptlist" file? I can upload, no problem. But to be honest I do not understand why the content matters if I add *.xcbkptlist files to the ignore list. Should not it just skip the file completely regardless the content? – Teddy Dec 28 '15 at 14:42
4

Without official description, we're not going to ignore anything. Almost every time people have done that, it's corrupted someone's project sooner or later. Way too dangerous - don't go there. So I refuse to add anything to this file unless I have a verifiable source confirming it is safe to ignore! – Adam Dec 28 '15 at 14:55
OK, I got your point. The thing is that you have added it because it is under "xcuserdata/". Yet git tracks the file. All other files under xcuserdata are properly ignored except for the breakpoints file (breakpoints_v2 file contains information about the breakpoints you set up for debugging in Xcode). I do not understand why. – Teddy Dec 28 '15 at 15:18
I'm not sure *duplicating* the file that's stored on an actual source control hosting site is wise. – jpmc26 Nov 24 '16 at 01:33
3

@user770 the file on that site is borderline malicious. Whoever committed it clearly either has NO IDEA what they're doing, or wants to mess up other people's projects. As I keep saying: DO. NOT. TAKE. RANDOM. INTERNET. GITIGNORES. FROM. IDIOTS. WHO. DON'T. EXPLAIN. EVERY. LINE! – Adam May 12 '18 at 21:23
Following most of these practices and yet i still occasionally get podfile out-of-sync issues between branches. So annoying. Makes me want to ignore the pod control files completely. – drew.. Jun 01 '18 at 12:48
@Adam "...but maybe it'll shame one of them into treating developers more fairly." - hope is the last to die eh? But in earnest: good on ya, we can only try! – GrayedFox May 18 '22 at 05:57
Is this unchanged for SwiftUI? – Jun 13 '22 at 02:32

Hagelin · Answer 2 · 2011-02-16T12:00:24.017

276

Based on this guide for Mercurial my .gitignore includes:

.DS_Store
*.swp
*~.nib

build/

*.pbxuser
*.perspective
*.perspectivev3

I've also chosen to include:

*.mode1v3
*.mode2v3

which, according to this Apple mailing list post, are "user-specific project settings".

And for Xcode 4:

xcuserdata

edited Feb 16 '11 at 12:00

answered Sep 08 '08 at 11:14

Hagelin

16,440
5
29
37

53

I don't particularly like the *.pbxuser/*.perspective/*.perspectivev3 patterns. I much prefer the following *.xcodeproj/* !*.xcodeproj/project.pbxproj That ignores everything inside a *.xcodeproj except the project.pbxproj. – Lily Ballard Mar 15 '09 at 20:33
6

I do not ignore *.pbxuser, *.perspective and *.perspectivev3 because I like to keep those settings back when I clone my repository. – lajos May 27 '09 at 05:57
3

Use build/ to exclude only directories named build in case you might have a script or something named build that you don't want to ignore. – nicerobot Jul 03 '09 at 20:16
1

I like to leave in build/Release-iphoneos so I have a copy of every released device app I seed out to people. Patterns to add would be build/Debug-* and build/*-iphonesimulator . – Ryan McCuaig Oct 17 '09 at 20:32
1

I'm not sure if I'd keep this in my repository. Perhaps a better solution would be to keep your build folder outside of your project in some central location (e.g. /builds/projectname/**) and keep the /builds directory backed up with something like GetDropbox? – Luke Redpath Jan 20 '10 at 23:19
8

Also you might want to add that you can make a "global" gitignore file like this: git config --global core.excludesfile ~/.gitignore – Jess Bowers Apr 27 '10 at 14:56
1

I agree with Luke regarding his hesitation to keep the build directory version controlled in the same repository. In any case, if you often integrate external libraries and projects into your xcode projects, you should configure your build directory to be common anyway. I typically keep mine in /Users/Shared//Products – memmons Oct 25 '10 at 15:32
65

I'd like to caution everyone who added .gitignore file **after** they have committed the project: those files you ignore are still being tracked. You'll have to remove them from git manually using `git rm --cached ` – pixelfreak Jun 27 '11 at 01:44
2

Using xcuserdata is bad as it prevents your xcschemes directory from being version controlled. – Erik Jul 06 '11 at 04:29
3

In Xcode 4, it appears that the only files to worry about are xcuserdata directories and .DS_Store, and the rest aren't needed in .gitignore. I have an active project that's never been opened in XCode 3, but only in v4, and none of the other files were present in my file hierarchy. It uses Storyboard instead of .xib's for the views. My config is normal too, i.e. no "weird" customizations like moving the build directory from its default location. – curtisdf Apr 16 '12 at 22:24
2

According to http://stackoverflow.com/a/9552687/599884 and https://github.com/github/gitignore/blob/master/Objective-C.gitignore it seems to be a good idea to also ignore xcworkspace – Christoph Apr 18 '12 at 15:21
3

The comment @KevinBallard is extremely useful, except that it contains a small oversight. `*.xcworkspace/* !*.xcworkspace/ !*.xcworkspace/contents.xcworkspacedata` works, since it first blacklists every **file** in the project folder, then whitelists the folder itself and then whitelist the project file. This way, the entire folder will not be blacklisted, which causes git to skip it entirely. – SpacyRicochet May 10 '12 at 13:17
22

@SpacyRicochet: Comment formatting has apparently changed since I wrote the comment. Hence the italics. My pattern is supposed to look like \*.xcodeproj/\* !\*.xcodeproj/project.pbxproj. Of course, these days you do need to adjust it for workspaces. – Lily Ballard May 10 '12 at 19:14
Shouldn't you use `*.sw?` instead of `*.swp`? Vim will create multiple swap files for multiple concurrent editing sessions, and name them .swo, .swn, etc. – SilverWolf Jan 19 '18 at 19:51

Abizern · Answer 3 · 2012-03-19T18:30:21.610

Regarding the 'build' directory exclusion -

If you place your build files in a different directory from your source, as I do, you don't have the folder in the tree to worry about.

This also makes life simpler for sharing your code, preventing bloated backups, and even when you have dependencies to other Xcode projects (while require the builds to be in the same directory as each other)

You can grab an up-to-date copy from the Github gist https://gist.github.com/708713

My current .gitignore file is

# Mac OS X
*.DS_Store

# Xcode
*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
*.xcuserstate
project.xcworkspace/
xcuserdata/

# Generated files
*.o
*.pyc


#Python modules
MANIFEST
dist/
build/

# Backup files
*~.nib

I do have the build folder outside of the project folder, but when other users build the project, it by default is recreated in the project- so I found that adding it to the ignore file is a better solution, otherwise it gets readded in their commits. — lajos, May 27 '09 at 05:53

score 59 · Answer 4 · answered Oct 13 '10 at 14:09

59

For Xcode 4 I also add:

YourProjectName.xcodeproj/xcuserdata/*
YourProjectName.xcodeproj/project.xcworkspace/xcuserdata/*

answered Oct 13 '10 at 14:09

Vladimir Mitrovic

1,780
17
15

80

If you just add `xcuserdata`, then that takes care of both. – ma11hew28 Apr 12 '11 at 18:13
7

For some reason just adding xcuserdata without the prefix didn't work for me. I thought it should, though. Odd. – BastiBen Dec 02 '13 at 14:22

Eric · Answer 5 · 2015-06-22T10:41:26.457

18

The people of GitHub have exhaustive and documented .gitignore files for Xcode projects:

Swift: https://github.com/github/gitignore/blob/master/Swift.gitignore

Objective-C: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

edited Jun 22 '15 at 10:41

answered Aug 04 '12 at 18:30

Eric

16,003
15
87
139

5

This has already been posted to one of the answers above. I found it to be: incorrect, questionably supported (more than 100 outstanding pull requests!), and undocumented. The fact that it's "incorrect" is the worst of all; they have made an ignore that only works for a narrow set of uses and haven't explained what or why! Hence: my answer above, which corrects their bugs AND explains what's being done and why, so you can make educated decisions on a project-by-project basis (on a new project, I sometimes forget why some of the items are in there - the comments help me decide :)) – Adam Oct 14 '12 at 16:42
@Adam: GitHub's `.gitignore` has now been updated for Xcode 6.3.2 and Swift, so it's now correct. It's also documented. – Eric Jun 22 '15 at 10:40
yeah, but the problem with publishing a data-destructive file and keeping it that way for months or years - and apparently not bothering to test it properly - is that you permanently sacrifice all faith, trust, respect from the community. Too late. – Adam Jun 26 '15 at 11:45

score 18 · Answer 6 · edited Aug 04 '19 at 19:56

18

You should checkout gitignore.io for Objective-C and Swift.

Here is the .gitignore file I'm using:

# Xcode
.DS_Store
*/build/*
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata
profile
*.moved-aside
DerivedData
.idea/
*.hmap
*.xccheckout
*.xcworkspace
!default.xcworkspace

#CocoaPods
Pods

edited Aug 04 '19 at 19:56

Peter Mortensen

30,738
21
105
131

answered Sep 25 '14 at 09:14

onmyway133

45,645
31
257
263

1

always use your example. nice settings! Thanks! – Nikolay Shubenkov Oct 30 '14 at 07:38
I haven't used http://gitignore.io for a while - worth checking if you haven't. You can use it to create a `gitignore` file for whatever IDE / language etc you're using. It'll even add a cocoapods section. Brilliant – Ashley Mills Sep 04 '18 at 15:19

Wanbok Choi · Answer 7 · 2013-07-29T17:41:55.197

14

I'm using both AppCode and XCode. So .idea/ should be ignored.

append this to Adam's .gitignore

####
# AppCode
.idea/

edited Jul 29 '13 at 17:41

answered Apr 17 '13 at 13:57

Wanbok Choi

5,432
1
21
26

score 13 · Answer 8 · edited Aug 04 '19 at 20:04

Adding a .gitignore file for

Mac OS X + Xcode + Swift

This is how I have added a .gitignore file into my Swift project:

Select you project in Xcode and right click → New Group → name it "Git"
Select the Git folder and right click → Add new file
Within the iOS tab → select Other → empty file

Give the file name here ".gitignore"

Confirm the file name and type

Here is the result structure:

Open the file and past the below code

# file

#########################################################################
#                                                                       #
#       Title         - .gitignore file                                 #
#       For           - Mac OS X, Xcode 7 and Swift Source projects     #
#       Updated by    - Ramdhan Choudhary                               #
#       Updated on    - 13 - November - 2015                            #
#                                                                       #
#########################################################################

########### Xcode ###########
# Xcode temporary files that should never be committed

## Build generated
build/
DerivedData

# NB: NIB/XIB files still exist even on Storyboard projects, so we want this
*~.nib
*.swp

## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata

## Other
*.xccheckout
*.moved-aside
*.xcuserstate
*.xcscmblueprint
*.xcscheme

########### Mac OS X ###########
# Mac OS X temporary files that should never be committed

.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

########## Objective-C/Swift specific ##########
*.hmap
*.ipa

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/

# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts

Carthage/Build

# fastlane
#
# It is recommended to not store the screenshots in the Git repository. Instead, use fastlane to re-generate the

fastlane/report.xml
fastlane/screenshots

Well, thanks to Adam. His answer helped me a lot, but still I had to add a few more entries as I wanted a .gitignore file for:

Mac OS X + Xcode + Swift

References: this and this

Very useful answer. I added it as a link in my [Setting Up Github in Xcode](http://stackoverflow.com/a/32498035/3681880) answer. — Suragch, Jul 13 '16 at 21:37

BB9z · Answer 9 · 2023-04-16T17:15:55.457

Most of the answers are from the Xcode 4-5 era. I recommend an ignore file in a modern style.

# Xcode Project
**/*.xcodeproj/xcuserdata/
**/*.xcworkspace/xcuserdata/
**/.swiftpm/xcode/xcuserdata/
**/*.xcworkspace/xcshareddata/IDEWorkspaceChecks.plist
**/*.xcworkspace/xcshareddata/*.xccheckout
**/*.xcworkspace/xcshareddata/*.xcscmblueprint
**/*.playground/**/timeline.xctimeline
.idea/

# Build
**/.build/
**/Build/
DerivedData/
*.ipa

# Carthage
Carthage/

# CocoaPods
Pods/

# fastlane
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output
fastlane/sign&cert

# CSV
*.orig
.svn

# Other
*~
.DS_Store
*.swp
*.save
._*
*.bak

Keep it updated from: https://github.com/BB9z/iOS-Project-Template/blob/master/.gitignore

score 9 · Answer 10 · edited Aug 04 '19 at 19:54

9

Mine is a .bzrignore, but it is the same idea :)

.DS_Store
*.mode1v3
*.pbxuser
*.perspectivev3
*.tm_build_errors

The tm_build_errors is for when I use TextMate to build my project. It is not quite as comprehensive as Hagelin, but I thought it was worth posting for the tm_build_errors line.

edited Aug 04 '19 at 19:54

Peter Mortensen

30,738
21
105
131

answered Sep 08 '08 at 17:51

Dave Verwer

6,140
5
34
30

score 6 · Answer 11 · edited Aug 04 '19 at 19:55

6

For Xcode 5 I add:

####
# Xcode 5 - VCS metadata
#
*.xccheckout

From Berik's Answer

edited Aug 04 '19 at 19:55

Peter Mortensen

30,738
21
105
131

answered Oct 16 '13 at 07:00

Wanbok Choi

5,432
1
21
26

score 5 · Answer 12 · edited Aug 04 '19 at 19:58

5

Best of all,

gitignore.io

Go and choose your language, and then it'll give you the file.

edited Aug 04 '19 at 19:58

Peter Mortensen

30,738
21
105
131

answered Feb 06 '17 at 07:45

alicanbatur

2,172
1
28
36

score 4 · Answer 13 · answered Sep 25 '12 at 21:38

4

I've added:

xcuserstate
xcsettings

and placed my .gitignore file at the root of my project.

After committing and pushing. I then ran:

git rm --cached UserInterfaceState.xcuserstate WorkspaceSettings.xcsettings

buried with the folder below:

<my_project_name>/<my_project_name>.xcodeproj/project.xcworkspace/xcuserdata/<my_user_name>.xcuserdatad/

I then ran git commit and push again

answered Sep 25 '12 at 21:38

user1524957

176
2
4

Did you add it also? Or is this just all you do? – hakre Sep 26 '12 at 08:41
1

Yes, I added both but xcusersate was the main offending file. Adding that was the only way I could push my code remotely. Otherwise I was stuck in a feedback loop that required commit before push. So you commit, then Xcode 4.5 would ask you to commit again and you are never able to push because the pre req is committing. – user1524957 Oct 02 '12 at 21:59

joserock85 · Answer 14 · 2015-11-19T19:36:55.753

I use the following .gitignore file generated in gitignore.io:

### Xcode ###
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata
*.xccheckout
*.moved-aside
DerivedData
*.xcuserstate


### Objective-C ###
# Xcode
#
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata
*.xccheckout
*.moved-aside
DerivedData
*.hmap
*.ipa
*.xcuserstate

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
#
Pods/

jqgsninimo · Answer 15 · 2023-01-21T02:47:49.933

gitignore.io: Create useful .gitignore files for your project

Example: Preview | Edit
- Programming Languages: Objective-C Swift
- Build Automation Tool: SwiftPackageManager Carthage
- IDEs: Xcode
- Operating Systems: macOS

Steps to use in Terminal (Refer to the YouTube Video)

Create Git global config alias (One time only)

git config --global alias.ignore '!gi() { curl -L -s https://www.gitignore.io/api/$@ ;}; gi'

Enter the project directory
```
cd <the project directory>
```

Generate .gitignore file

git ignore Objective-C,Swift,SwiftPackageManager,Carthage,Xcode,macOS >.gitignore

Add and commit .gitignore file

git add .gitignore
git commit -m "Add .gitignore file"

score 2 · Answer 16 · answered Oct 28 '14 at 17:45

2

Here's the .gitignore that GitHub uses by default for new Xcode repositories:

https://github.com/github/gitignore/blob/master/Objective-C.gitignore

It's likely to be reasonably correct at any given time.

answered Oct 28 '14 at 17:45

funroll

35,925
7
54
59

The github .gitignore file is a collection of all files which we had problems with in the past. Right now, if you start a Xcode project from scratch an let Xcode preconfigure the git repository, there's not too much left to ignore in .gitignore: The only thing I prefer to ignore is xcuserdata/ ... this helps not to clutter your commits. – crosscode Jan 02 '15 at 17:03
GitHub is the first place I ever look for gitignores :) – Ky - Sep 12 '16 at 12:29

score 0 · Answer 17 · answered Sep 04 '13 at 08:03

We did find that even if you add the .gitignore and the .gitattribte the *.pbxproj file can get corrupted. So we have a simple plan.

Every person that codes in office simply discards the changes made to this file. In the commit we simple mention the files that are added into the source. And then push to the server. Our integration manager than pulls and sees the commit details and adds the files into the resources.

Once he updates the remote everyone will always have a working copy. In case something is missing then we inform him to add it in and then pull once again.

This has worked out for us without any issues.

score 0 · Answer 18 · answered Jan 15 '18 at 17:48

I recommend using joe to generate a .gitignore file.

For an iOS project run the following command:

$ joe g osx,xcode > .gitignore

It will generate this .gitignore:

.DS_Store
.AppleDouble
.LSOverride

Icon
._*

.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns

.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

build/
DerivedData

*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata

*.xccheckout
*.moved-aside
*.xcuserstate

For the next person trying to install Joe, check if it's 5+ years of dead repo resurrected before wasting time — Ely Dantas, Mar 05 '21 at 21:02

score 0 · Answer 19 · answered Nov 18 '21 at 12:12

0

If someone need a standard gitignore file as a simple way.

Just run this line in cmd/ terminal after navigating to your project.

npx gitignore Objective-C

answered Nov 18 '21 at 12:12

Alwin Jose

696
1
5
13

I studied this from https://www.youtube.com/watch?v=b0g-FJ5Zbb8 (14:50) – Alwin Jose Nov 18 '21 at 12:13
Note: Can replace Objective-C with swift, node, etc based on your requirement. – Alwin Jose Nov 18 '21 at 12:19
`-bash: npx: command not found` – Mark Apr 07 '22 at 21:14
Please install node from https://nodejs.org/en/ If still didn't work, please run the command stated in https://stackoverflow.com/a/51224061/11844048 – Alwin Jose Apr 08 '22 at 08:30

score 0 · Answer 20 · answered Nov 07 '22 at 16:02

0

This will create up-to-date gitignore file

For iOS development

git ignore swift,ios >.gitignore

For macOS development

git ignore swift,macos >.gitignore

answered Nov 07 '22 at 16:02

Ozgur Sahin

1,305
16
24

score -4 · Answer 21 · answered Jul 02 '18 at 10:24

-4

A Structure of a standerd .gitignore file for Xcode project >

.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
Icon?
ehthumbs.db
Thumbs.db
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
!default.xcworkspace
xcuserdata
profile
*.moved-aside
DerivedData
.idea/

answered Jul 02 '18 at 10:24

Rahul Singha Roy

548
1
3
13

How is this any different to any of the previous answers? Don't just paste your `gitignore` file here, this does not add anything to this subject. – Ashley Mills Sep 04 '18 at 15:08
@AshleyMills Please read the answar first then add a comment .... The answar is for a standerd structure / required ones .... which are essentials to have ... – Rahul Singha Roy Sep 06 '18 at 07:24

Git ignore file for Xcode projects

21 Answers21

Linked

Related