How To Use GitHub Branches & Pull Request
Let's learn how to use GitHub📅 2025-04-18
Transcript
[00:00] let's find out everything we need to know when it comes to GitHub and branches welcome back y'all in this video let's go over branches and how that applies to our web applications our software basically any context when it comes to coding I do a lot of content on this channel around creating actual software or just leveraging artificial intelligence when coding in this new age so that's pretty cool you can check me out there and one really big reoccurring request idea or situation is what the heck is a branch how do we properly commit and essentially everything we
[00:30] need to know about the software creation process when I say software let's just use that as a bous term here for any type of coding in any context pushing committing everything this video idea actually came from my school Community you can check it out description down below hit the link let's proceed in order for me to best showcase this we're going to go to a real code repo for a real website and this code right here was on a 3-hour 30-minute playlist that showed me creating my own website which is this one right here completely mobile responsive everything good to go links
[01:01] work nice little enlarging when you hover over everything we love in websites so what is a branch and why do we use it let's go and create one personally I like creating a new terminal window when doing these commands but in theory you can come down here click this and just click terminal right there and then it'll be exactly where your code is located when pushing these kind of commands if that didn't make any sense put it this way basically we need to access where this codee's located which is in web Cafe land for me that's just a folder on my computer now for me to access web Cafe land the
[01:31] folder with all my code the command for me is simply CD web Cafe land if you don't want to deal with that you don't want to open a new terminal window that's fine just simply go through the process I showed you earlier where it opens up a terminal window within the IDE integrated development environment that's what this is It's vs code wind surf all that for now though we are within the code directory once we're here let's create a separate Branch because the first reason we create separate branches is so that we never commit and make changes on our main branch main branch is the code that is
[02:01] currently live within production when I say production that means the live website link you see up there and everything that's going on right here this is Live code therefore we know that when it's in production or that live website link it's not broken it's good to go so that's the first reason and first major reason we create branches so when we make changes here we know we're not messing with good code so let's make our Branch we're going to say get Branch just to see what we're on okay we're on Main this is going to create one locally we're going to do get check out B and then we're going to call our
[02:32] Branch name typically what you'll do is that the branch name is going to be whatever you're changing about the underline application you have so let's say we're going to make a change to our footer right here what I would do is some type of general term we'll just say footer change and there we go so now we are in the branch of footer change this is an exact duplication of main there is no difference between main code and footer change code right now do the exact same here's the difference though I click her IDE VSS code cursor click it it'll change down here now we're in footer change what this means on a
[03:04] service level is this I go like this I put a comma here I say test one two 3 so we got test 1 2 3 in footer change so when we make a differentiation between Main and footer change you're going to notice a little asteris here that says hey there's something different from the original code locally what we can do here is now we can push this to our GitHub as a side note if you want to know how to connect local code to the cloud like GitHub I'll leave a video in the description down below that shows you how to do it in 30 minutes with Resources by a Google DC that's not the purpose of this video get add get commit
[03:36] this is when we're changing and adding committing changes to our Branch here right so we can just say add a comment and what you'll notice is going to do a couple things so we're going to get push origin and we're going to do the branch name which is foot or change and then we're going to jump over to GitHub first thing it's going to do is it's going to remove that asterisk because the local code and the cloud code exact same comeing over to our GitHub you will notice it will come in as a PR request purpose of this is now we have separated the original main code everything that was here and we have that slight
[04:06] differentiation here of that test 123 that we added as a comment now typically what I like to do is we can just pull this in right away right create our little PR request here great pull request and this is live now we haven't merged to main yet which I'll describe why we do that and everything about that but for now you successfully created a separate branch that currently is a PR within the cloud request so now here we go we now know that in footer change this is going to be a change we make to the footer that's what we call forter
[04:38] change so let me go through some best practices of When approaching PRS and just branches in general first off I'm going remove this test 1 2 three second off let's go to a footer file so here's 101 of when we just do commits like when is an opportunity for a commit I suggest you do commits when you feel like you're at a safe spot and a lot of work you put towards a file so what I mean by this is assuming we look at this footer here let's just say I go crazy here and I'm like you know what I don't want any of these columns I delete all this delete save like that's it I don't want any of
[05:08] these columns this would probably justify a save SL checkpoint that you would want to commit to your PR because it's so drastically different than the original main code that we had because compared to this the main code still had that so this would be what we call a commit so get add dot get commit and what I suggest you to do especially early days if you're like what the heck do these even mean what's going on why is there three different commands put them in a sticky note have them on your desktop get ready to go this though is going to be our second commit here get
[05:39] commit DM remove all links in footer so second major tip I can give you here is whatever the commit is give it very much Clarity it's like when you play a video game and you have like a checkpoint you know when you're playing Skyrim and you're like about to go to Winter Hall I think it's called and maybe like attack the entire city and you put a little checkpoint in your game like before attacking City because it can get a little crazy same idea here remove all Links of footer or like roll back to this if you need to have the links back
[06:09] whatever it may be this is like saving a checkpoint that we can roll back to we're going to do get push origin footer name or Branch name for the change so what we're doing here is come over here and then you'll notice is that we have two different commits here and here we go the idea is this though watch this we got added comment that was the first one we got remove all footer links that's fine this right here is how we're going to roll back this is how we roll back to a checkpoint so I'm going to show you how to do that because it's actually very valuable and that's very much why we use branches as well is for this
[06:40] ability to roll back so let's say I keep going here like okay explore my ways to build whether it's in the mountains you know I'm like not the mountains let's say the lakes and then I hit save again and we'll do another commit so then I come over here I'm like get add get commit same situation as you'll notice here the more you add or the more you do these little pushes it'll be like very natural get push origin for the change okay we're good to go we keep going we keep going we're working and working and at a certain point we may get to so many commits and we're like hold up I think we went down the wrong path here and
[07:11] this is just no good which happens EG the application kind of broke in or you just took the footer down a path that you're just like whoa I do not like how this looks what's great is that because we created these little save checkpoints we can just roll back to one of these so let's roll back to the checkpoint before I removed all the links in the footer because I think I need some links so I'm going to go and copy this your next question might be Corbin how the heck did you get to this page don't worry come to your repo here go to pull request click the underlying PR that we
[07:41] created together go to commit and then this is where it's found right here right above me before I show you how to reset hard to a previous checkpoint there's also another valuable thing you can do if you don't want to take this route simply click the commit so if I click added comments here you know it's only going to show you what you changed very specifically within that commit but some times you may want to look at the entire code repo up to this point actually to see what the code repo was up to that point it seems like they moved some stuff around here in GitHub go back to your PLL request here added comment commits and then all we actually
[08:13] have to do is click this little button right here we can browse the underlying code up to this point which can be useful in the context that maybe you don't want to do a full-on reset but you're like you know what I remember in my source file I just kind of want to grab the original code found in app.js assuming though it's red alert and we're like we just messed up Corbin we got to go all the way back to the beginning and go to our original save point here we go we're going to come over to our IDE here obviously have your terminal window open in your terminal window we're going to do this command you're going to grab what you just copied and you're going to
[08:44] add this get reset Das Das hard and then whatever you just copy paste then you're going to hit enter boom what you'll notice is that we just got all our links back and we just went back to that checkpoint that we said this is fundamentally very important and why I always encourage this kind of development as this gives you more free will where you can feel comfortable when you get to a save point to maybe take that risk on what you are coding next what I mean by this is that in software
[09:14] development web app development or whatever kind of development you do there are going to be times when you are coding certain things components or functions or whatever it may be that you might not be 100% confident on you're going to take the risk of maybe like really messing with the file to try to get the end value point and now you have the insurance of being able to roll back to previous commits which is just fundamentally amazing honestly like I said it's like playing Skyrim rolling back to pre- attacking winter Hall I think it's winter Hall is it winter Hall okay it wasn't winter Hall it was Winter
[09:46] Hold shout out to Skyrim this was an amazing game growing up once you're satisfied and you're good to go and you're like you know what Corbin I like my Branch I'm good to push this all the way let me actually do this with you so it's very clear so to confirm we have the correct Branch here okay we got our links here renamed that Mountains from Lake the abjs we did test 1 2 3 4 and the command I used uh in order to assure this clean would happen correctly as before you might get this very annoying situation here because we did the force roll back of like hey fail to push because you know it's fast forwarding I
[10:18] don't care so we're going to go ahead and just do get push Force origin forter change is going to force your local code to be like okay I got it I got it we're going to go to that very specific branch commit that we did way earlier and clean it up between the cloud and your local so then what you'll notice is that our commits here go all the way rolled back here to added comment and clean it removed all that original commits that we had that may have went down a route that just wasn't good so from here it's very simple once we get to a point where the branch is good to go we've tested npm start everything looks clean I'm
[10:49] going just leave this in here honestly we can go to merge and to do that we're going to go to our pull request here add a comment and what merging is doing is we're taking this br branch and just merging it to main watch this this will make more sense merge Pro request confirm merge once we merge we can actually just delete this Branch don't worry if you ever need to reference this specific Branch again we can just restore it but it's just common practice to just delete the branch and the only thing different now from the main and footer change if you remember is going
[11:20] to be this one comment in line seven in our app.js so to confirm that a merge worked correctly you can now fundamentally understand what it means to merge a branch if I come back over to my repo here and I go to my main branch right here which you'll notice merge pull request for for the change the only change I should see here is in that appjs let's see there we go it was successfully merged back into the main code now from here in theory once we're going to go I could deploy this to my web app but as you can probably already expect there's really no reason to
[11:51] deploy because it's just a comment and only I can see that no one can actually see that within the application itself That Just About Does it so make sure to leave a like if you feel like you learned something in today's video and what I always tell my software Engineers When developing with branches they give it like a game checkpoint think of it like playing Mario you hit the little flag you can always roll back it's a very very good practice to have also it allows for the ability for scalability within a workplace environment due to the fact that you can have multiple Engineers have separate branches for a specific repo that's a whole different conversation but for now I'll see you in
[12:22] the next video multiple branches footer Change Main two random videos that's my face I'll see you in the next video