Developing Perspective

00:00:00 ◼   ► Hello and welcome to Developing Perspective. Developing Perspective is a podcast discussing

00:00:04 ◼   ► news of note in iOS development, Apple, and the like. I'm your host, David Smith. I'm

00:00:09 ◼   ► an independent iOS and Mac developer based in Herne, Virginia. This is show number 94,

00:00:13 ◼   ► and today is Thursday, November 8th. Developing Perspective is never longer than 15 minutes,

00:00:18 ◼   ► so let's get started.

00:00:19 ◼   ► All right, after the long arc I did on Check the Weather, I'm going to be switching up

00:00:24 ◼   ► gears a little bit on Developing Perspective and probably going into at least a couple

00:00:28 ◼   ► of weeks of, I guess you could call it kind of Q&A. And so if you have any questions or

00:00:33 ◼   ► comments or thoughts that you want me to sort of expand upon for 15 minutes, just let me

00:00:38 ◼   ► know on Twitter. I'm _DavidSmith there, or on AppNet, I'm DavidSmith, without the underscore.

00:00:44 ◼   ► But generally speaking, I just kind of, I thought it'd be interesting to kind of just

00:00:47 ◼   ► walk through focus topics for the next couple of weeks while I kind of think about what

00:00:51 ◼   ► I want to do next for a big arc or if I want to do a big arc or whatever. So anyway, so

00:00:56 ◼   ► So this question that I'm going to talk about today comes from Brad Allen, and he was asking

00:01:02 ◼   ► all about Git, version control, and how I use GitHub.

00:01:06 ◼   ► And it seemed like a pretty good place to start.

00:01:08 ◼   ► Version control is a pretty fundamental topic for developers and for development in general.

00:01:12 ◼   ► So first I'm going to back up a little bit before I start talking about Git or GitHub

00:01:16 ◼   ► and just talk about version control and what I think it's useful for and what it is and

00:01:21 ◼   ► what it isn't.

00:01:23 ◼   ► So for me, version control has two primary purposes.

00:01:27 ◼   ► One of them is to create an anthology or a collection of all of the code I've ever written

00:01:36 ◼   ► that worked.

00:01:38 ◼   ► And maybe didn't work, but specifically it's all the code I've ever written that worked.

00:01:42 ◼   ► That's what I really want my version control system to be for me.

00:01:46 ◼   ► And what I say that is so that I can go back in time, I can pull out little fragments or

00:01:51 ◼   ► or little functions or things I've written or things I've done in the past, and I can

00:01:55 ◼   ► apply them to my current problem.

00:01:57 ◼   ► Typically, in my experience, if you have an existing solution to a problem, it's often

00:02:02 ◼   ► better to adapt that to a new problem or a similar problem than it is to entirely reinvent

00:02:08 ◼   ► the wheel every time.

00:02:11 ◼   ► Source control is great for that because it lets you keep track of not only what the current

00:02:17 ◼   ► snapshot at the head of your source control system is, but also all the previous things

00:02:21 ◼   ► you've had. And I've often encountered things where I'll go back in time and be like, "Oh,

00:02:25 ◼   ► what was that thing I used to do before I did this? Now, whatever." You can kind of

00:02:30 ◼   ► go back in time and reach in and grab it. Or, often what I'll end up doing is it allows

00:02:34 ◼   ► me to head down a path, kind of capture a vaguely working solution, and then kind of

00:02:40 ◼   ► jump over to the actual, like say, my master branch in Git, and I can cherry pick little

00:02:45 ◼   ► parts of that into my main code branch. But it's really just about having this anthology

00:02:50 ◼   ► of all the stuff I've ever done.

00:02:55 ◼   ► That's what version control is important for.

00:02:57 ◼   ► Version control for me is not a backup system.

00:02:59 ◼   ► It's not something I'm doing in that way.

00:03:02 ◼   ► It's not really a--

00:03:05 ◼   ► I don't use it as a collaboration system,

00:03:06 ◼   ► though obviously many, many, many people do,

00:03:08 ◼   ► and most of you who listen to this podcast probably do as well.

