CocoaPods and Source Control Installation

In this lesson

Is the most recent version of a CocoaPod not working out for you? Maybe there is a hotfix in an emergency branch that you need for tomorrow’s deadline? You can specify exactly which Git repo, tag, even commit of a Pod that you want to install. Don’t wait for that pull request to be denied, go ahead and install it!

Kyle Roberts
Swift Guru at Large

Kyle's Series

Transcript

Tap on time to skip ahead

00:11

Hello world. Kyle here with Brax.tv. Let’s have a quick chat about CocoaPods and source control. For source control, I typically use SourceTree just cause I like it. How I normally handle CocoaPods and source control is that I just commit everything. In that, I mean, if you run a pod install and you have a ton of unstaged file changes here, just from the pod install, all those file changes include the Pods project, the Podfile, any of the Pods that it’s actually installing and any changes it makes to the project file, I just have that all committed into Git.

00:50

Usually, what that means is that if someone else, or I on another computer, were to download this code and work in this repo, that as long as they open this workspace file, they don’t have to worry about installing any sort of CocoaPods or running a pod install or pod update or anything like that. It should all just be ready to go.

01:09

Sometimes you may not want to commit everything to CocoaPods. That is understandable. Maybe you’re installing some CocoaPods that are huge and you don’t necessarily want that in source control with megabytes and megabytes of code. Who knows. That would be a lot of writing.

01:31

Some important things to include in source control when you are working with CocoaPods, at the bare minimum is the Podfile, of course, that’s something you want to share with anybody who is trying to install the app. That’s where you are defining the actual resources that you’re wanting to download. Also, you will want to include the Podfile.lock. The Podfile.lock is something that is created after you run a pod install. If you want to open it because of its file type, there’s no associated apps to open it with. I’ve already opened it with Xcode. You can read it since it is just a simple text file.

02:09

The Podfile.lock contains version information for all the Pods that have been installed and any dependencies they might have, as well as spec checksums (I’m not sure what that is) and the CocoaPods version. This is important to commit because if you run a pod install and were using this optimistic logic operator here, say we downloaded 3.3.0 and committed our Podfile and Podfile.lock, then Podfile.lock here with Alamofire will say 3.3.0, not 3.3.1. Then, someone else downloads the code and they run a pod install because of the Podfile and the Podfile.lock, they will see that there has been an update to Alamofire and that the Podfile.lock will have changes in source control that the current version of a Pod that we’re using, there’s actually a new version of a Pod that we’re using. The second user’s Podfile.lock says 3.3.1 and not 3.3.0. That way, the original user will be able to see that in source control that the history has changed. Or the second user who actually updated to the newest version can communicate that to everyone else.

03:23

The Podfile.lock, from the user’s standpoint, is just an easy way to compare what is actually installed to what is defined in the Podfile. Of course, you’ll want to commit any project changes that may link to the Pod update. This Manifest.lock is sort of similar to Podfile.lock. It’s just in a different location in Pods. That’s the bare minimum. I like to commit all changes from CocoaPods. It sometimes leaves a nasty commit just because there are tons and tons of file changes if there are several Pod updates. You can just make that its own commit and make the commit message pod install or something like that. Then, actually, commit your code changes at a later time.

Additional Info

Register to get access to additional resources and info.