Branches, Merging and More

Just to review, in our last video we set up a GitHub account, created a new repo, 0:00 added our new Xcode project, made commits, explored GitHub and pulled some changes. 0:05 Now, we'll pretend that we're working on a collaborative project and 0:11 we'll need to be creating branches and merging. 0:14 So, like I said, we're collaborating on a project. 0:17 Now in a second, I'll open that project and we'll take it from there. 0:20 But first I'd like to spell out what we'll be doing. 0:23 First, we'll create our own new branch to work in. 0:26 After we make some changes to that branch, we'll eventually wanna merge any 0:28 recent changes our team has committed and pushed into our branch. 0:32 Just to illustrate a point, I'll be sure we have some merge conflicts, so 0:37 we can see how to resolve them. 0:40 Now, just to be clear, branching, merging and 0:42 resolving conflicts aren't processes that only happen collaboratively. 0:44 Generally, when you have more developers working on the same code base, you'll need 0:49 more branches to keep everyone moving forward without disrupting each other, 0:52 which in turn, will mean more merges and perhaps more conflicts to be resolved. 0:56 But creating new branches is absolutely something you should put to use, 1:00 even on solo projects. 1:04 Doing so allows for a very clean and safe segregation of your code and is often much 1:06 better suited to experimentation, feature enhancement, and more. 1:10 For example, I recently had an old app that I hadn't touched in years. 1:15 It sells on the App Store, but 1:19 doesn't make enough money to warrant any new feature enhancements. 1:20 When the Apple TV came out, I thought it made sense to try and rework the app for 1:23 a living room experience. 1:27 The first step in that process was creating a new tvOS branch 1:29 that allowed us to benefit from all the work that had all ready been done and 1:32 not worry that our new changes would jeopardize the existing code. 1:35 Surely, when trying to build an Apple TV app, 1:40 which was uncharted territory at the time, 1:42 we'd probably end up breaking our existing app and there was no reason to risk that. 1:44 Also, down the road, once our tvOS app is done, we could in theory, merge it 1:48 back into the original to create a single universal app if that indeed made sense. 1:53 So, like I mentioned before, I've been asked to collaborate on a project. 1:59 I've been sent the link to the Git repo, so let's check out an existing project. 2:02 That replaced window just popped up because I demoed this myself beforehand, 2:16 but that's not gonna pop up for you on a real project. 2:20 Now this app is called Potluck and it's just a sample app provided by Apple. 2:24 You can download the code. 2:28 By the way I'm only creating this repo as a temporary demo for 2:30 you also don't go looking for it on GitHub. 2:33 If you want your very own copy, I've supplied the link below. 2:35 Anyway we can run the app 2:38 And it's nothing too exciting here. 2:51 It's a location based app, and I'm running in the simulator. 2:53 Let's just click this button, and we see the text changes up here. 2:56 Location manager updating. 3:03 Okay, now I've been tasked with improving the text user C on the home screen. 3:07 The team leader has said that this feature is number 8675309. 3:13 We're gonna quit our sim. 3:16 Now, let's go up and create ourselves a new branch. 3:20 Since we have a feature number, we're gonna do that. 3:23 Now, Xcode assumes that when you create a new branch you'll want to use that as your 3:34 working copy, so that's where I am. 3:38 You can confirm that by going to source control and now you see the repo 3:41 followed by the branch here that we created Feature 8675309. 3:45 If I wanted to, I could switch back to the master branch, 3:47 by clicking Switch to Branch and then I'd have that choice. 3:53 Okay, so my task was to change the text and improve on it. 3:57 Let's see if we can find that. 4:01 So right here, in our view controller, we see we've got some strings here. 4:05 Location manager updating. 4:11 I don't love that. 4:16 Let's change that a little bit. 4:17 It sounds redundant, we know it's a location manager. 4:18 Let's just call it Manager updating. 4:21 We'll also change this second one just to manager updating. 4:25 I'm gonna save my file. 4:28 And now you'll see, this little M showed up here. 4:32 That indicates that the file, this file has been modified. 4:35 Once I commit, like this, 4:40 You'll see the M has gone away. 4:52 Those Ms by the way can be very helpful if your code just suddenly stops working and 4:54 you aren't sure what you may have broken. 4:59 Assuming that you saved but didn't yet commit, it's a good place to look for 5:01 first clues. 5:05 Now let's pretend that that's the only change we need to make and 5:07 that I've already tested the app. 5:10 I've spoken with the team lead and they say they definitely don't want me to merge 5:12 my new changes back in the master yet. 5:16 However, they do want to make sure that my changes jibe nicely with 5:19 anything else that may have changed in master. 5:23 The way we can do this is by merging master into my branch. 5:26 Now of course I just created this branch a second ago. 5:31 So there probably aren't any changes to master yet. 5:34 Just for kicks, I'm going to hop in to GitHub and make a change. 5:37 Now here you see that I'm in GitHub and I'm looking at the same repo. 5:42 But I'm not me, I'm this other guy, whynoserous who looks suspiciously 5:46 like me, and I'm gonna change one of the things that we changed in Xcode. 5:50 So this is like a collaborator on the project changing the repo. 5:55 Now they're still gonna be working in the master branch, 5:59 And we'll update that first string that we updated before. 6:15 And of course we'll have to go back down and 6:20 commit In real life 6:23 your collaborators would be doing this in Xcode probably not right on GitHub. 6:29 But this just shows you that someone else on the team is doing it and 6:33 now our work flow will continue inside Xcode. 6:37 So here back inside, we wanna make sure our branch is up to date as possible. 6:40 We'll eventually wanna merge our changes back into master. 6:47 But for now we wanna merge master into our branch. 6:51 That helps test for compatibility. 6:54 And it also means that when the time comes to merge our changes back into master, 6:56 there won't be as many differences to present potential problems 7:01 since we already have many of those changes in our branch. 7:04 Okay, so let's merge. 7:08 We can see here that we can merge from a branch 7:11 into our branch, and we can do that from master. 7:16 There are no changes to merge from the branch master. 7:24 Well why is that happening? 7:27 That's right. 7:30 The reason that's happening is cause we haven't pulled the changes. 7:31 AKA those changes that I just made when I was pretending to be whynoseros pn GitHub. 7:34 They only exist on the remote. 7:39 They don't exist on my local repo. 7:41 To pull those, what we need to first do is switch to that branch. 7:44 And then we can pull. 7:55 When we do that You'll see that it's updated to what we entered on GitHub. 7:58 Now we can merge the master into our branch. 8:06 Remember this is not the same thing as merging our branch into master. 8:09 When you merge you're only changing the branch you merge into, 8:13 the other branch remains unchanged. 8:16 Okay, here we are. 8:32 But our merge button is grayed out and we have this red C icon over here. 8:34 Red icons are almost never good. 8:41 And as you might have guessed, that red icon is the reason we can't merge. 8:43 The C stands for conflict by the way. 8:48 Git, in its magical wisdom has decided that there are changes in the two branches 8:51 that relate to the same code and it can't figure out which code to keep. 8:55 Let's click on it. 8:59 If you notice, one of the changes seems fine and isn't showing a conflict. 9:01 This one down here. 9:05 That's because we never change that line in our master branch. 9:07 So Git assumes that the line that we changed 9:10 over here locally is the one we want going forward. 9:13 That said, I could still overwrite it in my branch by clicking here. 9:17 But I won't do that. 9:25 We'll just leave it. 9:27 Now, up here, where we have the question mark, that's our conflict. 9:29 You can resolve it in four ways using these buttons down here. 9:33 Starting from the left, 9:38 this will keep both lines with the working copy change up top. 9:40 The next button just keeps the working copy. 9:44 By working copy of course I mean the branch we're in, 8675309. 9:47 The next two buttons would keep just the master version. 9:50 And lastly it would keep both versions with the master as first. 9:55 Now at the beginning I mentioned there is much more you can do with Git. 9:59 I absolutely encourage you to take the complete tree house Git 10:03 course linked below but it is lengthy and for the time being you may be more 10:06 concerned with getting up and running and using X code safely and collaboratively. 10:10 To that end I'll bring our workshop to a close by showing just a few more things 10:14 you can do here inside of X code. 10:18 So let's merge this, so the first is viewing version history. 10:21 One way to do that is simply to go to source control history, 10:26 And inside, we see a list of all the commits to this branch. 10:32 It shows them in reverse chronological order along with who made the commit, and 10:36 a timestamp, shaw, and if you click this 10:41 right here where it says how many files were modified you can get a list of them. 10:45 Now when you're in here. 10:52 You can't edit. 10:54 But you can copy code out of here and 10:55 paste it back into the editor if that's useful. 10:57 You can also send an email to one of your collaborators if you'd like. 11:00 Now speaking of older versions which we might have down here. 11:07 Sometimes you'll find changes that you made aren't what you actually want. 11:10 Maybe they broke something else in the code or 11:15 perhaps you were just tinkering and you want to go back. 11:17 Well if you haven't yet committed those changes. 11:20 You can head to Source C>Discard All Changes. 11:23 If you do that the changes are gone. 11:28 But what if the changes you wanna get rid of have already been committed or 11:31 what if you want to get back to some state your code was in six commits ago? 11:35 To do that we're gonna use the version editor. 11:39 We'll head to view Version editor, comparison view. 11:42 Once here you can compare different commits by tapping on the clock icon or 11:49 using your menu down here 11:55 And then you can scroll through. 12:07 And see your changes. 12:09 You'll notice on the right side here we have these little horizontal lines which 12:11 indicate where changes that's a very helpful when you have a very long file and 12:15 you're not sure changes are. 12:19 By the way they disappear when you're not scrolling. 12:21 So you have to start scrolling again to see them. 12:23 When we see changes here we can get at them by hiding the center panel. 12:26 And then, you have some choices here, they're grayed out now but 12:30 often you can discard your changes. 12:33 Let's find a more recent one and see if we can do just that? 12:36 Okay here we go. 12:48 Let's discard that recent change. 12:50 If we go back to our traditional editor. 12:54 We're going to see that now we have an M here. 12:58 Since we discarded that change, we now have a modified file. 13:01 But we didn't commit it yet. 13:05 So of course we could still commit or discard that most recent update. 13:07 So just for fun let's commit that change. 13:12 And again we're just committing the changes in this file right here. 13:22 Our M should disappear. 13:29 That's good. 13:31 Not just for fun. 13:32 Let's head to our history again. 13:34 So what we see now is that we have a recent commit, the commit we made 13:38 at the beginning of our lesson and then a whole bunch of old commits. 13:42 Again just to be clear we didn't rewind our code to that point in time and 13:48 lose everything that happened since. 13:52 We simply discarded the old change and made a new commit. 13:55 This gives us a lot more safety and 13:58 transparency, if we ever need to go investigating these changes in the future. 13:59 By the way if you ever find that you want to revert your entire project, 14:04 you won't be able to do that in Xcode in unless you go file by file. 14:08 To revert in one fell swoop. 14:12 You'll want to either work from terminal, GitHub or GitHub desktop client. 14:14 If command line reverts interest you, I've supplied a link on that below. 14:19 I hope you found this intro to get in lightning using a VCS like get 14:24 is an essential part of working as a developer either independently or 14:27 on a team We've given you the basic tools and processes here but 14:30 there's plenty more you can learn in our full Git course linked below. 14:34 I would strongly suggest you make time to work through that when the time is right 14:37 as future employers may expect you to be comfortable using git on the command line 14:41 or taking advantage of more advanced features. 14:45 Until then have fun with your repos, branches, commits, and 14:48 merges it's a way of life. 14:51 See you soon 14:53