00:03:10 ◼   ► But I just happen to be a one-man shop,

00:03:13 ◼   ► so it's not really useful for collaboration for me in that way.

00:03:15 ◼   ► But it is very useful for collaboration.

00:03:15 ◼   ► I'll talk about that a little bit when I talk about GitHub.

00:03:18 ◼   ► And the second thing it is, is it's incredibly helpful

00:03:20 ◼   ► to be able to have repeatable snapshots of code bases.

00:03:25 ◼   ► And what I mean by that is, so if I-- right now, I think--

00:03:28 ◼   ► let's say check the weather.

00:03:29 ◼   ► Version 1.2 is the current App Store version.

00:03:33 ◼   ► However, I have version 1.3 already submitted

00:03:35 ◼   ► to the App Store.

00:03:36 ◼   ► And I have a few even bug fixes beyond that

00:03:39 ◼   ► that I've been testing and doing as I've been going along.

00:03:42 ◼   ► That's just kind of the development process,

00:03:44 ◼   ► especially with Apple where you're kind of,

00:03:49 ◼   ► you make a snapshot, you submit it to the App Store,

00:03:51 ◼   ► and then you keep moving potentially up to a week or two

00:03:54 ◼   ► of changes.

00:03:58 ◼   ► And so what is very helpful though is that I can go back

00:03:59 ◼   ► and pull up exactly what it was I submitted,

00:04:03 ◼   ► I pull up the tag or the commit that I know

00:04:06 ◼   ► that I submitted on, and I can recreate something.

00:04:08 ◼   ► So even if I get a help desk request from somebody now

00:04:10 ◼   ► who says, "I'm having this problem,

00:04:09 ◼   ► It's very reproducible, but it only happens on version 1.1.

00:04:13 ◼   ► I can go and find version 1.1 inside of my version control system rather than having

00:04:18 ◼   ► to do have some kind of clunky making zip files of my source tree or something and archiving

00:04:23 ◼   ► them that way.

00:04:24 ◼   ► So those are the two things that I really want my version control to do.

00:04:27 ◼   ► I want it to have an anthology of all my working code, and I want to have the ability to reproduce

00:04:34 ◼   ► particular snapshots in time.

00:04:36 ◼   ► That's really it.

00:04:37 ◼   ► And exactly what you do, which system you use to do that, really doesn't matter.

00:04:42 ◼   ► I mean, I've used, let's see, I started off using CVS back in the day, then I used SVN,

00:04:47 ◼   ► and now I use Git, and I've played around with a few of the others, like, was it SourceSafe, Perforce,

00:04:54 ◼   ► there's all kinds of these other little version control systems, many of them are

00:05:02 ◼   ► I come with big enterprise-y systems,

00:05:07 ◼   ► rather than more general or open-source style.

00:05:11 ◼   ► And right now I use Git.

00:05:15 ◼   ► And I use Git almost exclusively

00:05:16 ◼   ► because it's the lingua franca

00:05:18 ◼   ► for the development community.

00:05:21 ◼   ► And by that I mean, I don't really care.

00:05:24 ◼   ► Git does some crazy stuff that I'm sure I could use,

00:05:27 ◼   ► but like I said, I'm an independent.

00:05:29 ◼   ► I don't need all of the really complicated

00:05:29 ◼   ► distributed branching and all the stuff that you can do

00:05:34 ◼   ► that is really helpful when you're working on a large team,

00:05:37 ◼   ► it's just me.

00:05:41 ◼   ► I use Git because everyone else seems to use Git.

00:05:42 ◼   ► And so I want to be skilled with it

00:05:45 ◼   ► so that I can interact well with other people

00:05:47 ◼   ► who post code online or in other different places,

00:05:49 ◼   ► and I want to be able to speak that language.

00:05:52 ◼   ► It's the most popular one, so I went with it.

00:05:54 ◼   ► Git is pretty solid though.

00:05:59 ◼   ► I'm not using it kind of reluctantly.

00:06:01 ◼   ► It's definitely grown on me.

00:06:03 ◼   ► It took a while to wrap my head around it

