# Git Tutorial for Beginners | Part 4: Merge, Rebase & Commit Mastery

## Метаданные

- **Канал:** Codecademy
- **YouTube:** https://www.youtube.com/watch?v=KiV2D7RaQ48
- **Дата:** 20.11.2025
- **Длительность:** 1:03:54
- **Просмотры:** 699
- **Источник:** https://ekstraktznaniy.ru/video/45981

## Описание

Welcome to Part 4 of our Git & GitHub workshop series!

In this session, Club Captain Nick Edwards takes you deeper into advanced Git techniques, building on what you learned in Part 3. Learn how to manage commit history and optimize your workflow for smoother collaboration.

🔧 What You’ll Learn:
• How to modify commit history: merge strategies, rebase, and squash commits
• How to stash changes and efficiently clean up your repo
• Best practices for writing clear commit messages, using short-lived branches, and managing Pull Requests

Whether you’re improving your Git skills or looking to refine your workflow, this session will give you the confidence to handle version control with ease.

📌 Watch Part 1 here:  https://www.youtube.com/watch?v=X3vlS6ip5V8
📌 Watch Part 2 here: https://www.youtube.com/watch?v=D0xV3GOY_Yk
📌 Watch Part 3 here: https://www.youtube.com/watch?v=kd33ydEtDvc

Learn Git on Codecademy: https://www.codecademy.com/learn/learn-git?utm_source=youtube&utm_medium=organic

## Транскрипт

### Segment 1 (00:00 - 05:00) []

Well, welcome to part four of our four-part Git Foundations workshop led by our esteemed club captain Nick Edwards. Uh, this event is for beginners for those looking uh for a refresher. Um, as well as those who don't know anything about like Git at all, although we are in part four. Um, and so hopefully after part four, you should feel a lot more confident with Git and GitHub. I'm Jonathan, the head of community at uh CO Academy and Nick Edwards, our steam club captain, he runs um the Boston club and he has already done three uh parts so which are all uploaded on YouTube so they can check out later. Uh so a bit about Nick, he is he uh enjoys coding on Salesforce. He enjoys uh doing a lot of testing on robot automations. And if there's anyone that's interested in Arc Raiders, definitely hit him up because he plays a lot of it. So, um but enough about me and me talking, I'll pass it to you, Nick. Nick, please take it away. — Awesome. Thank you, Jonathan. Uh welcome everybody. Um [clears throat] so, yeah, uh as Jonathan kind of mentioned, we've done a long series here on GitHub. Um you can find all the other events on uh the Code Academy YouTube channel. Today is the fourth event where we are going to be covering or more of a continuation of our last event where we were covering uh viewing commit history um looking at what different ways to modify that commit history via being merging rebasing. Those are the things that we covered last session. Today's session we're going to be focusing on things such as squashing uh and cherrypicking in particular. Um, and then after we review some of those materials, we're going to also be looking at uh, git stashes. We're going to be looking at git reset. Um, kind of a few different ways that you might be able to um, leverage to kind of clean up your branches and whatnot. You know, maybe you make some mistakes and you need to, you know, backtrack a little bit. So, we're going to be covering some of those techniques as well. Um, and then we're going to wrap up with a small discussion on some just best practices uh, for using Git in general. So, um, without further ado, we'll get started with the slide here. So, I always have this slide for all my events. I think it's really important to just call these out. It's also for me to encourage the group to ask questions, which is really that first uh bullet point there, be brave, be vulnerable. Um, you know, showing up here sometimes, you know, speaking out or asking questions can feel a little uncomfortable. I used to feel that way myself, but uh that is how we learn. Um, so I would encourage you guys if you have any questions throughout the session, please, you know, feel free to throw them in the chat. Um, Jonathan, I believe, will be watching that chat as well and may stop me uh periodically to help address some of those questions. I'll also make a note to stop periodically as well to ask uh ask for them as well. [snorts] Um, but be mindful and respectful, of course, you know, right? Um, that's super important. Kind of goes without saying, you know, be respectful of your questions. uh if other people are asking questions, you know, don't try to spam the chat or try to talk over others or whatnot. Um and you know, by doing all that, you guys are getting engaged and hopefully we'll have some fun along the way. Uh and anytime we do a demo, sometimes we have uh some minor hiccups here and there. So you guys get to watch me struggle, which you know can be fun. Uh but you know, may the demo god smile upon us. Uh so as I mentioned uh today's session, just you know, quick recap on that. We're going to be covering squashing and cherrypicking. I should have wrote cherry picking, not rebasing. That's my bad. Um, so just imagine that's a squashing and cherry picking. Uh, we're going to be going over resetting, uh, stashing, and then again, we're going to have that quick discussion on the suggested best practices. Uh, so let's go ahead and get started with squashing and cherrypicking. Uh, and of course, uh, if you want to go over merging or rebasing, just go to the Code Academy YouTube channel and look for session three. We did a pretty good cover of it there. Um, I'm going to actually take this uh I'm go back. I'm going to g actually go out of here for a second so that I can copy this because I think it's important that you guys have access to this. Um I'm going to be using this throughout the session today and it's also something that you guys can use um after the session to do some practicing with all the things that we've covered up until this point. Um what it is it's like a little bit of a workshop. So, the way that that's going to work is it kind of takes you through a step-by-step process. And I can actually I can pull that up here really quick as well. And that's not what we're looking for. How do I get this banner out of my way? There we go. Um, so this is what it's going to take you to. It's just a GitHub Git Skills um workshop. Um, different operations on commit history. So what you know there's a couple of different hyperlinks here but um essentially in a nutshell what it does is it takes you through a rock paper scissors application and you get to build the application. Uh there's all the code that you need in these app stages folder. There's uh four stages to the

### Segment 2 (05:00 - 10:00) [5:00]

