CocoaPods and GitHub forks

Question

This is my first time forking a GitHub project, and I'm not too competent with CocoaPods either, so please bear with me.

Basically, I forked a project on GitHub using the following in my Podfile:

pod 'REActivityViewController', '~> 1.6.7', :git => 'https://github.com/<username>/REActivityViewController.git'

I then made some changes to the fork, and of course when I did a pod install to install another pod it reinstalled the original REActivityViewController and erased my changes.

I'm realizing I need to push my changes to my fork before another pod install, but how do I know it is the fork being installed, considering that this is a repo installed by CocoaPods? I looked in the REActivityViewController folder installed under the Pods folder and there aren't any git files.

Do I need to work on my fork outside of my project and then use CocoaPods to install the changes? That's too cumbersome of a workflow.

Or do I need to do something with submodules?

Cheryle

Answer 1

I will answer this question using an example. I have a fork of TTTAttributedLabel with some extra functionality I added here:

https://github.com/getaaron/TTTAttributedLabel

In order to use this in a Cocoapods project, I:

1. Push my changes to my fork
2. Configure my Podfile to get the changes & update

Once you've pushed your changes to your fork, get the SHA of your last commit. You can do this using git rev-parse origin/master | pbcopy or on the GitHub commits page for your project:

Then, you can specify the specific commit on your fork in your Podfile like this:

pod 'TTTAttributedLabel', :git => 'https://github.com/getaaron/TTTAttributedLabel.git', :commit => 'd358791c7f593d6ea7d6f8c2cac2cf8fae582bc1'

After that, pod update will update this particular commit from your fork. If you want, you can also make a podspec for your fork, but I find this approach simpler and I don't make changes frequently enough to justify a new workflow.

Do I need to work on my fork outside of my project and then use Cocoapods to install the changes? That's way to cumbersome of a workflow.

You can do it this way, but I usually:

1. Edit the code inside my project and make sure it works
2. Copy the changes over to my fork, by
   • exporting a patch, or
   • copying over the entire source code file
3. Commit & push to GitHub
4. Update the Podfile with the new SHA
5. Run pod update.

Or do I need to do something with submodules?

No, you don't need to.

Violetvioleta

Follow-up question: So updating the Podfile with the new SHA is really necessary? pod install won't just automatically clone the most up-to-date version with the latest commit? – Cheryle

If you rename your project to something different and make your own podspec file, you can point it at your own repo and use pod 'MyForkName', :head instead. – Violetvioleta

:head: points to the newest commit, but you can't use :git and :head in the same line. – Violetvioleta

You can commit your new Podspec at github.com/CocoaPods/Specs and cocoapods will automatically find it. – Violetvioleta

Finally, if you want to keep it private, you can just register your custom Podspec for private use here: guides.cocoapods.org/making/private-cocoapods.html – Violetvioleta

This is a perfect fix for using a custom fork of a public project. In my case, I forked and modified a project, and had an open PR for the maintainer to merge those changes, but wanted to update my project's Podfile to use those changes immediately. This worked great! – Paez

@AaronBrager - Can I add the same repo in my Dependency file ? – Apomict

Instead of using the commit name, you can use the branch name pod 'Eureka', :git => 'https://github.com/slammer8/Eureka.git', :branch => 'Swift3' – Bartram

This works but I used pod install instead of pod update – Lem

@AaronBrager it's showing "Unable to find a specification for '<pod name>' " do you know how to resolve it? – Respite

@AaronBrager if the original branch is updated with some bug fixes after i forked the repository how do i pull those new changes from original repository to my forked repository ? – Bask

Nice answer, but is it just me who thinks Submodules is better than Pods in terms of source code management? There are many situations where we make changes to the dependent project (source code) and we would want to push directly to the forked project, this can be easily facilitated in submodules. Pods is not friendly in this matter, isn't it? – Worked

Submodules are simpler for this one thing, but generally Cocoapods / Carthage solve many problems that submodules don’t – Violetvioleta

The best thing instead of pointing to a specific commit is to create a new release in github and change the podspec with the latest version. In the podfile the you only have to point to your git repo without specifying any commit, it will always get the latest commit. – Xerox

@MihirMehta, any new about "after i forked the repository how do i pull..."? – Cycloparaffin

Answer 2

Another option is to have your project reference the pod directly and not via github. This way you don't have to keep committing your fork or copying/pasting code just to test your changes. You can work with two different Xcode projects simultaneously and commit separately into their respective projects.

pod 'AFNetworking', :path => '~/Documents/AFNetworking'

CocoaPods Documentation: http://guides.cocoapods.org/using/the-podfile.html#using-the-files-from-a-folder-local-to-the-machine

Wertheimer

How does this solve the problem? The Pod will pull these sources and place them as Pods project in the source project. Any changes to these (now included through Pods) files are not tracked by Git of the '~/Documents/AFNetworking', isn't it? – Worked

@RajPawanGumdal The local folder can still be checked into a local or remote repo, the Cocoapods aspect and the Git aspect are separate issues. – Paravane

Answer 3

CocoaPods and GitHub fork

You have two variants to work with fork

1. [Podfile specific branch]
2. [Podspec specific branch]

The difference is in the first variant you must push changes into remote/origin branch, while the second variant allows you just commit changes in a local branch

Russophobe