-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve discussion of checking in Pods directory #67
Conversation
|
||
Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend against adding the Pods directory to your `.gitignore`. However you should judge for yourself, here are the pros and cons: | ||
Whether or not you check in your `Pods` folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and do not add it to your `.gitignore`. But ultimately this decision is up to you: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do not
-> don't
Yeah, I'm good for merging once Thanks @smileyborg - this is really useful. |
- Smaller repo under source control | ||
- CocoaPods given the availability of the sources is capable to recreate (almost) the same exact installation. | ||
- No conflicts to handle in the dependencies of the management system of source control. | ||
- After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run `pod install`, and no Internet connection is necessary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading this a few times I'm not sure if it makes sense to say no Internet connection is necessary
since you would need internet connection in most cases to clone the repository.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I like having it in there. You're right that cloning will most always require Internet. However, sometimes you will clone a repo but not actually open/build its contents immediately...for example you may clone or pull the latest before hopping on an airplane. If you forget to also pod install
and the Pods aren't checked in, you wouldn't be able to build on your flight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd agree with @smileyborg here, there have been a few occasions where I've cloned a project before getting on a train but forgotten to pod install
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes I work on a quick test project that I don't really want to push on GitHub, so I do my commits only locally, copy my working copy on an USB drive to bring it home to do some more commits, etc… so in such case, no remote and no internet connection required at all. So even if it's not the most common case, it still does make sense to me anyway ;)
🚢 |
available. CocoaPods will honour this version unless the dependency is updated | ||
on the Podfile or `pod update` is called. In this way CocoaPods avoids headaches | ||
caused by unexpected changes to dependencies. | ||
Running `pod install` will install the current version of RestKit, causing a `Podfile.lock` to be generated that indicates the exact version installed (e.g. `RestKit 0.10.3`). Thanks to the `Podfile.lock`, running `pod install` on this hypothetical project at a later point in time on a different machine will still install RestKit 0.10.3 even if a newer version is available. CocoaPods will honour the Pod version in `Podfile.lock` unless the dependency is updated in the Podfile or `pod update` is called (which will cause a new `Podfile.lock` to be generated). In this way CocoaPods avoids headaches caused by unexpected changes to dependencies. | ||
|
||
This file should always be kept under version control. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should emphasis this last point / sentence way more than that IMHO.
I still have encountered people adding Podfile.lock
to their .gitignore
. They generally just don't understand the consequences and e.g. think that using fixed version in their Podfile is sufficient to ensure fixed versions for all pods (not thinking about transitive dependencies).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok nvm, that point is already repeated above in line 72 so having it twice is probably enough.
Alright, let's get this in. |
Improve discussion of checking in Pods directory
As per @orta's suggestion, here are some suggested improvements to make these 2 sections much clearer. I and the other folks on my team had trouble understanding this as it was originally written without reading it a few times, hopefully this is clearer!