process here. Stage one has all the just the root folders as the game starts. Um stage two has one update that you would com uh you would commit. Stage three has another commit and then stage four has a final commit. And so at the end of setting up the project, essentially what you start with is you start with a main branch that has the base application and then you have a feature branch that has three commits within that feature branch. And using the commits within the feature branch that enables you to explore how to use things like merging, rebasing, cherrypicking, squashing. Um, and you get to play some rock paper scissors against the computer throughout the process as well. So it's a little bit of a fun learning exercise. Um, we've used this before in the Boston community with one of the events I did uh earlier in the year, if not late last year. We had a lot of fun with it. So, and a lot of people learned a lot of things about these operations and so I wanted to share that with the group. So, let's begin with squashing. Uh, what is squashing? Squashing is a way for us to condense multiple commits into a single commit. And so bringing back that um that exercise that I just had on the screen, if we have that main branch and then you have that feature branch that's got three different commits in it, maybe you don't want to merge all three of those commits into your main branch. Maybe it's a small of enough feature that you want to take all those commits and condense them or squash them if you will uh into a single commit that you would then uh play on top of your main branch. Um it's kind of a way to keep the commit history condensed like small and practical and not have so many commits. Um you know one con to that of course is that if you like that granular commit uh level by squashing those commits you kind of lose insight into those all those individual commits. And um that's the one tradeoff of it that I would have to call out. Um, but other than that, it can be a really useful tool if you were doing a lot of different a lot of work in inside of a feature branch. Um, and you start to have a lot of commits in there. Maybe some of the commits are just for single line changes here and there as you're moving along. Uh, and instead of committing that whole history to your main branch, you just want to take all of it and condense it slwash it into a single commit. Um, some of the commands over here on the right are what you would use in that example. There are two different ways of going about this. Um, and actually, if I go back over to my workshop here and I go to my readme, I call those two different methods out. Um, the first method, which is, if we look at this code here for a second, the first method is where you're going to use this command right here. You're going to start in that main branch, and then you're going to squash that feature branch into your main branch. That's the first method. The second method actually has you start in the feature branch. you perform the squash there and then you have to commit it back to your main branch. Uh so there's two different ways of going about it. They have their pros and cons. Um I like to give favor to the first method. Uh and the reasons I have listed here. The first reason is it keeps the commit history of the branch uh being squashed intact. So what do I mean by that? If you start in the feature branch and you perform your squash in the feature branch, all three of the commits that you have there are going to be squashed and essentially you're going to lose those commits. You're going to replace them with one singular commit. Um, and that be might be an issue if you wanted to retain that commit history um within that branch and leave it untouched. Maybe you make a mistake through the process. um maybe you squash too much because sometimes you can take different commits, you can just squash a few of them into one and keep some of the others. And so it's kind of like a foolproof sorry uh process to retaining that commit history within that branch being squashed. [snorts] Um the second reason is avoids the need to use interactive rebase which uh usually makes use of your command line uh text editors like uh them for example. Um those tools can be confusing to a lot of people, especially if you're just getting started. Um if you guys have been a part of my uh events in the past, you guys know that I like to keep um what I teach simplified because I feel like it's easier to understand when we use simple concepts and simple terms. I don't like to make things too complicated because I think that gets in the way of learning. Once you learn like the foundation of something, it's much easier to build from there. Uh and I always try to take that approach with anything that I teach. Um, so enough talking about squashing. Let's get into an exercise for squashing so you guys can kind of see it in real time. Uh, I'm going to leave this up um just over here so that before I switch over to my VS Code. Um, I've already got most of the setup done here. So, if I actually switch over to my VS Code and actually move this to my other screen so it's out of the way. Um, and if you guys don't see what I'm moving, it's just it's the zoom bar. Uh, so if that wasn't showing up and you

### Segment 3 (10:00 - 15:00) [10:00]

guys were wondering what I'm doing, that's what it is. Um, but anyho, so over here on the right hand side, I've got a few different directories within this root directory, get workshop 4. It was just for the fourth event. Um, so uh don't worry about this practice one. This practice one was just the kind of the setup uh steps that I used before I copied it into uh three different repositories. Each one of these is a repository though, isolated in nature. So, if I make changes in one here, it's not going to impact anything over here. And the reason I did that is we have a few different examples that we're going to uh move uh through throughout the session. And I just wanted to keep that all isolated. So, we're going to start in the squash uh example folder. So, before we do anything, I'm just going to CD into that screen. Um so, if you guys recall from — Wait, are you muted? No. Yeah. But okay, Raleigh. — I'm just gonna mute. Uh — Oh, wow. I got I got it for me. — All right. Thank you. — Um so, I'm just going to after I seed into my squash branch here. So, one thing I'm going to do is I'm just going to make sure that I'm starting on my main branch, which I should be. So, if you guys recall from previous sessions, we can use git branch to see what branch we're on. Currently, right now, you can see I'm on main. If I do a getit log just to take a look at that history there, we can see that we have one initial commit. It's the first version of the rock paper scissors application. Okay. Uh so let's check out the other one. We can see that we have a feature branch right here. Right. So let's check that out. Uh so if I do get switch branch, make sure I spell that right. All right. So now that I'm on that branch, let's do a git log. Uh so you can see that now uh in the main we had that one commit. In the feature branch we have three commits. We have a first feature commit, a second feature commit and a third feature commit. These three commits are what we're going to be working with throughout the session um as we kind of explore squashing and cherrypicking. — Wait, can you all hear me? — Yeah. Um, Nick, we got a question from uh a user named Dude. Um, dude, would you like to ask the question? — Okay, my friend has this question. — Okay, so for Coding, what would be the like best software to learn how to use it? — Well, uh, for what kind of coding? — C. — Uh, so I actually don't code in C#. I code mostly in Java and JavaScript and whatnot. And I respect the question, but I also um I would like for questions to kind of be geared towards the event if we don't mind. Um so if you have any questions about Git or GitHub or whatnot, I'd be happy to answer those. — Okay. — Or if anybody in the chat uh answer question wants to conver good use as well. — Yeah, please keep the questions relevant to the topic at hand. Thank you so much. All right. So, starting with this, what I'm going to do, if you guys don't have this, uh, I have a live server. That's just something that allows me to fire up a web page. I want to show you guys real quick what the application looks like. Um, so, uh, let me actually go back to VS Code because right now I'm in my feature branch and I want to switch to the main branch. Go back over here. Um, so this is the game in its uh in its raw form currently right before we've added any features to it. It's just a basic rock paper scissors game. You can choose rock paper scissors. The computer will have a choice uh and then it'll tell you whether you won, whether it was a draw, um whether you lose, whether you lose. Right? So that's kind of the base application before we get started with any of this work. Um, so now that I'm on main branch right now, what I want to do is I want to take all of those commits that we saw in the feature branch and I want to squash them into the main branch. So at the end of this, instead of having three different commits there, we're going to have one singular commit. Uh, and if I go back over to my resource that I shared earlier, uh, we can see the code here that we need to do that. You don't necessarily need to add a change to the index html. You can if you would like. Uh, but we can move forward with these three different uh commands right here. Um, so what we're going to see if I go back over to my VS Code and I just look at that log history one more time within the main branch. We're going to see an additional commit made on top of this one. And then we're going to see the full game uh after all the features have been added to it. Uh, and we'll be able to experience what that's going to look like. Uh, so if I go back over to my resource, just going to copy this command here because it's already typed out just to make things easy and save time. Uh but before I press enter, let's just take a look at that. So we've got get merge uh hyphen squash feature

