This may be a more complicated issue than I am portraying, but after building an iOS app and occasionally using GIT, I am not in a challenging position; I have additional developers I am working with, and there is a need to properly use a repository (BitBucket) for further work.
My project is "complicated" for two reasons;
I am using CocoaPods for third-party dependencies.
I use using GPUImage2, which is a separate .xcproject embedded in my project.
Somehow, everything was working fine (I had a master branch and several branches that various developers have been working on). Things have been complicated whenever I find the need to switch branches or merge branches. Issues related to CocoaPods constantly come up, though endless efforts at the command line typically get us through our challenges.
At this point, we are now trying to merge master into a new feature branch, and have hit the end of the line.
My question: Only one actual project file has a merge conflict. Every other file is related to the .xcworkspace or something with CocoaPods. I would think it would be ideal to remove CocoaPods from GIT control altogether, leaving just the Podfile, which developers can install locally.
Does anyone have suggestions on dealing with CocoaPods and GIT with Xcode projects?
I strongly recommend that you do not add your Pods folder to git, only commit the Podfile and Podfile.lock.
You can do the following to remove the folder:
git rm --cached Pods/
Related
I am using some framework which are integrated with pods . So I want to ask is this good approach to sync these framework on gitHub . For example . In my iOS project I have integrated GoogleMap framework, Should I sync this on Github or i should some reference . I am asking this because When i commit this framework it give me memory issues.
I'd say there's no "best approach" about what should be ignored concerning your pods dependencies.
One would say that it's better to ignore the pods directory to keep your git repository light, but for someone else would say that your pods dependencies are part and parcel of your app, it won't build without it, so you must commit it.
First I chose to include all my pods in my git repo, but I quickly noted that it could be very annoying, given that each time you update one of your dependencies it blows yp your updated commit files list. Now I just include my Podfile and Podfile.lock files and ignore the Pods repository. Just make sure to run pod install each time you pull from the repo.
The main benefit of including all your Pods is to have your project "ready to build", without the need to have CocoaPods installed on your computer to build it first.
For more details, see this related question :
What goes into your .gitignore if you're using CocoaPods?
I have an Swift project that utilizes two libraries: the SQLite and SwiftCSV project. They can be found on: https://github.com/stephencelis/SQLite.swift and https://github.com/naoty/SwiftCSV respectively. I followed the instructions on each respective Github README to incorporate the projects into my project which works fine, but when I push my project to Github and I have another teammate of mine clone the project, the SwiftCSV and SQLite projects turn up empty so my teammate has to re-add them into his project. I have been trying to google different responses but maybe I am looking for the wrong keywords. Any ideas on how to fix this?
You should (and may be) adding the above projects to your repo as submodules (if not, read up on them).
If you used submodules, they are not automatically checked out when you clone a repository. You can, however, use clone's --recursive flag to ensure submodules are checked out when someone first clones your project:
git clone --recursive git#github.com:your/project.git
If the project has already been cloned, one can check out the submodules by running the following incantation from within their project directory:
git submodule update --init
Note: Xcode is usually smart about letting you check out submodules from within Xcode itself. Check the Source Control menu and see if SQLite.swift or SwiftCSV show up under Working Copies.
If you merely downloaded the projects and dragged them into your Xcode project (rather than use submodules, as instructed above), they'll likely be referencing directories outside of your project. Make sure you move them to your project's directory before dragging them into your Xcode project. If you don't, the projects will appear red/unavailable on subsequent clones.
usually, xcodeproj is in gitignore, please remove it from .gitignore file
In Xcode 5 I am developing a universal iOS app - on three different Mac OS machines (on which I happen to have different usernames too - "admin", "alex", etc.)
My project uses the SDWebImage library through CocoaPods and I plan to add few more later.
I would like to keep my project in a Git-repository on GitHub or BitBucket.
I'm confused: which files of my project should I check in into the git repository.
Especially I wonder about 2 groups of files:
The CocoaPods-related (currently I've only checked in the Podfile and Podfile.lock, but there are also Pods.xconfig and Pods, etc.)
And the Xcode-related (should I check in the Workspace Settings? What to do with User Data - admin - ...?)
Here is the screenshot of the commit dialog:
When I run git clean -n -d in my project dir, I see the following:
Would remove Podfile.lock
Would remove Words.xcodeproj/xcuserdata/
Would remove Words.xcworkspace/
And my Podfile contains the following:
platform :ios, '6.0'
pod 'SDWebImage'
UPDATE:
I use a .gitignore containing xcuserdata, but for some reason still see the User Data files in the commit dialog:
This is a bit of a matter of taste and requirements for your projects. There are two schools:
Never check in generated code. Put your xcworkspace, Podfile.lock and Pods folder in .gitignore and never commit them. Instruct developers on your code base to run pod install directly after checkout. This is my preferred choice, and should work fine as long as your pod dependencies point to a specific version or a range of compatible versions.
Check the workspace, lock file and Pods directory into Git with the rest of your code. This is a guarantee that all developers on the project are using the exact same code when they build. Even if your third party dependency removes their code from the Internet, your project is still buildable. However, you now have a lot of source code that is unrelated to your own, version controlled together with your own.
As an aside: you should probably always put "xcuserdata" in your gitignore, maybe even your system-wide git ignore, because other users of your code are probably not interested in your personal Xcode settings.
I am working on a project using cocoapods and suddenly I see myself doing some changes in one of the libraries. How can I ensure that those changes will never be override by a pod update? Is there any way to introduce changes in a pod without updating the github project?
UPDATE : Forking a project
I have tried to fork the project and create a new specfile to point to the new project. I was able to install the basic stuff, however, for some reason, there are some dependencies that are installed but can't be referenced inside the pods project. Currently I have this in my podsfile:
'WhirlyGlobe', :podspec => 'https://raw.github.com/tiagoalmeida/WhirlyGlobe/master/WhirlyGlobe.podspec'
The fork of the library is in https://github.com/tiagoalmeida/WhirlyGlobe
UPDATE2: Missing Headers
I have found that the headers (Pods/Headers) for boost and Eigen (used from the WhrilyGlobe) are not being generated.
UPDATE3: Trying to do Something about the headers
I have tried to look in some of the configurations that are in this thread and I have tried the solutions in the FAQ but I believe that my problem is different. The headers are actually missing.
UPDATE4: Attacking the cocoapods version
I have uninstalled cocoapods and installed the version 0.20.2 (that was working before trying to use my fork) and it keeps all the same :/.
#pgb and wattson provided me good information but ultimately the problem was in a combination of things.
I don't know why but it seems that cocoapods 0.22 handles headers differently. I uninstalled cocoapods and installed the version 0.20.2.
To check the version of cocoapods I have used gem query and I have removed the cocoapods with gem uninstall cocoapods and installed the cocoapods with gem install cocoapods --version 0.20.2.
I have used my podfile like this:
'WhirlyGlobe', :podspec => 'https://raw.github.com/tiagoalmeida/WhirlyGlobe/master/WhirlyGlobe.podspec'
Where podspec points to my new podspec. I made like this because I need to remove the :tag from the original podfile (otherwise it always points to the same spot) and this way I have more control over the file.
In the podspec I have changed the source:
s.source = { :git => "https://github.com/tiagoalmeida/WhirlyGlobe.git"}
To point into my fork and removed the tag.
Thanks #pgb and #wattson for the attempts to help me. Upvoted both because they were both usefull.
You can fork a repository and then add your forked repo as a pod, so say you've forked the repo to https://github.com/tiago/ThePodProject.git, then set the pod to:
pod 'ThePodProject', :git => 'https://github.com/tiago/ThePodProject.git'
see here for more detail (under "From a podspec in the root of a library repo")
You are close to having it working with your forked repository.
I just tried it with the following Podfile:
pod 'WhirlyGlobe', :git => 'https://github.com/tiagoalmeida/WhirlyGlobe'
It downloaded WhirlyGlobe and then failed because hg was missing. I simply installed it using Homebrew: brew install mercurial and then runnning pod install was able to install all the dependencies.
The project compiles, but I'm not sure it works, go ahead and try it.
Be aware that it took a really long time to download and compile all the dependencies (shapelib in particular).
Just want to add my few cent to the answer.
I encounter the same problem. As someone suggested above too I went to subclass-ing the pod lib.
I was using ACEDrawingView and it has property image which is readonly.
I subclass-ed it and made this property read/write.
I personal feel going by sub-class is more elegant and hassle free solution to this kind of problem.
Unless there is huge development you want to do on side of your main project.
Saving custom changes using only Git (no forking)
For those looking for a simple solution, I have successfully solved this problem by using git stashes.
As mentioned, pod update will overwrite any changes you made. However, if you're using git what I like to do is commit all my changes except for my pod changes.
Once the only changes I have on my branch are the Pods changes, I stash those changes by running git stash save "Custom Cocoapod changes, apply after every pod update". You can give it any message you'd like by changing the text between the "".
This command has the side effect of reseting your working directory to the previous HEAD, so if you want to reapply those stashes you can just run git stash apply to get those changes back in, and then you can commit them to save them.
Don't use git stash pop as this will delete the stash after applying it.
Now, at some undetermined time in the future, when you update your pods and its time to apply the stash again, what you're going to want to do is run git stash list. this will return a list of all the stashes you've made with the most recent being zero indexed. You'll probably see something like this:
stash#{0}: On featureFooBar: foo bar
stash#{1}: On Master: Custom Cocoapod changes, apply after every pod update
...
If the custom cocoa pods changes stash is in stash#{0} then perfect, you can just run a git stash apply again and you'll get those changes on your working directory. Otherwise once you find which stash number your pods changes are you can apply that stash by running git stash apply stash#{1}
Applying stashes is easiest when you have a clean working directory on the same branch but thats not required. This page gives a good description of git stash and how to use it otherwise.
This is not the most full proof solution since I can foresee some issues when you have multiple people on the same project, but it's a simple way to solve this without resorting to more involved solutions.
There is an another way exist where you can fork the repository , modify the changes and maintain the library through cocoapods for future bug fixes and feature enhancement .....
I have recently published tutorial for the same here https://medium.com/#mihirpmehta/how-to-modify-cocoapods-library-within-pods-647d2bf7e1cb
I am working on a project which includes other repositories from Git.
I would like to keep up to date with these repositories. Know what are the latest features, bug fixes etc.
Qu 1) What is the best way to keep up to date with a repository on Git without receiving emails of all issues reported etc?
After this is complete I would like to know the best way to include these into your project. I understand you can copy the source code into the project, but what are cocoapods/sub modules used for? For example, what is the correct way to update your project with the latest changes to that included repository?
Are there any GUIs for either of these methods as opposed to terminal?
Cocoapods is a great way to include other projects in your Xcode project. The Cocoapods project maintains a list of pod spec files for a many open source libraries, which specify where to download the code and how to integrate them into an existing project. As you noted, you'd traditionally have to add a git submodule, manually add the source files to your project, update your build settings, and so forth. Cocoapods takes care of all of this for you.
I'm not sure of a way to track updates for Github projects without also being notified about issues, but Cocoapods can certainly tell you if any of your 'pods' have become outdated. It's then one command to update them to the latest versions. That said, it's generally best practice to 'lock' your external dependencies to a specific version that you know works correctly.
Using Cocoapods
To get started, first install Cocoapods. You then simply need to create a file in your root project directory (the same directory that contains your .xcodeproj file) called Podfile. Inside, you can specify your target OS, and your dependencies:
platform :ios, '5.0'
pod 'AFNetworking', '0.9.1'
pod 'OHAttributedLabel', '0.1.1'
The example above is targeting iOS 5.0, and pulling in the AFNetworking and OHAttributedLabel projects.
Then, in the Terminal, change to your project directory:
> cd path/to/my/project
And run pod install.
> pod install
This will check out the latest version of your dependencies for you. It will also generate you a .xcworkspace file. From now on, when you work on your project, you must open the .xcworkspace, not the .xcodeproj file.
Inside your new workspace, you'll have your existing Xcode project and a new Pods project - this contains all of your third party libraries. Just build and run your app as normal, and the Pods project will also be built and included.
Some other useful Cocoapods commands:
> pod outdated
Will list all dependencies that have an update available.
> pod search query
Will search all known Pod specs for 'query'. Useful for finding new libraries!
Tutorials
Looks like Tutsplus have a nice tutorial on getting started with Cocoapods
There's a free episode of NSScreencast on Cocoapods
GUIs
I'm afraid I don't know of any GUIs for Cocoapods, but there really aren't many Terminal commands that you need to know. It's worth getting comfortable with the command line, as it's such a useful developer tool.
That said, as far as I know, Appcode (Jetbrains' alternative IDE for Objective-C) is planning on adding Cocoapods support in their next update.
Good luck!
James Frost's answer is an excellent explanation of how to work with Cocoapods and their advantages over submodules.
A few important advantages submodules have over Cocoapods are:
submodules are sub-repos - not only does this mean that git and git GUIs implicitly recognize them and more and more support easily working with them, it also means that your dependencies stay connected the wonderful world their git repos, Cocoapods or not, reside in. This means that you are able to collaborate and test changes from within your project, your project usually being the source of inspiration for elaboration of a dependency.
Unfortunately Cocoapods do not maintain this link, to work on a dependency means to clone it from git, outside of the range of Cocoapods.
Edit: It's worth noting that Cocoapods does allow working on a local pod with the path or local fields or even building your own Spec repo but it still isn't as simple a process.
one less tool dependency - as mentioned in the previous bullet, submodules are a function of git and your using git means they are available to you. Any software's adoption of git implies that they will eventually support either all (important) features of git or all features that cover common use cases. Xcode 5 has brought in a basic support for git and GUIs (which are tool dependencies, it's true, but hopefully just dictate how information is surface, git dictates how it works) like Git Tower make working with sub-repos straightforward.
Cocoapods has come a long way and everyday is taking steps to becoming a stable, indispensable tool. However it hasn't yet gotten a nod from Apple and there isn't any reason why Apple won't release a change to Xcode that breaks Cocoapods. Additionally Cocoapods is dependant on Ruby. Aside, considering how much attention and community has been generated around Cocoapods it would be silly for Apple to ignore it.
It's also worth noting that using one does not lock you out of using the other. It might be a headache or it might be what you need, perhaps using Cocoapods for tiny one class libraries or libraries with complex dependancies and submodules for libraries with that you will be interacting with often.