On May 20, 2017, at 15:57 , Bryce Glover <email@hidden> wrote:
Hmm, that doesn’t exactly mesh with the mental model I tend to use for this kind of directory tree structure.
I don’t disagree with anything you said. I don’t really use “project” in a technical way. The enclosing folder is the “project folder”, so calling it the “project” is informal, but in fact it *is* the project because it may contain multiple Xcode project files, and multiple repositories (at different levels or locations, of course).
The important factor is that everything in the Xcode project is relative to the project file (i.e. package), and everything in the repository is relative to the .git subfolder. (Assuming there’s only one of each and they’re both at the top level.) That makes the project folder self-contained, hence moveable and duplicatable. …The only thing you really need to do is to fix the .gitignore file before you commit anything, since Xcode’s standard one is inadequate.
How so, exactly?
It depends what you’re doing, but from time to time files appear that you know you don’t want to commit. You see them in the commit sheet, and they mean the commit sheet isn’t “clean” just after a commit. In those cases, you might want to add specific items to .gitignore.
I usually add “xcuserdata/” to .gitignore, to prevent user-specific settings (e.g. breakpoints and non-shared schemes) to the repository, since they aren’t useful to anyone else. If you don’t do that, then any action that creates a new file inside xcuserdata introduces something untracked into the commit sheet, as above.
OTOH, if you’re working on a project alone, I guess it might be useful to have personal settings backed up in a remote repository.
It’s not really crucial, though. At worst, it commits a few extra small files to the repo. |