In this tutorial, you'll learn how to use git source control with Xcode 8; whether committing or reverting, branching or merging, this tutorial has you covered.
Richard, great introduction to a tool that, for a self-taught iOS developer, is something of a mystery. One question, which had me worried at the time: when you are finally ready to publish your app, does the publishing / archiving process always take the code that’s in the master branch? Can you publish from a separate branch?
Hi Alan,
Thanks for the kind words. Xcode, when building or archiving your project, isn’t actually looking at your Git repo. It works on the working copy of your project that you have checked out. So, if you’re on a branch other than master, then yes, it will build/archive/publish/distribute that branch. You have complete control. It will never access another branch, even if that other branch is master, without your telling it to do so.
Hope that helps!
Hey Richard. Great tutorial! I see a lot of developers using Git from the terminal to commit, checkout branches and merging. On this site there is a great tutorial in using Git from the command line as well.
Now the question: Is there a specific reason to use the Xcode Git features other than not feeling comfortable with the terminal? Are there important limitations to using Git in Xcode versus from the command line that you know?
Best regards, Martijn
This is great! My issue with Git and Xcode development has always been storyboards… do you have any best practices around merging storyboards? The issue is they’re text-based so git will do diff checks and can merge them, but when you have merge conflicts I have never found an easy way to merge them… any tips?
You say the following:
“For example, let’s say you’re adding a new map feature into your app but it isn’t quite ready for production. To simulate this, create a new class derived from NSObject and name it MapForItinerary. At this point your project might look like this:”
I am not following you on how to create the new class.
I figured it out, I wasn’t thinking cocoa class files - my screw up.
Thank you, Martijn! I suspect many developers use Git from the terminal because that’s how they learned to use Git. I definitely do some things from the terminal (such as tagging) because Xcode doesn’t do that. (As an aside, I also create my repos from the terminal because I keep my DerivedData in the project directory and want to setup a .gitignore before the repo is created. Otherwise, it just makes a mess).
The advantage, in my opinion, of using Xcode’s source control features is that it doesn’t interrupt your workflow and it makes some things much easier. For example, it makes it really easy to review what will be included in a commit before actually updating the repo. Of course that can be done with git diff commands, but why bother. Likewise, the ability to see blame differences and merges before they are committed is far better in Xcode than from the terminal. Yes, I know there are tools like SourceTree (which I also use) but I still find comparing versions and validating merges to be more intuitive in Xcode.
I know that’s a rather “touchy-feely” answer, but at the end of the day, use the tools that make you most productive and do their best to stay out of your way.
I’m afraid I have no magic bullet for storyboards and source control, whether you’re using the tools in Xcode or not. Yes, the storyboard is just an XML file, but merges are tough. Personally, I just make sure the version I’m merging is already what I want and just let it replace the one in the branch I’m merging into. Probably not optimal, but it works for me.
I’m glad you were able to figure it out. Sorry it wasn’t clear from the beginning.
I tend to build projects by creating local frameworks of code that I expect to reuse. Then an application project contains several library frameworks that are local (internal) to me. Now each library framework should be independently controlled in git - I get that. But what is the recommended way to handle source control for these frameworks in the main (application) project?
The best suggestion I have is actually another of our tutorials: https://www.raywenderlich.com/155150/dependency-management-using-git-submodules
Hey Richard. Thank you for great explanations. I also have a question for you. For some couple of time I’m thinking about how to save credentials on Github. With credentials I mean: all of connectionStrings/serverUrl/tokens/etc.
At the moment all of them are hardcoded in AppDelegates file. But I have a filling that it’s a wrong place. Maybe you have/know a better approach for this situation. I will appreciate if you will share with us.
Thank you
Hey hackmajoris!
Glad you enjoyed the tutorial.
There really isn’t any one single good way to handle credentials/API tokens/etc. Usually, you’d try to encapsulate all of the functions that need a particular credential into one module, place the credential at the top of the module, and point to it in your README.
But I can also imagine a circumstance where you’d rather just collect all of the credentials in one source file and point to that from the README. When using this option and writing in Swift, you can at least “namespace” the credentials by grouping them inside appropriately named structs or enums. That means more text at the usage site but Xcode’s code completion can help with that.
At the end of the day, it’s which ever way is most workable for you when maintaining your code and your repo.
Hope that helps!