00:06:05 ◼   ► from when I came from an SVN background.

00:06:07 ◼   ► The things I like most about Git is that it is distributed.

00:06:10 ◼   ► The biggest part of that is that you can do

00:06:14 ◼   ► non-connected commits.

00:06:17 ◼   ► It's just something that at first I didn't think

00:06:19 ◼   ► would make that much of a difference.

00:06:21 ◼   ► My server's almost always available,

00:06:20 ◼   ► Often I've even run SVN servers locally,

00:06:25 ◼   ► so my server's always available.

00:06:29 ◼   ► But the fact that you're not tied to a particular,

00:06:31 ◼   ► you can completely reproduce a Git repository

00:06:36 ◼   ► just by copying its directory.

00:06:39 ◼   ► And then you can take that and put it somewhere else

00:06:41 ◼   ► just has been really, really helpful

00:06:44 ◼   ► in a lot of situations.

00:06:46 ◼   ► I can create a copy of my,

00:06:46 ◼   ► to take a repository, put it on a thumb drive,

00:06:51 ◼   ► go on a trip.

00:06:55 ◼   ► I have all of the history that is associated with that repository

00:06:57 ◼   ► in that directory.

00:07:01 ◼   ► I don't need something else that I'm connecting to.

00:07:02 ◼   ► And also, a bigger part of that, I think,

00:07:05 ◼   ► is that the latency is zero, which makes it really fast,

00:07:07 ◼   ► because I'm not interacting with the server all the time,

00:07:11 ◼   ► or even on a local server.

00:07:14 ◼   ► It's still not quite as fast as doing direct file access.

00:07:13 ◼   ► I think it's also just built to be really fast.

00:07:18 ◼   ► So those are the things that I really like about it.

00:07:20 ◼   ► I think I don't particularly like some of the,

00:07:23 ◼   ► I'm not a huge fan of the two-phase commit.

00:07:27 ◼   ► I've gotten used to it, and I'm fine.

00:07:29 ◼   ► But my development philosophy tends to be

00:07:31 ◼   ► I'm always stage all commit, so it always feels kind of redundant

00:07:34 ◼   ► that I have to stage all my files and then commit them.

00:07:37 ◼   ► I know why you do that, and it makes sense,

00:07:40 ◼   ► but not really for my workflow.

00:07:39 ◼   ► And I don't really like that Git has--

00:07:44 ◼   ► sometimes I feel like Git is a little too dangerous,

00:07:48 ◼   ► or too freeform.

00:07:50 ◼   ► And this speaks more to times when I've worked on larger teams

00:07:52 ◼   ► where because you can do anything with Git,

00:07:55 ◼   ► it creates a couple of situations.

00:07:58 ◼   ► One, people can go round and round and round about how we're going to structure our Git flow.

00:08:00 ◼   ► You know, Git flow is even a philosophy, or I'm going to organize it.

00:08:06 ◼   ► So we have this branch for this, and this branch for this.

00:08:07 ◼   ► and I'm going to move merge from this to this.

00:08:09 ◼   ► Oh, we have a merge conflict.

00:08:10 ◼   ► Let me rebase that with all this crazy stuff

00:08:13 ◼   ► that people can end up doing that just isn't really

00:08:16 ◼   ► productive.

00:08:16 ◼   ► You can create lots and lots of busy work

00:08:18 ◼   ► that feels very productive using Git because it's so unstructured

00:08:22 ◼   ► and you can do anything.

00:08:24 ◼   ► The ability to do anything is often the most dangerous thing

00:08:27 ◼   ► in most things in technology.

00:08:30 ◼   ► Having a little bit of structure I think would be nice.

00:08:32 ◼   ► You can easily enforce that on yourself.

00:08:35 ◼   ► For me, the vast majority of my work,

00:08:40 ◼   ► I have a master branch that's code I expect to ship.

00:08:42 ◼   ► I have branches that is code I'm not sure

00:08:45 ◼   ► if I'm going to ship.

00:08:47 ◼   ► And then I push that off all,

00:08:49 ◼   ► I only really push master onto my main repository repository.