### Segment 4 (15:00 - 20:00) [15:00]

branch. So what this says is that hey get I want to merge the feature branch into the current branch that I'm on, which is main. However, I would like for those commits in that branch to be squashed or condensed. So if I press enter, you can see that squash commit was done uh and that there was modifications to the index html. there was some modifications and deletions to the script. js. Um, and so all of the commits that were in the feature branch are now on top of the main branch, right? Um, so what we still need to do though is now that we've squashed it, we need to add a commit. So I'm going to copy that. So if you guys recall from previous sessions when we reviewed commits, the command for that is get commit-m. That's your message flag. Uh, and then within quotes, you just kind of add something that um gives some meaning to that commit. — So now that I've added that and I do get log, now you can see that we have the initial commit, but then we have that other commit now that for that same message that we just had. And if I go back over to my live server, you can see that the game has now been modified. We've got some directions here on how to play the game. Uh we have some new parts of the interface here that actually tracks the stats for the current round. It overall performance of the game. If you want to play multiple rounds, you know, maybe first person to 10 wins kind of type deal. So, uh let's just play a quick round and see what else we have. Um we've got a next round button that shows up that I need to click in order to uh move forward. You see right now that I have a score, the computer has a score. We're tied at one. Uh, now it's a draw. I won the next round. Oh, we have some uh some CSS here. The last round it's red. Uh, let's go with rock. And I won. Right. So then you can see the background kind of highlights as green. Uh, and so one round has been played. You can see that I have a score of one. The computer has zero. Click play again. And then rinse and repeat. Um, but kind of back to the point at hand, right? we squashed all of the uh commits that were in the feature branch into the main branch. And if I actually switch back over to the feature branch, do a get log, you can see that we still have those three different commits there. The first feature commit, the second feature commit, the third feature commit. This is what I meant if you kind of if you if we go back to uh earlier in the session when I said the first method um keeps this commit history intact. That's super important. If for whatever reason you might make a mistake or you want to redo the rebate uh not the rebase, squash. Um, if we were to go into the feature branch and try to go through the interactive rebase, which is another form of squashing, all of these commits would actually be condensed into one, and we would lose this history here. So, if you want to keep this history intact within a feature branch, it's super important that you use the first method that I just showed you. And I also think it's the easiest to use. I actually never use the other method. Um, I would encourage you guys after the session, if you're interested to go try and use that method. I'm not going to do that here just for the interest of time and I want to make sure that I have enough time for everything in the session. Um, but after this uh after this session whenever you guys have time feel free to go to my GitHub and look at that workshop and try to give that a go. Uh, and you'll see what I mean there. These three different commits will actually get squashed into one. Then you have to push that to your main branch and you lose that history. Um, one way of going about it if I actually uh I don't know I don't want to go down that road. Um, one thing I'll call out though when you're doing that, maybe you're playing this recording while later when you're going through that example. Um, it's going to bring up an editor uh somewhere up top here above your terminal and it's going to show all of your commits. It's going to say pick this commit or pick this commit, pick this commit. Um, you need to change that pick to a squash. There's actually some helpful directions that get printed on the screen that kind of walks you through the process. Um, the reason that you might want to use the other method is to say maybe you want to squash uh the first uh three commits into one, but then like the next three or four commits, you want to squash those into a different commit. And so that's one way that you're able to interact with the commit history and say, I want to squash these to this one. commits to this one. And then at the end, you might have a couple of different commits. Um, but it's going to be cleaner than what you may have had originally, which you know, maybe you have 10 commits and you condense them down into two separate ones. Um, so again, at the end of the session or whenever you guys have time, feel free to go to that, try to work through that example. If you have any issues or any questions or you run into any, you know, problems or whatnot, um, feel free to just, uh, shoot me a message on the Code Academy, uh, community and I'd be happy to help as time permits.

### Segment 5 (20:00 - 25:00) [20:00]

