1 00:00:00,210 --> 00:00:00,690 Okay. 2 00:00:00,690 --> 00:00:06,140 So as we've seen the centralized workflow aka everyone works on one branch is not ideal. 3 00:00:06,150 --> 00:00:07,450 Quite a few issues. 4 00:00:07,470 --> 00:00:10,680 That brings us to our next workflow feature branches. 5 00:00:10,680 --> 00:00:13,170 I don't really know what to call it, but that's the concept. 6 00:00:13,200 --> 00:00:17,190 Work on feature branches don't work on master you silly goose. 7 00:00:17,190 --> 00:00:18,480 That's the main idea. 8 00:00:18,480 --> 00:00:24,120 If the centralized workflow is everyone works on master, the feature branch workflow is nobody works 9 00:00:24,120 --> 00:00:25,230 on Master or Main. 10 00:00:25,230 --> 00:00:27,510 You always work on a feature branch. 11 00:00:27,510 --> 00:00:29,880 This is a very, very common pattern. 12 00:00:29,880 --> 00:00:35,790 Rather than working directly on the master branch or the main branch or any centralized branch, all 13 00:00:35,790 --> 00:00:41,640 development, whether it's something tiny or some massive new feature or a redesign or a bug fix, all 14 00:00:41,640 --> 00:00:44,010 development should be done on separate branches. 15 00:00:44,010 --> 00:00:49,860 So part of this means treating the master or main branch as the official project history. 16 00:00:49,860 --> 00:00:51,500 The branch right? 17 00:00:51,510 --> 00:00:55,050 Like the sacred branch that you're not going to work on. 18 00:00:55,800 --> 00:01:02,340 Instead all work is done on these side feature branches and then merged back in to the master or main 19 00:01:02,340 --> 00:01:03,930 branch when appropriate. 20 00:01:04,170 --> 00:01:10,440 This allows multiple teammates to collaborate on the same feature without having to mess up the master 21 00:01:10,440 --> 00:01:11,370 or main branch. 22 00:01:11,370 --> 00:01:17,760 Like with what happened with the centralized approach to share broken code or incomplete code also meant 23 00:01:17,760 --> 00:01:19,410 breaking the master branch. 24 00:01:19,410 --> 00:01:24,420 So with this feature branch workflow, I could have a branch that never works. 25 00:01:24,420 --> 00:01:29,850 It's always broken and I can collaborate on that with anybody else, any number of collaborators. 26 00:01:29,850 --> 00:01:36,180 So my master or main branch should not contain any broken code unless somebody messes up and thinks 27 00:01:36,180 --> 00:01:39,930 code is not broken and they merge it back in and it actually is broken. 28 00:01:40,470 --> 00:01:41,940 So back to our diagrams. 29 00:01:41,940 --> 00:01:45,600 Here's the same three characters Forest, David and Pamela. 30 00:01:45,690 --> 00:01:48,210 They all clone the same GitHub repository. 31 00:01:48,210 --> 00:01:51,900 It starts with two commits and a master branch or a main branch. 32 00:01:51,930 --> 00:01:54,660 In this diagram, master is the default branch name. 33 00:01:54,870 --> 00:02:00,000 So Forrest clones it, Pamela clones it and David claims it. 34 00:02:00,030 --> 00:02:01,530 Everyone's at the same point. 35 00:02:02,850 --> 00:02:04,580 So we work on feature branches. 36 00:02:04,590 --> 00:02:06,630 David starts working on a new feature. 37 00:02:06,630 --> 00:02:09,780 He's working on a branch called Add Dark Theme. 38 00:02:09,780 --> 00:02:12,720 So he's hit a point where he's not totally done. 39 00:02:13,140 --> 00:02:19,560 He's maybe 30% of the way there, but he wants to share his work with the rest of the team, and specifically 40 00:02:19,560 --> 00:02:21,230 he wants some help from Pamela. 41 00:02:21,240 --> 00:02:24,660 He wants her feedback, or maybe he wants her to write some code. 42 00:02:24,960 --> 00:02:29,820 So he pushes his branch up, he pushes add dark theme up to GitHub. 43 00:02:29,910 --> 00:02:32,190 So he didn't merge it into master, right? 44 00:02:32,190 --> 00:02:33,660 It's not merged into anything. 45 00:02:33,660 --> 00:02:36,060 He just pushes that feature branch up to GitHub. 46 00:02:36,390 --> 00:02:42,030 So at the same time during this morning or afternoon or whatever it is, Pamela has been working on 47 00:02:42,030 --> 00:02:44,670 her own new feature, Animated Scroll. 48 00:02:44,670 --> 00:02:46,590 It's the name of the branch she is working on. 49 00:02:46,620 --> 00:02:47,940 It's a totally separate branch. 50 00:02:47,940 --> 00:02:49,950 It's in yellow here to make that clear. 51 00:02:50,370 --> 00:02:51,540 She's not working on Master. 52 00:02:51,540 --> 00:02:55,200 Nobody works directly on Master or Main, so she's working on her branch. 53 00:02:55,200 --> 00:02:56,460 She's made good progress. 54 00:02:56,460 --> 00:02:59,550 But then she gets a chat message from David. 55 00:02:59,550 --> 00:03:04,530 David sends her a slack, saying, Hey, Pam, can you please take a look at the work that I did today 56 00:03:04,530 --> 00:03:05,700 on the branch? 57 00:03:05,700 --> 00:03:06,360 What was it called? 58 00:03:06,360 --> 00:03:07,500 Add dark mode. 59 00:03:08,040 --> 00:03:09,420 Is that what it was at Dark Theme? 60 00:03:09,420 --> 00:03:14,370 Can you take a look at that branch, pull it down from GitHub and let me know what you think and add 61 00:03:14,370 --> 00:03:15,420 some of your own work. 62 00:03:15,420 --> 00:03:17,220 So that's what she does. 63 00:03:17,310 --> 00:03:19,770 She pulls down that branch. 64 00:03:19,800 --> 00:03:23,520 She didn't have to stop what she was doing and merge this into some other branch. 65 00:03:23,520 --> 00:03:28,320 She can just leave her animated scroll branch where it was if she's not ready to share it and she just 66 00:03:28,320 --> 00:03:29,730 pulls down his branch. 67 00:03:30,060 --> 00:03:34,860 So we've seen how to do that and how we can switch to a remote branch we can fetch to see if there are 68 00:03:34,860 --> 00:03:37,830 new branches that we don't have and then switch to them. 69 00:03:37,830 --> 00:03:43,290 So she gets his feature branch down at Dark Theme and it doesn't pollute the master branch, it doesn't 70 00:03:43,290 --> 00:03:44,820 pollute her animated scroll. 71 00:03:44,850 --> 00:03:47,130 They can co-exist side by side. 72 00:03:47,880 --> 00:03:48,930 So she takes a look. 73 00:03:48,960 --> 00:03:50,270 She makes a couple of improvements. 74 00:03:50,280 --> 00:03:53,670 She even adds her own commit on the same feature branch. 75 00:03:53,820 --> 00:03:54,910 So it was three. 76 00:03:54,930 --> 00:03:56,310 Now it's four commits. 77 00:03:56,310 --> 00:03:57,710 So she pushes those up. 78 00:03:57,720 --> 00:04:00,070 Add Dark Theme is now updated on GitHub. 79 00:04:00,090 --> 00:04:03,510 She tells David, Hey, I added some new work. 80 00:04:03,510 --> 00:04:05,310 Go ahead and pull down those changes. 81 00:04:05,640 --> 00:04:08,320 And so he returns to work the next morning. 82 00:04:08,340 --> 00:04:13,620 I guess this was late at night or evening and after some editing in the morning he decides, okay, 83 00:04:13,620 --> 00:04:15,000 I guess I should get back to work. 84 00:04:15,000 --> 00:04:18,720 But all that he has are these three commits on add dark theme. 85 00:04:19,019 --> 00:04:24,600 All he needs to do is pull down, see if there's any new information he could fetch first to check, 86 00:04:24,600 --> 00:04:30,660 but he gets the new work from that branch on GitHub that Pamela did, and now he can continue his work. 87 00:04:30,660 --> 00:04:36,780 And then at some point, maybe he decides he's happy with the new feature and he can merge it into Master. 88 00:04:36,810 --> 00:04:38,520 So that's what I'm illustrating here. 89 00:04:38,940 --> 00:04:42,810 So that actual mechanic, your mechanism for merging into master. 90 00:04:43,200 --> 00:04:46,350 Usually you don't just decide if you're at a big company, you don't decide. 91 00:04:46,350 --> 00:04:47,940 All right, this goes in, master. 92 00:04:47,970 --> 00:04:49,620 There are usually some controls. 93 00:04:49,620 --> 00:04:51,740 I mean, at the very least, there's code review. 94 00:04:51,750 --> 00:04:55,610 Somebody or a team of people need to look at what you've written, right? 95 00:04:55,620 --> 00:04:57,030 Things need to pass tests. 96 00:04:57,030 --> 00:05:00,420 So it's not a matter usually of just merging it in whenever you want. 97 00:05:00,420 --> 00:05:06,090 And we'll talk about some of those mechanisms for code approval and rejection, but that doesn't really 98 00:05:06,090 --> 00:05:07,720 matter for this workflow right now. 99 00:05:07,740 --> 00:05:14,400 All that matters is that when a branch is done or when a feature is done, it can be merged into master. 100 00:05:14,760 --> 00:05:20,340 So this would ideally and the way that this is supposed to work, this is a fully done feature. 101 00:05:20,340 --> 00:05:22,140 It's not broken, it's ready to go. 102 00:05:22,320 --> 00:05:24,810 Then we merge it into the main branch of the master branch. 103 00:05:24,810 --> 00:05:31,530 We don't merge broken stuff in unlike the previous centralized workflow, so everyone works in a branch 104 00:05:31,530 --> 00:05:32,430 on a given feature. 105 00:05:32,430 --> 00:05:33,920 You can have multiple branches too. 106 00:05:33,930 --> 00:05:41,310 It's not necessarily like Pamela's branch and David's branch, it's more one branch per feature or branch 107 00:05:41,310 --> 00:05:42,390 per bug fix. 108 00:05:42,420 --> 00:05:48,390 Branches are feature oriented, so this allows us to then share those branches, collaborate on branches, 109 00:05:48,390 --> 00:05:55,320 and keep our master or main branch as the source of truth and our repository as the stable, always 110 00:05:55,320 --> 00:05:59,100 working, functioning, non broken branch in our project. 111 00:05:59,100 --> 00:06:04,590 And of course the last thing that would need to happen once David merges his new feature branch in is 112 00:06:04,590 --> 00:06:10,320 he would push that up so that GitHub is updated and now everyone's master branch would include those 113 00:06:10,320 --> 00:06:14,510 new commits, those new changes that he made on his feature branch originally. 114 00:06:14,520 --> 00:06:18,360 So that's the main idea, master or main or whatever you want to call it. 115 00:06:18,360 --> 00:06:21,210 You treat it as a branch that is not to be screwed with. 116 00:06:21,240 --> 00:06:23,170 It's the official project history. 117 00:06:23,190 --> 00:06:29,010 All work is done on separate branches and then those branches can be either abandoned or eventually 118 00:06:29,010 --> 00:06:31,680 merged back in to the official project history. 119 00:06:31,680 --> 00:06:36,840 Whether that's Master or Main, remember this slide from the centralized workflow? 120 00:06:36,870 --> 00:06:40,200 These were all problems with working on one branch. 121 00:06:40,200 --> 00:06:43,080 No one can work on anything without disturbing the main code base. 122 00:06:43,080 --> 00:06:44,160 That's not a problem. 123 00:06:44,160 --> 00:06:45,720 If you're working on a feature branch. 124 00:06:45,720 --> 00:06:49,910 The only way to collaborate on a feature is to push incomplete code to master. 125 00:06:49,920 --> 00:06:51,510 Nope, that's not a problem. 126 00:06:51,510 --> 00:06:57,330 Now if everyone works on feature branches, way less time spent resolving conflicts and merging code 127 00:06:57,330 --> 00:07:01,890 because now code only needs to be merged when something is ready to go into master. 128 00:07:01,900 --> 00:07:08,190 Not any time anybody does literally any commits, which is what happened when everyone works on one 129 00:07:08,190 --> 00:07:08,830 branch. 130 00:07:09,300 --> 00:07:10,950 In conclusion, feature branches. 131 00:07:10,950 --> 00:07:12,090 Much better approach.