
No Comments Yet
Be the first to share your thoughts and start the conversation.
Be the first to share your thoughts and start the conversation.
How did you manage to remove the blur property and reach here?
Upgrading gives you access to quizzes so you can test your knowledge, track progress, and improve your skills.
By logging in, you'll unlock full access to this and other free tutorials on JSM Pro.
Why? Logging in lets us personalize your learning experience, track your progress, and keep you in the loop with new workshops, coding tips, and platform updates.
You'll also be the first to know about upcoming launches, events, and exclusive discounts.
No spam—just helpful content to level up your skills.
If that sounds fair, go ahead and log in to continue →
Enter your name and email to get instant access
In this lesson, you'll discover essential Git commands that serve as lifesavers when things go wrong during development. Understanding how to effectively use these commands not only helps in managing your code history but also in recovering from mistakes and keeping your workflow seamless.
git checkout
: This command allows you to view history but does not delete anything from your commits.git reset
: This command helps to reset the commit history, allowing you to remove specific commits while deciding what to do with the associated changes.git revert
: Ideal for situations where you want to undo changes while keeping the commit history intact.git stash
: Temporarily saves uncommitted changes, allowing you to switch to another task without losing your work.00:00:00 So far, you've learned the basics and some intermediate Git skills that you'll use in your day-to-day work.
00:00:06 But let's be honest, sometimes things can go wrong and you mistakenly break production.
00:00:13 That's when Git becomes your best friend, only if you know how to use it to its full potential, of course.
00:00:19 And this is where what I call Git Savior commands come in handy.
00:00:24 These commands let you manage changes, undo mistakes, and tweak your commit history.
00:00:30 Think of them as your backup plan when things get messy.
00:00:33 You already tried and tested one such command, which allows you to check out to a past commit.
00:00:39 Do you know which one is it?
00:00:41 Yeah, it's git checkout and then a commit hash.
00:00:45 But as I've told you, that command doesn't discard or delete anything.
00:00:50 It's just a way to view the history of specific commits.
00:00:53 There might be the case where you want to check out to a particular commit and then delete everything that comes after it.
00:01:00 That's the job for git reset.
00:01:03 Imagine you want to remove some commits and revert to a previous commit with the possibility of choosing whether you want to keep or discard the changes
00:01:12 in the working directory.
00:01:15 That's a bit hard to understand, right?
00:01:17 So let me say that again.
00:01:19 Suppose you made 10 commits and want to check out the third commit in history.
00:01:23 You want to delete all commits after the third, like fourth, fifth, sixth, tenth, and so on.
00:01:30 Maybe you even wrote some bad code in those commits.
00:01:33 And to keep things simple, you want to remove these bad commits, but still want to keep the changes that you implemented.
00:01:40 I hope that makes sense.
00:01:41 So, delete these commits, but keep all the changes you made from the fourth to the tenth commit.
00:01:48 This is where we use git reset.
00:01:50 It allows us to remove the traces of commits in history, but gives us the changes we made in those to be discarded commits so we can decide what to do.
00:02:00 We can keep those changes, form a better commit out of them, or delete them entirely.
00:02:05 It's up to you.
00:02:06 Let me quickly add a console log to this hello.js file.
00:02:10 On top of the first one, I'll add another one that says something like console log hello GitHub.
00:02:17 There we go.
00:02:18 Now we have two.
00:02:19 Then make a commit by running git add dot git commit dash M add GitHub console log.
00:02:29 to hello.js.
00:02:31 Next, to properly illustrate how we'll use git reset, I'll add one more console log.
00:02:37 This console log will say something like hello from, and then put the name of your branch.
00:02:44 Dev Adrian in my case, since we haven't switched from before, we're still in this branch.
00:02:49 And I also want to commit this.
00:02:51 Imagine this is a bigger feature that you implemented.
00:02:54 So I'll run git add dot git commit dash M and we'll say something like add hello console dot log to hello dot JS.
00:03:07 And commit it.
00:03:09 Now you commit it, you stand up from your desk, go for a walk or go about your day.
00:03:13 Then you come back and then you start focusing on some additional functionalities within the same branch.
00:03:19 Let's say that additional functionality is another console log, but this time this console log will actually break things.
00:03:26 So we can say this is bad code.
00:03:30 Okay.
00:03:30 And now we can do another commit, of course, without knowing that this commit breaks the code.
00:03:35 So we can say git add dot git commit-m, and we can say add another console log.
00:03:44 Now, if you run git log.
00:03:47 You'll see many commits.
00:03:48 Keep in mind that git log here includes all commits that have happened before as well.
00:03:53 Everything from the latest console logs, to previous ones, to resolving our merge conflicts, even Johnny's changes right here.
00:04:00 There's a lot of stuff that's here.
00:04:01 Everything from when we first started working on this project.
00:04:05 Now, before I tell you how to remove this bad code using git reset, you must understand that there are a couple of different ways to run the git reset command.
00:04:14 Soft reset simply moves the specified commit in history, but keeps changes staged in a working directory.
00:04:21 That means that whatever changes were made after that commit will be in stage mode.
00:04:26 And stage changes are those that we add to git tracking system by running the git add dot command.
00:04:34 So before running that, they're untracked.
00:04:36 And then once you run git add, then you can consider those changes tracked or staged.
00:04:42 So if you want to do that, you can run git reset dash dash soft, and then add a commit hash.
00:04:49 The second way to use git reset is called a mixed reset.
00:04:53 And for that one, you don't have to pass any flag as it's the default one.
00:04:59 MixedReset moves to the specified commit in history, unstages the changes, and keeps them in the working directory.
00:05:06 Thus, all changes made after the specified commit will be in your working directory, but they won't be staged.
00:05:13 You have to manually stage them if you want to by using git add dot.
00:05:17 And finally, there's a hard reset.
00:05:19 It moves to the specified commit in history and discards all changes in the working directory and staging area.
00:05:27 All those changes made after the selected commit will be discarded entirely and you won't see any trace.
00:05:34 You can run that command by running git reset, dash dash hard, and then add a commit hash.
00:05:41 Now let's actually go with a mixed reset by copying one of the commit hashes from here.
00:05:46 But which one do we want to copy?
00:05:48 We can scroll to the top to see the newest ones.
00:05:51 And we have this add another console log, which we know breaks our code.
00:05:55 So we want to avoid this.
00:05:57 So instead we can go all the way to add GitHub console log to HelloJS.
00:06:02 So let me copy this commit hash and press Q to exit.
00:06:08 Git log.
00:06:10 Next, we can run git reset and then paste this commit hash and press enter.
00:06:17 Unstaged changes after reset, hello.js.
00:06:20 So take a quick look at the file explorer.
00:06:23 You'll see that the hello.js file is blue, which means that we have some changes in that file.
00:06:29 And if you pay attention to this green line here, this means that these are the two additional changes which are currently unstaged.
00:06:36 So let me put that in other words.
00:06:38 The changes for the two commits that we have added are right now here and are unstaged.
00:06:44 And we can verify that by running git log.
00:06:47 And you can see that there are no additional commits after the add GitHub console log.
00:06:52 There's no add hello dev Adrian, and there's no add bad code.
00:06:56 We can exit that for a second and we can also run git status.
00:07:00 And you'll see that hello.js has been modified and specifically it has been modified with the file changes that came from the two commits that we have reset.
00:07:11 So now it's completely up to you whether you want to keep those changes, modify them, and then again, stage and commit them.
00:07:18 In this case, I will simply remove them from the code like they never happened.
00:07:24 And we can go to git log and see that there's no more add buggy code or add console log and see that those two additional commits happening after the GitHub
00:07:34 console log are completely gone.
00:07:35 All of your mistakes completely deleted.
00:07:38 I hope this makes sense.
00:07:39 So you can take a moment and try the other two variations of the git reset on your own and see how they differ.
00:07:46 Once you do that, we can move to the next advanced git command.
00:07:50 Git revert.
00:07:51 Let's say you've deployed a feature that broke production and you want to undo its effects without losing the commit history.
00:07:58 You want the logs to be there, but you want to revert to an old commit.
00:08:03 This is the exact situation where you want to use git revert.
00:08:07 It's ideal when you have nothing to hide and you want to maintain a clear record of changes that you did.
00:08:13 It's almost the opposite of reset.
00:08:15 Let me show you how it works.
00:08:17 I'll add another console log that says something like trying out revert.
00:08:23 Okay.
00:08:24 And I will commit it by running git commit-m add revert console log.
00:08:31 Oops, I forgot to do a git add before that.
00:08:33 My mistake.
00:08:35 Let me do git add dot, and I'll use the up arrow two times to get back to the previous command and commit it.
00:08:42 Now, let's say you want to revert to the previous version of your code base that didn't contain this console log, but you want to keep it in the logs.
00:08:51 You can run git log.
00:08:53 You can find the commit hash of the previous commit without containing the revert console log.
00:08:58 Copy it.
00:09:00 and then run git revert, paste the commit hash, and then we get something that looks like this, which is somewhat familiar to us.
00:09:09 It's like a mini merge conflict.
00:09:12 It's trying to figure out what we want to keep and what we want to remove.
00:09:16 In this case, I'll manually remove lines of code that we don't need.
00:09:20 So we don't need these ones and we don't need the trying out revert because we want to abort or revert that one.
00:09:28 You can save it.
00:09:30 And once you save it, we want to add those changes to staging by saying git add dot.
00:09:36 And then you can run git revert continue, and this command will successfully finalize the revert.
00:09:43 As you can see, we're getting there.
00:09:44 This message is saying that we will revert this commit, but we just need to provide it a commit message.
00:09:50 Or we can exit this window by pressing colon, QA, and then exclamation mark, and then press enter.
00:09:57 There we go.
00:09:58 So one file has changed, there's one insertion and two deletions, and we are back to where we were.
00:10:03 Similar to git reset, right?
00:10:05 But now, if you check out git log, You can see that a new commit revert add GitHub console log to hello has been added to our Git history.
00:10:17 As I said, similar to reset, but depends whether you want to hide your tracks or you want to show everybody that you messed up and you fixed it later on.
00:10:26 Both have their own use cases.
00:10:27 Now, let me show you git stash, another super useful git command.
00:10:32 Let's say you're in the middle of developing a feature, but an urgent bug caused by your teammate comes up and your boss wants you to work on it first.
00:10:40 You haven't finished your feature and it's not ready to commit yet.
00:10:45 But you still have to keep your active changes somewhere so you can get back to them later on and you can start working on this bug soon.
00:10:52 And that's exactly what git stash does.
00:10:54 It lets you temporarily save your uncommitted changes, both staged and unstaged, without actually committing them.
00:11:02 Let's say that I am in the process of implementing an important feature.
00:11:09 And then I have multiple lines of code, which I don't want to lose.
00:11:14 That's going to look something like this.
00:11:17 You can also write some of your own very important code here.
00:11:20 So now how do we save this code so we can use it later on so we can focus on something else for the time being?
00:11:26 It's super useful.
00:11:28 You just run git stash.
00:11:31 As you can see, your important code is now completely gone.
00:11:35 And we got a message here saying that save the working directory on devadrian.
00:11:40 So now you can go ahead and implement this urgent fix that your boss requested you to do.
00:11:47 You can then run git add, git commit, and say save the day.
00:11:53 Of course, this is not a realistic commit message, but in this case, since you implemented the urgent fix, you indeed did save the day.
00:12:00 And you can even push that code if you want to.
00:12:02 So it can run git push.
00:12:04 Great.
00:12:05 The day is saved, but now you want to get back to implementing that other feature you were working on before your day was ruined by a bug.
00:12:12 To get our code back, simply run git stash, apply, and then enter a stash name.
00:12:19 But how do we get to a stash name?
00:12:22 You can run a command git stash list to see a list of all stashes.
00:12:27 Currently, we have stash at curly braces 0. So let's do just that.
00:12:33 Get stash, apply stash at curly braces 0. And press Enter.
00:12:41 And you can see that our code got back right here.
00:12:44 Since the implemented fix was on similar lines as our existing code, we have yet another merge conflict.
00:12:50 But by now, you should be an expert in resolving those.
00:12:53 So simply remove the lines around it and keep both the urgent fix and your work in progress.
00:13:01 And that's it.
00:13:01 The day is saved and you can continue working on your feature.
00:13:05 I don't want this to happen, but I'm sure that someday soon you'll encounter an issue in your code that requires you to use one of these three very handy
00:13:15 Git commands.
00:13:16 Git stash will definitely be the first one.
00:13:18 So when the time comes, you'll know how to use it.
00:13:21 Great work.