00:08:51 ◼   ► But yeah, that's Git at a high level.

00:08:57 ◼   ► Git is pretty straightforward in terms of its operation.

00:09:00 ◼   ► You get a knit to create a repository.

00:09:02 ◼   ► you git add to say that a file should

00:09:04 ◼   ► be added to the next commit.

00:09:06 ◼   ► You say git commit to commit that file,

00:09:08 ◼   ► and then now you've made a snapshot of that current

00:09:11 ◼   ► or of the stage files at that point in the directory.

00:09:15 ◼   ► And you can branch, git branch, and that

00:09:17 ◼   ► creates an alternative fork of your code path

00:09:21 ◼   ► that you can develop, download, and commit to,

00:09:23 ◼   ► and then you can ultimately git merge to put that back in.

00:09:26 ◼   ► It's fairly straightforward.

00:09:27 ◼   ► It does all the obvious things.

00:09:28 ◼   ► It doesn't do that much that's particularly unique.

00:09:31 ◼   ► It does something better than others. Some people say Mercurial is much better.

00:09:35 ◼   ► I don't really know or particularly care. Like I said, I use Git not because

00:09:39 ◼   ► of its functionality, but because everyone uses it and it does

00:09:43 ◼   ► a good enough job that that works fine for me.

00:09:47 ◼   ► And so I'm going to talk a little bit about GitHub and what it did. And I think it's kind of a remarkable

00:09:51 ◼   ► thing that GitHub kind of solved this problem that I think a lot of people had.

00:09:55 ◼   ► And I don't think its success is strictly tied to the fact that they used Git.

00:09:59 ◼   ► It just so happened that they used Git and it became very popular in the Rails community,

00:10:03 ◼   ► and when GitHub was founded, that was important.

00:10:06 ◼   ► But GitHub allows for people to share code very, very easily, to fork and sort of alter

00:10:14 ◼   ► it and to kind of have this very efficient open source process that is really very useful.

00:10:21 ◼   ► I mean, GitHub is a great resource, and I find I use it mostly for just looking for

00:10:27 ◼   ► looking for inspiration, looking for people who've solved the same problems that I've had,

00:10:31 ◼   ► and looking at how they did it, or getting some help there.

00:10:36 ◼   ► Something like SNEC Overflow is really useful for if you have a question or something very specific.

00:10:40 ◼   ► But often what I'm interested in is I'll go and just look at how other people write,

00:10:46 ◼   ► especially people who open source code, who the developer is someone I respect, someone who I admire.

00:10:51 ◼   ► I love just looking through it.

00:10:56 ◼   ► couple days, the Pocket SDK was released, which is some work that Steve Stresa has done.

00:11:02 ◼   ► And it was just fascinating to go and look at the way it was structured, and it's really

00:11:05 ◼   ► kind of clever and well put together and thoughtfully designed. And that's good for inspiration.

00:11:10 ◼   ► And GitHub, I think, is just a great tool for that. It's a great way to kind of put

00:11:14 ◼   ► code out there and let people easily pull it down, work on it, change it if they want,

00:11:19 ◼   ► and so on. It's not perfect, but I think it does a great job at that. I think GitHub is

00:11:24 ◼   ► For collaboration purposes, I've never really gotten into all the crazy stuff you can do,

00:11:29 ◼   ► that some organizations will do.

00:11:33 ◼   ► You can do milestones and issues and all kinds of stuff like that.

00:11:35 ◼   ► Primarily, I just use it for open source stuff.

00:11:39 ◼   ► And all my own stuff I actually don't even use at GitHub.

00:11:42 ◼   ► All my own stuff I hosted Bitbucket.

00:11:45 ◼   ► And I hosted Bitbucket because they have a much better plan for the independent,

00:11:48 ◼   ► for someone like me, where they charge based on a number of users,

00:11:52 ◼   ► rather than a number of repositories, which is always kind of cumbersome and annoying

00:11:56 ◼   ► for me at GitHub.

00:11:58 ◼   ► Because I have many dozen repositories.

