Git ignore file for Xcode projects

Asked 8/9, 2008 at 11:7 Answered 7/11, 2022 at 16:2

Solved xcode git macos version-control gitignore

961

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

Phelgen answered 8/9, 2008 at 11:7 Comment(2)

Check https://www.gitignore.io/api/swift,xcode,Cobjective-c,osx – Veneering 27/7, 2016 at 4:30

Above link produces an error: gitignore.io/api/swift,xcode,objective-c,osx – Luana 28/5, 2019 at 15:45

735

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: https://mcmap.net/q/12672/-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: https://mcmap.net/q/12973/-xcode-projects-what-is-a-quot-perspectivev3-file-quot

*.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. https://mcmap.net/q/12974/-should-xccheckout-files-in-xcode5-be-ignored-under-vcs
#     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. https://mcmap.net/q/12672/-git-ignore-file-for-xcode-projects
#
#tm_build_errors

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

Misalliance answered 18/8, 2012 at 19:22 Comment(52)

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) – Misalliance 26/9, 2012 at 8:52

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. – Enamelware 2/11, 2012 at 21:45

I also suggest to add .svn for projects that work with both source control systems – Coletta 7/11, 2012 at 17:8

@Enamelware - " 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 – Misalliance 8/11, 2012 at 17:9

@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. – Misalliance 11/11, 2012 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. – Coletta 12/11, 2012 at 8:26

I added cocoapods to the mix – Wolfgram 8/2, 2013 at 12:40

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". – Aleksandropol 17/4, 2013 at 13:58

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 :(. – Misalliance 17/4, 2013 at 14:22

@Misalliance 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). – Aleksandropol 17/4, 2013 at 14:37

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. – Misalliance 19/4, 2013 at 13:21

@Adam: Thanks for this! Notice that the gist link still points to v2.0 instead of v2.1. – Glottic 15/8, 2013 at 22:18

@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! – Misalliance 13/11, 2013 at 1:9

@Misalliance 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 – Karena 13/11, 2013 at 4:20

@Karena According to this answer on SO you may be wrong: https://mcmap.net/q/12974/-should-xccheckout-files-in-xcode5-be-ignored-under-vcs - 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! – Misalliance 2/12, 2013 at 15:4

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. – Misalliance 19/1, 2014 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 :( – Misalliance 7/4, 2014 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 – Submissive 21/5, 2014 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. – Misalliance 11/7, 2014 at 14:56

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! – Misalliance 11/10, 2014 at 14:14

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 :) – Misalliance 11/10, 2014 at 14:15

Help me understand why we would be ignoring *.nib files please. – Mimicry 9/12, 2014 at 18:13

@AlexZavatone We're not. Look at that line carefully - there's an extra character. As per the comment above. – Misalliance 12/12, 2014 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? – Mimicry 12/12, 2014 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. – Misalliance 14/12, 2014 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. – Mimicry 15/12, 2014 at 3:47

What about the .original files that file merge creates? – Defunct 28/1, 2015 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? – Misalliance 15/2, 2015 at 22:5

@Misalliance a little typo: "xcsshareddata" should be "xcshareddata". Thanks for the great answer! – Darren 10/5, 2015 at 3:48

@Misalliance xcuserdata should be xcuserdata/ – Degraded 13/5, 2015 at 3:46

@Karena 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. – Misalliance 15/5, 2015 at 9: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. – Misalliance 15/5, 2015 at 9:46

@Misalliance Confirm! xccheckout is dummy and cause a lot of redundant changes in case of forking repo! Get rid of this! – Karena 15/5, 2015 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. – Fish 29/6, 2015 at 16:11

@Fish can you provide a link explaining that? – Misalliance 1/7, 2015 at 8: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: jetbrains.com/objc/help/… and jetbrains.com/objc/help/… so apparently .idea/tasks.xml and some others should be excluded as well – Fish 1/7, 2015 at 9: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. – Stockton 24/7, 2015 at 11:59

@lyck thanks - I thought I'd already edited that out, but apparently I didn't hit save. Stupid mistake, my bad. – Misalliance 2/8, 2015 at 12:12

@adam After seeing links like this: 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. – Defilade 3/9, 2015 at 7:4

@Misalliance - your gist is still on v2.5, perhaps you should update (currently v2.6 here) – Moultrie 19/9, 2015 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 – Misalliance 25/9, 2015 at 13:51

@Misalliance It'd be nice to get *.xcscmblueprint added to this document. ( stackoverflow.com/questions/31584297/… ) And thank you for maintaining such a useful document! – Sacci 11/11, 2015 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. – Stalagmite 19/12, 2015 at 15:33

@Stalagmite - 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. – Misalliance 28/12, 2015 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? – Stalagmite 28/12, 2015 at 14:42

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! – Misalliance 28/12, 2015 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. – Stalagmite 28/12, 2015 at 15:18

I'm not sure duplicating the file that's stored on an actual source control hosting site is wise. – Handbarrow 24/11, 2016 at 1:33

@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! – Misalliance 12/5, 2018 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. – Decurion 1/6, 2018 at 12:48

@Misalliance "...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! – Kat 18/5, 2022 at 5:57