— [snorts] — Okay, so now that we've kind of gone over squashing, let's go back over to our um presentation here and let's take a look at cherrypicking. Uh so cherrypicking, what is cherry-picking? Cherry-picking is a method that you can use to select or pick one specific commit at a time. And so thinking about that main branch and then thinking about that feature branch, right? That feature branch had three different commits in it. Um, you can take each one of those commits and cherrypick them into your main branch or whatever branch you're working with. Um, you can cherrypick them one at a time. This is very helpful when let's say you have you're working in a team-based environment, right? Um, using Git uh into your own using Git like in a solo project is usually much easier to work with because you're not dealing with other people's code coming in. commits that might cause conflicts. Um, but let's say you're actually working on a development team because if you want to be a software engineer, if you already are a software engineer, you are going to be working with other people in the same repository more often than not, if not 95 99% of the time. And so learning how to use git and github and working with other people in a shared project is very important. Um, cherrypicking is a really nice tool to use in some situations where you are working with other people because let's say you have um, let's say your standard uh, branch hierarchy is you have your main branch. That's where like your production code lies. That's where your users are logging in and doing whatever they need to with the system, whatever brings them value. Um, but underneath that main branch, let's say you have a stage branch. The stage branch is typically where code goes to get tested um in its final form uh or integrated testing. Stage is basically almost a an exact copy of main except with new features being added to it to make sure that um not only do the new features work, but we're not breaking any existing uh functionality either. That's really important. And then below that stage branch, you have a develop branch. Develop branch is where all the innovation and all the fun happens. That's where things can get uh things where can get broken. Um, if people are using the develop branch, typically you actually might see a team uh branch off of the develop branch. That way they're working within their own local um their own local copy or their own local branch on their own local machine where they can do whatever they need to um in order to add a feature or fix a bug, what may have you. Um, but let's say you push commits back to this develop branch and you need to move code from your develop branch to your stage branch, but you can't take all of the work that's in develop and move it to stage because maybe another one of your team members added some code that they haven't quite yet tested or been able to test. Um, and so it's important that code doesn't move up the branches into Maine, right? Because then we might run into um an issue, a production issue and our customers might get impacted. So that's a really important concept. There might be work in that develop branch that you don't want to go to stage. And so a way around that is taking the commits that you know have been tested or the code that you know has been tested and is ready to go and you can cherrypick it from that branch, move it up to stage and then move forward. So it's a way to just take certain commits in a in a branch, move it to another branch without taking everything that might be in that branch and moving it all at once. Hopefully that point makes sense. [snorts] Um so let's move over back to VS Code. I'm going to clear my screen. Going to take this down. Actually, I don't need to. Um, I'm going to cd up one directory and then I'm going to go into my chariot directory. Okay. And then clear the screen. Get branch. Let's just see what branch I'm in. Need to I'm in main. And if I do a get log, we're going to see that initial commit right there. Uh, I'm going to stop my live host and I'm going [snorts] to open up my one on the cherrypick example. Okay, let's close that other one. So, again, right here, we've got the basic game where we can just click buttons over and over again and just play a single round as many times as we want. Um, but if I go over to my feature branch, get switch and I do a get log. All right. So, we have that initial commit. We can see the commit hashes match here. And then we've got three different commits here. We've got the first feature commit, the second feature commit, and the third feature commit. And with all of these commits in the current branch, if I go back over, you can see that we have that full rendition of the game. So, if I just play a quick round, see what happens. You see that I won this round. Cool. Awesome. — [clears throat] — Um, and we got the CSS in the background. It highlights red. Let's see if I can get uh lose or have a draw.

### Segment 6 (25:00 - 30:00) [25:00]

Maybe if I just choose the same option over and over again. Nope. It doesn't happen this time. That's fine. All right. So, we have a draw. You can see it's yellow background. Now, if I were to lose, there would be a red background. Um, but those three different commits, they add the CSS, they add the current round stats, and they add the overall stats. Those are the three different features, if you will, that we're adding to the application. And the way I the reason I wanted to kind of put this application together for this is it really helps visualize um the learning and the functionality of what a cherry paper merging or any of the operations that we've covered do. Um, and sometimes, uh, being able to visualize what you're doing is really beneficial to the learning process. One thing that I do want to note here, and if I actually go over to my, um, slideshow here, caution. I have a caution here. Um, when you cherrypick a commit, you are going the commit hash will change. And if you guys recall from previous sessions, that can be a very important uh topic or point of contention, especially when you're working in a shared team environment and you're working with branches that other people share and you're not working with just your singular branch. If you cherrypick uh one commit to another branch, the commit hash is going to change. And let's say whatever um whatever branch you cherrypick to, somebody has that branch checked out. Um and they already have a commit history in their local copy of that branch that you're now modifying. Um when they go to push their changes back to that uh that branch, GitHub is going to throw some conflicts uh and some issues there that are going to take a little bit of manual effort and rework in order to fix them. And that can cause an issue especially when of course we want to be focused on coding. innovating. We don't want to be focused on fixing things and doing rework on stuff because that just kind of pulls us back from that innovative work. Uh and so having a standard around this and making sure that people know which branches you can cherrypick to, which ones you shouldn't cherrypick to, um can be very beneficial in a shared team environment. So that's just one key call out that I want to make. If you're going to use cherrypicking, be cautious of what you're cherrypicking to. Um, and just make sure that by changing that commit hash, you're not going to be uh damaging the commit history for another person that might be using that same branch. But you'll see what I mean here shortly if you just take a note of these three different commits here. These are going to change when we cherrypick. It's important to have these on the screen, though, because you actually need these commit hashes in order to cherrypick them from this branch to another. So, I'm going to leave those up before clearing my screen. I'm going to switch back to main. Uh I'm going to do one more getit log so that you can just see within main we've got that one commit. The command for cherry picking is get cherry-pick. Oops, forgot my Y. And then let's take that first feature commit. So I'm going to copy this commit hash. I'm going to paste it there. Uh so you can see that we took that commit. If I do a get log, we're going to see two commits here. Now, that we have that initial commit and then the first feature commit. But notice how this was the commit hash prior, right? The C34 BC. The commit hash is now 49 DC9 yada yada. Um, so that just visualizes that the commit hash does change when you perform this process. If I go back over to my game though, uh you can see that we've now picked that first uh that first box. So, if we try to play around, you see that we uh we were able to do this, but oh, the game kind of broke a little bit, right? Uh there's actually some changes in that next feature that fixed this. But what this does, we're able to still play around, but we're not able to continue playing the game. And we don't have any CSS being applied here either. We have some, but we don't have the colors that we had prior. [snorts] So, let's go back over and let's take that second commit now. So you can see the second commit adds the overall round stats capability. Uh so if I do a get cherrypick, I'll just go up a few and then I'll delete this commit hash here. Paste a new one. Uh second feature commit. Okay. So if I do a get log, you can now see that we have the initial commit, we have that first feature commit, and now we have the second feature commit. And again, just to note it out because it's a very important topic or point rather about this topic, the commit hash has changed. If I go back over to my live server though, you can now see that, hey, we've got the current round stats. We have the overall stats. What happens if we play a game? Let's just try just a few random clicks. Uh, okay, we can play again. So, the game works except we're not getting that background confirmation that we used to have. Uh, and as far as the user experience is concerned, that's really nice to have, right? So, let's go back

### Segment 7 (30:00 - 35:00) [30:00]

and real quick, let's take that third commit from above. this one. Copy that. Go back down to I'm actually gonna out because I feel like that was probably Now we have that third feature commit. So if I just clear the screen here, remember we have F6 CF go get log. You can see that we have that third feature commit except the hash change has now changed. It's C94E and then some change. All right. So, what we're going to do here is I'm going to go back over um play one more game just to make sure that third feature commit went through and it has. Oh, great. You guys get to see that uh when we lose the background turns red. So, hopefully that helps visualize the process of cherrypicking. You guys were able to see that we were able to take those three different commits and we were able to cherrypick them one at a time individually into the main branch. Uh and again just to kind of um reiterate why that's why that process might be needed or why it's really important or some of the power that comes along with it. If you're working in a shared environment and let's say you have that uh that one branch that you're doing some work in and there's other work in that branch that you don't necessarily want to pull or push rather you don't want to push work in that branch to another one. Um you might need to cherrypick a few of those individual commits that you know have been tried and true and tested um and before moving forward. And this is one way of doing so. Um, so that kind of covers up our topics for squashing and cherrypicking. Uh, how are we doing on time? Good. We're about halfway through. Perfect. That's what — we're doing. We're doing well. We have plenty of time. — Nice. All right. Um, I'll stop and pause there real quick. Do we have any specific questions around squashing or cherry-picking that anybody might want to ask? I'm trying to keep an eye on the chat as well. I don't see anything. I definitely agree with you, Owen. It can be very complicated. — Doesn't look like we have anything. — All right, let's continue. Let's talk about resets. Um, resets are a pretty useful tool. I actually use them quite a bit especially when I start getting a little crazy uh within a particular branch and I start having a bunch of commits and sometimes I might commit a few things um and at the end of the process you know I don't want to take all those commits and push them forward uh I might want to uh if you will condense them right we just kind of covered squashing this is a way to I don't want to say cheat the system um but this is another method that you can use to clean up your brain branch before trying to do any of the operations that we've covered like merging for example. Um you might have a bunch of different commits uh within a particular branch that you want to clean up. Maybe you want to reset them. You want to get rid of the commits in there but you don't want to get rid of the code that came along with them. There's really three different uh flavors to resetting. Um and I have them listed here on the right. I'm actually going to go into my slideshow so it's a little bit larger. Um, so the three different flavors are get reset soft, mixed, and hard. Um, when you do a git reset soft, this keeps your staging and working area intact. And so all of the commits that you had um, previously committed, all of the code associated with those commits remains in your staging area. If you recall from one of the previous sessions, it may have been the first or second one that we had done earlier uh in the year. Um your staging area is basically or your working area rather. Let's start with the working area. Your working area is where you're making all those changes um where you're saving your files and whatnot, but you haven't made those changes ready to commit yet. In order to create a commit, you have to take the changes that are in your working area and you have to stage them. So like think of staging them as like a verb. um you're pushing them to a staging area and you use commands like git add um with a file name or a dot to add all of your changes, but you use git add to take changes from your working area and move them to your staging area. Once they're in their staging area, you're able to create a commit from your staging area. Everything in your staging area will be included in your commit that you create. And so when you get use a get reset soft, you're keeping all of the changes associated with the commits that you're resetting in your staging area. And from there, you don't need to read any of the code. You can simply just create a new commit and then move on with the process. And so that's kind of what I mean by maybe you had 10 commits, but you want to go back to that first commit that you had in the branch. You can erase all nine of those commits without losing the code that was associated to them using a get reset soft. Um, a mixed one. This one kind of

### Segment 8 (35:00 - 40:00) [35:00]

remains similar except it unstages all the work and so you don't lose any of the code associated with the commits that you had, but they're not going to be in the staging area. Why might you want to use this one instead? You might because let's say you have those 10 commits again, right? And let's say you go back to the first one. So you're essentially kind of reversing nine of them um or getting rid of nine of them through the commit history. But let's say in all those changes you had some changes to code files, maybe test files, right? So you always have like a code file, then you usually have a test file that tests the code within that um that primary file, if you will. Um, and let's say you don't want to include all those changes in the same commit. Let's say you want to take the code changes that you made, include those with one commit, and then let's say you want to take the test files and include those in a second commit saying that you just added testing for the changes that you just made. Um, this is a helpful tool using git reset mix because again, you won't lose any of the code, but it will be unstaged and that allows you to read individual files to your staging area to create a new commit and then coming back add more files, stage them, create a new commit. And so that's where you might want to use git reset mixed um because you're not going to lose the code, but again it just allows you to recreate that commit history as you wish. [snorts] Um you could still do a get reset soft and then just unstage everything. Um but this kind of helps do that process for you. Uh it is worth noting here that when you use any one of these commands, you might see the commit hash right here. This is the hash of the commit that you want to reset to. You're not going to the commit prior to this one. That one's going to remain intact. This one that you provide here. But everything that comes after that commit is going to be a part of the reset operation here. Um, and then the last one is get reset hard. That one actually it just it's a full wipe. So let's say you're working on a branch, you add some stuff. You're not happy with any of it. Period. You don't think any of it is salvageable. Um there's you just really just want you want a brand new sheet of paper. You're just going to crumple this one up. Although I don't recommend that. Try to use digital paper. Uh but you know, let's say you're just writing a bunch of notes. It's no longer good. You're going to crumple it up, throw it away, and get a brand new sheet of paper. That's basically what's going on here. All of the changes that you've made in that commit history are going to be lost completely. Um and so use this one with a lot of caution, but if you're just looking for a clean slate, this could be the way to go. Um, and then before we actually move on to the example of this, um, don't do this in shared branches. Don't do it in shared branches, please. Um, if you're working in a sh in a branch that other people share and you start doing resets, that commit history is lost. No matter what no matter what version of reset you use here, the commit history that you reset is lost. You can create the code. You might not lose the code, but every time you create a new commit, the hash is going to change. And so again, it kind of goes back to that concept around if you're using shared branches, it's really important to keep the commit history intact. The hash is essentially um the one key indicator that is it represents the commit, the changes, the metadata of the change, when the change was made. There's a lot of information that is really important to retain. Um, and when you're working in shared branches, it's very important that you do not use reset because you can really you can do a lot of damage that way. Um, so keep get reset in mind. It's a great tool, but use it um use it cautiously and use it within the branches that you're working um on your own um in order to kind of keep your own history intact before you take those commits and push them to a shared branch that your team will be able to see. It's a very important call out. Um, I'm actually going to stay in the same branch that I'm in here for the practical example. Uh, because it really applies to anything. If I go in here and I use git log, we can see again after doing the cherry-picking, we have these uh four different commits here. But let's say for some reason I actually didn't want to I didn't want to cherrypick that one yet. Uh maybe there was something else I wanted to do or added. This is a obviously a very hypothetical, but let's say I wanted to get rid of this one for some example. Or let's say I wanted to get rid of all of them. Maybe I didn't mean to cherry pick these yet and I want to go back to my base foundation. So, if I take this commit right here, I'm just going to copy that and I do get uh resets and let's do a soft reset first so you guys can see what that looks like. Um, actually, no, I don't want to go all the way to the back because I want to be able to demo a few different examples here. So, let's just take one commit for now. So let's do get reset soft and then include that commit hash. If I do a get log, you can see now that we have the first feature commit and we have the second

### Segment 9 (40:00 - 45:00) [40:00]

feature commit. Um the third one is now gone. However, if I do a get status, you can see that the script. js file has been modified and it's green, meaning that it's in our staging area. So that third feature, if you guys remember, that's what added um uh that's what added some of that styling. The code responsible for those colors is in the script. js. Um so I didn't lose the code that made that change. However, um the commit is now gone, but I haven't lost the code and it is still in my staging area. So for whatever reason, if I wanted to add that back, I could do get commit-m. And before I actually do that, if I actually just go back to the app that we have here going, I play again. Let's make sure that the feature was actually erased. Well, maybe it wasn't. Oh, that's right. Um, it's the commit history doesn't matter for this application. What matters is that the code actually exists. And because the code is still on the file, the game is going to work the way that the code is there. So, apologies for doing that. That's actually not going to visualize it very well. [snorts] But if I wanted to say, let's say add um change to script. js, I would need to actually physically remove the code. do a hard reset in order for the example that I just showed you guys to work. And we'll see that in action, too. Um, so I added it. If I do a get log, you can see that new change is there. However, the commit is different. Um, and that's important to call out, right? So, let's do a mixed one, right? Let's do another one. I'm going to go back a couple of different commits here, though. Let's go back to the second one. first one. So, if I do clear and I do get resets next. So, unstage changes after reset. Okay. So, if I do get log, you can see that we have that initial commit. We still have that first feature commit. And if I do a get status, you can see that these changes, the code is still there, but they've been unstaged. As you kind of guys saw up here, unstage changes after reset. That's what a mix does. That's how that performs. Um, and again, that's that's uh that's useful if, let's say, I wanted to go ahead and add the index html first and then add the script. js after. So, I would get two different commits after this, but again, the commit hash would change. Um, but it allows me to rewrite the history a little bit, if you will. Uh, I'm not going to do that. So, I'm just going to add them all together addit-m just for the sake of time. I'm just going to say add back files. That's fine. Log make sure I have that history. I have the initial commit, the first feature commit, and then I've added the files back. Um, so now we've actually got three commits, but the application itself has not changed. It will continue to work as expected. We have not lost any of the code. So even though our commit history has changed, the functionality of the product, if you will, has not. Um, and now let's go explore with a hard reset. So if I do a getit log here just one more time, and let's say I actually just, you know what, none of these features, you know, we're getting some customer feedback. you know, the features aren't that great. You know, it would actually be based off of customer feedback because that would assume that we've already made it to production. Um, but let's say I showed it to a team member and they said, "Hey, I checked out your branch. I looked at some of the feature stuff. I think you could do X, Y, and Z a little bit better or something. " All right, let's start with a clean sheet of paper. Um, you know, everything that I made was junk. Uh, that wouldn't actually happen, right? But, you know, we're just for hypothetical. Um, I'm going to take this commit history and I'm just going to do a hard reset. I want to start all over. So if I do get reset- hard, right? So head is now at 9D. You guys notify or notice that that's the hash prefix for this one. And if I do a get log, you can see that we only have that one commit here now as well. However, because we did a hard reset, all of the code associated with the features and changes that we've made is now gone. So, if I go back over, you can see here that we actually have just that first rendition of the application. None of the features have been added because that code has been completely removed. Um, and that's just really important to be uh mindful of whenever you use a hard reset. You will lose all of the work um that you reset. If that's your intention, go ahead. Um, but just be careful when using that one. All right. Uh, so that's a good cover of Git Reset. Um, about 15 minutes. Perfect. Doing good on time. Stashes are going to go pretty quick. I'm not going to spend too much time on these ones. Um, but stashes are um they're pretty

### Segment 10 (45:00 - 50:00) [45:00]

useful if let's say you have work within one branch that you either need to save for whatever reason. Sometimes this might happen. So like if you think about if you put yourself in the position of a software engineer um typically you are given tickets to work on or deliverables or something within Jira like a Jira task a Jira item. There's a lot of different uh um terms that people might associate them within the industry but essentially all it is our user story. You guys may have heard those before. It's basically just think of it like a virtual card on a board that has um requirements on it that help the developer and the team understand what changes need to be made to the system. It might be a new button needs to get added to the screen uh or a new uh API route needs to get added. We need to be able to give people some opportunities to submit a post call to this API to create some assets or whatnot within a system. Um let's say you're working on one ticket. you have some work there that's uh you've been making some commits along the way. Maybe you have some work that hasn't yet been quite committed yet that you're not ready to commit. But let's say your manager comes to you and says, "Uh, hey Nick, uh I know you're working on this right now, but uh we need to switch up our priorities a little bit. Maybe there's a bug that came through that needs an urgent fix. I need you to focus on this now instead. " Um, okay, not a problem. What you might need to do though in these situations is you might need to stash your work quote like save your work if you will within that branch um or within a stash rather before moving to another branch. If you guys are if you guys have worked with Git in the past uh or as you move forward with working with Git, you might find that if you have work in a branch that you're current work on currently working on that you have yet to save or yet to commit, you might get an error message uh from when you try to move out of that branch to another one saying, "Hey, you have some uncommitted work here. You either need to create a stash before moving forward or you need to create a commit to save that work. " In those circumstances, you can create a stash. And so, let's say, you know, I'm in here and I go to my index. html and I say I want to change uh this ultimate instead of the classic game. I want the ultimate game. I might save that. Um, if I go back [clears throat] down here, let's clear the screen. If I do a get status, okay, we see that I have a modification to the index html, but I have not staged it. I have not yet to create a commit. Um, let's see if I can trigger this. switch back to main, what do we get? Um, oh, we we're actually already on main. So, let's just say I get switch feature branch. Or maybe not the feature branch, right? Maybe we had a bug and we need to fix it. So, we need to create a new branch. So, I'm going branch uh called bug fix. This may work. It does. Okay, that's not a problem. Um I was trying to see if I can get the error message to trigger. Not an issue. Um going back to here though. So, just to review the um comments real quick. So, there's a couple of different things here. In order to before we actually get to the example of it, in order to create a stash, you're going to use git stash. that takes everything you have currently um saved and it'll create a stash. In order to view all the stashes that you've created, you can use this command called get stash list. Um but let's say whenever you're ready to actually uh take the work that you have stashed and you're ready to apply it back to your current branch that you're working on, you can take either get stash apply. What this will do is it'll take your latest stash that you've committed uh that you've created and it will commit it back to your current branch. Maybe commit's not the best word there, but it'll take all the changes that are in that stash and apply them rather it'll apply it to the branch that you're working on. Um, but it'll retain that stash in the list of stashes that you've created. If you use git stash pop, uh, the same thing will happen. However, the stash that you created, uh, that you're now applying, that gets removed from the list. And so, because I don't have any git stashes right now in this repository, get stash should actually generate an empty list. Uh, no, I actually just created the stash. Sorry. Um, I wanted to do get stash list. But if I do get stash list now, you can see that we have some work in progress on main. And there's uh that's the first commit that was associated with it. Um, however, the changes that I had in Maine are no longer here. You can see that we have the classic game. That's not the change that I made. That was what it looked like prior, but because I've stashed my work, the work has been saved in that stash. But now I'm kind of working with a clean commit history. I can move on to another branch, do some work there. Um, I will say the stashes are also branch agnostic. So you can take changes that you have in one branch. You can stash them, move to another branch, and you can actually apply that stash to that

### Segment 11 (50:00 - 55:00) [50:00]

branch. That can be helpful if you need to move code between uh different branches and you're not um looking to create any commit history for that. Um, so that's a little um little tip that you can use, put in your back pocket as well. But if I do get stash uh apply, you can see now that we have the ultimate game again. But if I do a get stash list, that stash is still there. Um let me move over to get switch. Move over to the feature branch that we had. Oh, there we go. I actually just generated it. Um, so here's the error that you would normally see. Your local changes to the following files would be overwritten by checkout index. Please commit your changes or stash them before you switch branches. So what's happening here is because I have a change here in main that is not committed um it doesn't exist in the feature branch either. What git is trying to tell me is that by switching from this branch to the other branch to the feature branch, this change that I had here will be lost and it's preventing me from doing so. So what I actually need to do is I need to do another get stash just to save that worked now I can switch over to my feature branch. But if I do a get stash list you can see that we had that original stash that I created and they're actually indexed. Um and you can see that now that I have two stashes here. Uh back to that node that I said that you can actually take work from one stash and apply it to another branch. If I wanted to do that here, right now we see we have the classic game and I think this should work if I do get stash pop does. So I was able to take that change and apply it to my feature branch. But because I use pop, um the stash no longer exists in the list there. So if I actually do get stash list one more time, you can see that we now only have one stash here instead of two. Um, and so that just kind of helps visualize that when you use git stash pop, the stash is still applied, but it's also removed from the list of stashes available as well. But that is one way that you're able to save your work and move about different branches. [snorts] All right. And so, um, I'll finish the conversation on stashes there. I think it's a good overview, and I do want to save, uh, just some, um, some time for our final slides here. Uh, so best practices with git. Uh so let's kind of just let's let's summarize and round off a lot of the things that we've learned over the previous sessions. Um so I've got 10 different tips here. Um I'll just start with the top one and just uh we'll go down the list and just provide some context as we go. So number one, use branches for features, fixes, and experiments. Um so what do I mean by that? If you guys recall the uh situation that I was talking about earlier when you're working as a software developer and you're working with a within a shared team environment, you have that develop that stage in that main branch hierarchy. It's really important that you don't make changes directly within those branches because those are the branches that the team shares. Um the only time work should actually go to those branches um is when you are ready to move forward with the innovative work that you've done or the bug fix and you're ready to test those fixes within a real environment. Usually those uh those different those three different environments they usually have some kind of CI/CD pipeline associated with them where every time you merge or you open up a PR a pull request if you guys recall we talked about those in one of the sessions. If you open up a pull request and you merge that to a branch, there's some other automation in the background that could get kicked off. Whether it is to compile all of that code and create a new machine image that gets pushed to a container or um some server or instance within a cloud environment, uh if you will, that um opens up the ability to test within a production-like environment. Um and so it's important to leave those branches intact. The only time that you want to push changes to those is when you're ready to test work that you've created within a branch that you've created for your own use, your own individual use in order to break things, work on things, make changes. Um, and so it's really important just anytime you're adding changes to a system, branch off of that uh that lowest branch, if you will, that develop branch. There's different hierarchies out there. That's just a common example that I use that I've seen. Um, but just keep all the work that you're doing within a separate branch. Don't push that work from that branch to a shared branch until you're ready to test it and move forward with it. Um, don't innovate and make changes in a branch that everybody else is working on and sharing because if you break something, you can cause uh, you know, proximal damage to your team members. That branch might not work anymore. Um, they might have to wait in order for you to fix those issues before they can move forward with their work and then we start kind of just running into each other and it's not a productive way to work. [snorts] Uh, number two, write clear, meaningful commit messages. Um, don't make a change to a file and then just say uh updated

### Segment 12 (55:00 - 60:00) [55:00]

index html. That works as a commit message but it doesn't provide any meaning. semantics for why that change was made. Try to be very intentive uh with your messaging um or very direct rather with your messaging. When you create a commit, what change did you make? What did you add? What did you modify? What did you remove? Um you don't need to go so far into detail. We're not looking for sentences here. Um it's important to kind of keep commit messages somewhat small, right? Um we don't want something that drags on and on, but try to do your best to just think of um some meaningful sentiment um around why you made the change and use that as your commit message. When you push those changes from your branch to the shared branch, develop the stage when you open up that PR, that's the moment where you can provide a bunch of additional context as for what that change does. Um but in your commit messages directly try to keep them small and concise but keep them meaningful um and clear. That way people can look at the commit history and understand oh this is where that was introduced or changed feature was uh put in. Um you might kind of going back to those Jira tickets if I was that I was telling you about it might have an ID for that ticket. It might be ID-123. Um, so when you're in your workflow system, ID-123 points to a ticket that asks for these specific requirements. It's really good to use those IDs within your commit messages because it kind of helps tie everything back and forth, which is super important if you need to research why something may have occurred later on. Um, number three, commit small logical changes. Don't create a commit that has changes to a ton of different files. Um because if you ever try to go back and you try to look at that commit just interrogate it a little bit um there could be a lot of changes associated with that commit and it can get very daunting, very confusing very quickly. And so it's important to every time you create a commit make sure that you are only making some changes to a file or a couple of files at a time. Um don't take one commit that adds three or four different tickets all at once. Um because then again things get really large. they get complicated and it's important to be uh important to be mindful of that. Number four, uh pull or fetch frequently to stay up to date. So you can imagine if you take uh one branch that everybody shares on GitHub and you pull that one locally and you branch off of it, there could be changes made to that branch that you're going to merge back to um over the coming week or two. Maybe your team members are making changes to it. And if they're making changes to the same files that you're touching, it's good to know and be aware of those. And so when you're working in a local environment within a local branch, it's important to fetch and pull changes from the branch, the remote branch that you're working with often because then you're able to stay aware of the changes that are being made to that repository while you work on those same files in the meantime. Um number five, review and resolve conflicts carefully. Um, if you do end up in a merge conflict, meaning that you've made changes to a file as someone else has made changes to and um, there's just kind of like some conflicts there, maybe you guys touched the same lines of code, maybe there's new code that's been introduced that uh, your branch isn't yet aware of and you run into a conflict. It's important to be very mindful and careful when stepping through that process because you don't want to lose your work, but overwrite the work of another either. Um, and so just if you run into a merge conflict, just take a look at the code that is there. being introduced and make sure that you are either removing or keeping the code that needs to be there. Uh, and just be careful. Uh, six, use pull requests or merge requests for code review. Um, many branches have protections for these. They don't just allow you to merge code to a branch, but if you ever find yourself working in a repository that allows you to just push code to a branch without it being reviewed by other people in that repository, um, it's important to open up a pull request and state what the changes are being made. Ask your team for a review. They're able to go to that PR. They're able to take a look, okay, you know, what are they doing here? Is there any bugs? Is there any syntax errors? It kind of gives them a chance to review the code and make and give you feedback on it before you move forward with it. And that can be a super helpful process. Not only does it help you learn, but it also helps avoid um bugs from being introduced into the code as well. [snorts] Uh seven, keep the main branch clean and deployable. Um the only time code should ever be pushed to the main branch is if you are ready to release it to production. Do not ever push code to your main branch if it has not been thoroughly tested and you're not within some kind of release window when you know your customers expect some kind of update to be made. Sometimes if you push code there, you might need to recompile and repush an image to a machine. There might be some downtime, some impact there. Um, and you also just anything that goes to Maine should be tested thoroughly, ready to go. Don't put anything in Maine that has not yet been tested or you're just kind of questioning. Maine is not the branch for that. Um, eight, use git ignore and

### Segment 13 (60:00 - 63:00) [1:00:00]

avoid committing generated or sensitive files. Um, a common file that a lot of people work with is an environment file that has a lot of secrets in there. It could be passwords. It could be API keys. That data does not belong in GitHub under any circumstance. Um, that's how uh security risks happen. That's how things get hacked. That's how uh companies can lose reputation. Um, so it's very important that if you have any files that are just really important to your own local use or maybe some configuration files, those don't belong in GitHub. And the way that you can prevent them from ever getting to GitHub is using this git ignore file. That's essentially a file that um just with some simple markdown or some text, you can specify folder directories. You can specify specific files that you do not want included in any of your commits. Uh and provided that's there, Git will respect that. Uh number nine, regularly clean up stale branches and stashes as you create stashes or as you create branches. As you can imagine, if you're in a role and you're working on for months or years at a time, if you don't clean up um that inventory, every time you run a get branch command, you could have a long list of branches and you might just have to pageionate through them over and over again until you find the one that you're looking for. You could be looking at branches that were created two, three years ago. It does happen. Um, and so just to kind of, you know, just to kind of help your mental state as you're working uh within large projects, it's good to clean up branches and stashes that you no longer need. Um, especially if that branch has been pushed to those shared uh shared repositories or if it's been pushed to production, that code is in those shared branches now. You can always pull that code or pull those branches and continue working on it, but you don't need the old branches that you use in the innovative process. Um, so just, you know, for your mental health, just uh keep a clean working environment, if you will, a clean virtual one, so to say. Um, and then just like the last one, rebase thoughtfully and avoid rebasing shared branches. This does also apply to cherrypicking and squashing, right? You know, and I should have said that really any time that you're doing an operation that we've covered throughout this series. if it modifies the commit history in any way, just be very thoughtful about what you're doing, why you're doing it. Um, and just make sure that that's the uh that's the step forward that you want to take before actually taking the step. A lot of the things that you do can be fixed, but again, it requires a little more effort, requires some rework. Um, that takes you away from the stuff that you really want to be doing. And so, it's of course, you know, goes without saying, we want to do the best that we can on the first try. Um, and so just anytime you're modifying the commit history, just be thoughtful and be careful. Um, and so yeah, those are some of the tips that I would suggest for being successful with Git. And I appreciate everybody joining these uh these sessions. I hope you guys learned a lot. Um, feel free to review them on the YouTube channel. If you guys have any questions, you guys are more than welcome to reach out to me on the Code Academy community. — Uh, Nick, thank you so much for taking the time uh to lead us through part four. you've invested so much time and energy to do this. Um Nick, can you remind everybody what would be the best way for uh folks who are interested to connect with you? — Uh yeah, code academy community is great. Um you can also find my GitHub. I don't think GitHub has messages there, but um I think you can leave comments on some of my repositories, maybe that workshop that you guys are working on there. Um those are probably the two best ways to reach out to me um to start and if it needs to go, you know, offline from there or something, we can have that conversation. But I'm active there. — Got it. And um I get a lot of questions about this, but we will upload uh this event to our official YouTube channel so you can rewatch it as many times as you want. Again, Nick, thank you so much for taking the time to do this and uh yeah, we appreciate everyone who attended today. Um hope everyone has a good rest of the day. Talk to you later. — Enjoy. — Bye.