00:12:01 ◼   ► If you've been listening to the show for any length of time, you know that I have a bit

00:12:07 ◼   ► of a problem with starting new projects and thinking about things and creating new products

00:12:10 ◼   ► and shipping new products.

00:12:12 ◼   ► And so I tend to have lots and lots of our code repositories.

00:12:14 ◼   ► I think at some point I was paying GitHub for that.

00:12:18 ◼   ► I was paying essentially their max rate, which isn't a crazy amount of money.

00:12:23 ◼   ► I think I was $50, $60 a month.

00:12:25 ◼   ► But still, it wasn't really needed.

00:12:27 ◼   ► For Bitbucket, my purposes are much, much less expensive, if anything.

00:12:30 ◼   ► I'm not sure.

00:12:31 ◼   ► I may even still be in the free plan, even.

00:12:34 ◼   ► It's a much better fit for a small developer, for somebody who is just trying to...

00:12:38 ◼   ► It's really just kind of an archive for me in a way that I can pull down my code from

00:12:42 ◼   ► somewhere else if I need to.

00:12:44 ◼   ► But that's kind of what I do for source control.

00:12:48 ◼   ► A couple of resources I'd say is definitely

00:12:51 ◼   ► go to look at Pro Git, which is an online free book.

00:12:55 ◼   ► I believe that you can also buy the book.

00:12:57 ◼   ► But it's a great little book if you are learning Git

00:13:01 ◼   ► and kind of not really sure how to work your way around

00:13:03 ◼   ► or you're trying to solve a specific problem.

00:13:05 ◼   ► You're kind of getting into what's the difference between a rebase

00:13:08 ◼   ► and a merge.

00:13:09 ◼   ► It's a great book for that.

00:13:10 ◼   ► I'll have a link in the show notes to it.

00:13:12 ◼   ► But otherwise, it's the kind of thing you just play with.

00:13:15 ◼   ► And you just want to learn some of the patterns

00:13:17 ◼   ► that you want to get good at.

00:13:19 ◼   ► And of course, I would be remiss on an iOS development podcast

00:13:23 ◼   ► talking about source control to not mention

00:13:25 ◼   ► that there are a lot of files that you'll

00:13:28 ◼   ► interact with in an Xcode project that do not merge well.

00:13:32 ◼   ► And these are nibs, and these are the Xcode project file.

00:13:37 ◼   ► And these files are essentially unmergeable.

00:13:41 ◼   ► Project files are slightly mergeable, and nibs are just impossible.

00:13:45 ◼   ► Your head will explode trying to merge them.

00:13:48 ◼   ► You need to be very careful whenever you're working with one of these,

00:13:51 ◼   ► primarily to make sure that you're not going to be crushing other people's problems

00:13:56 ◼   ► or creating problems for other people.

00:13:58 ◼   ► If two people edit a nib file and then you're trying to merge that together,

00:14:01 ◼   ► you almost always need to just pick a winner

00:14:04 ◼   ► and then reapply the changes that you made to someone else.

00:14:07 ◼   ► Always be aware of that.

00:14:08 ◼   ► Anytime you change a nib in a collaborative environment, make sure that you are pushing

00:14:13 ◼   ► that very quickly and other people are pulling it before they make other changes.

00:14:16 ◼   ► So just pro tip, I've made that mistake enough times to know that it's a big pain.

00:14:20 ◼   ► All right, that's it for today's show.

00:14:23 ◼   ► As always, if you have questions, comments, or concerns, I'm on Twitter @_DavidSmith.

00:14:26 ◼   ► I'm on AppNet @DavidSmith.

00:14:29 ◼   ► And otherwise, like I said, this is a great time if you have questions, specific questions,

00:14:33 ◼   ► problems, things that you are struggling with, things that you are wondering about.

00:14:36 ◼   ► I'll do my best to answer. Just hit me up on Twitter. If you want to email me, if you have a slightly more lengthy thing,

00:14:41 ◼   ► I'm David@David-Smith.org.

00:14:43 ◼   ► But otherwise, I hope you guys have a great week and weekend and happy coding. I'll talk to you later. Bye.