Is this unchanged for SwiftUI? – Shadwell 13/6, 2022 at 2:32

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

Phelgen answered 8/9, 2008 at 11:14 Comment(14)

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. – Enchantress 15/3, 2009 at 20:33

I do not ignore *.pbxuser, *.perspective and *.perspectivev3 because I like to keep those settings back when I clone my repository. – Workingwoman 27/5, 2009 at 5:57

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. – Orinasal 3/7, 2009 at 20:16

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 . – Mccartan 17/10, 2009 at 20:32

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? – Sexed 20/1, 2010 at 23:19

Also you might want to add that you can make a "global" gitignore file like this: git config --global core.excludesfile ~/.gitignore – Frailty 27/4, 2010 at 14:56

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/<username>/Products – Marindamarinduque 25/10, 2010 at 15:32

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 <files> – Linder 27/6, 2011 at 1:44

Using xcuserdata is bad as it prevents your xcschemes directory from being version controlled. – Sungsungari 6/7, 2011 at 4:29

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. – Absa 16/4, 2012 at 22:24

According to https://mcmap.net/q/12976/-what-is-the-39-standard-39-content-of-gitignore-for-an-iphone-xcode-project and github.com/github/gitignore/blob/master/Objective-C.gitignore it seems to be a good idea to also ignore xcworkspace – Booster 18/4, 2012 at 15:21

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. – Melisent 10/5, 2012 at 13:17

@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. – Enchantress 10/5, 2012 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. – Lorindalorine 19/1, 2018 at 19:51

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

Antibiosis answered 8/12, 2008 at 10:42 Comment(1)

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. – Workingwoman 27/5, 2009 at 5:53

For Xcode 4 I also add:

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

Femmine answered 13/10, 2010 at 14:9 Comment(2)

If you just add xcuserdata, then that takes care of both. – Veal 12/4, 2011 at 18:13

For some reason just adding xcuserdata without the prefix didn't work for me. I thought it should, though. Odd. – Spiel 2/12, 2013 at 14:22

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

Sundberg answered 4/8, 2012 at 18:30 Comment(3)

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 :)) – Misalliance 14/10, 2012 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. – Sundberg 22/6, 2015 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. – Misalliance 26/6, 2015 at 11:45

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

Salute answered 25/9, 2014 at 9:14 Comment(2)

I haven't used 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 – Anaphora 4/9, 2018 at 15:19

you should keep *.xcworkspace file which could be the main project file – Neile 2/12, 2023 at 0:52

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

append this to Adam's .gitignore

####
# AppCode
.idea/

Chirp answered 17/4, 2013 at 13:57 Comment(0)

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

Saxe answered 28/11, 2018 at 8:23 Comment(0)

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

Reparation answered 13/11, 2015 at 8:39 Comment(1)

Very useful answer. I added it as a link in my Setting Up Github in Xcode answer. – Harpsichord 13/7, 2016 at 21:37

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.

Jaipur answered 8/9, 2008 at 17:51 Comment(0)

For Xcode 5 I add:

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

From Berik's Answer

Chirp answered 16/10, 2013 at 7:0 Comment(0)

Best of all,

gitignore.io

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

Exactly answered 6/2, 2017 at 7:45 Comment(0)

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

Softfinned answered 25/9, 2012 at 21:38 Comment(2)

Did you add it also? Or is this just all you do? – Revels 26/9, 2012 at 8:41

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. – Softfinned 2/10, 2012 at 21:59

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/

Chaps answered 12/8, 2015 at 10:15 Comment(0)

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"

Skipton answered 7/1, 2021 at 13:41 Comment(0)

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.

Bilk answered 28/10, 2014 at 17:45 Comment(2)

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. – Clemenciaclemency 2/1, 2015 at 17:3

GitHub is the first place I ever look for gitignores :) – Alfaro 12/9, 2016 at 12:29

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.

Mulford answered 4/9, 2013 at 8:3 Comment(0)

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

Chatterton answered 15/1, 2018 at 17:48 Comment(1)

For the next person trying to install Joe, check if it's 5+ years of dead repo resurrected before wasting time – Chafe 5/3, 2021 at 21:2

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

Management answered 18/11, 2021 at 12:12 Comment(4)

I studied this from youtube.com/watch?v=b0g-FJ5Zbb8 (14:50) – Management 18/11, 2021 at 12:13

Note: Can replace Objective-C with swift, node, etc based on your requirement. – Management 18/11, 2021 at 12:19

-bash: npx: command not found – Our 7/4, 2022 at 21:14

Please install node from nodejs.org/en If still didn't work, please run the command stated in https://mcmap.net/q/12978/-npx-command-not-found – Management 8/4, 2022 at 8:30

This will create up-to-date gitignore file

For iOS development

git ignore swift,ios >.gitignore

For macOS development

git ignore swift,macos >.gitignore

Nourish answered 7/11, 2022 at 16:2 Comment(0)

-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/

Martines answered 2/7, 2018 at 10:24 Comment(2)

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. – Anaphora 4/9, 2018 at 15:8

@AshleyMills Please read the answar first then add a comment .... The answar is for a standerd structure / required ones .... which are essentials to have ... – Martines 6/9, 2018 at 7:24

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags