Git & GitHub Crash Course for Beginners [2026]

This comprehensive course will give you a rockolid foundation in Git for version control and GitHub for collaborative remote storage. You will learn the core concepts like how Git tracks your work through the working directory, staging area and repository. You'll learn the vital git commands from add and commit to stash and rebase through clear real world examples. And you'll learn about collaborative workflows like how to work With branches, handle merges, and use powerful features like pull requests on GitHub. Sumit Saha developed this course. Today we are diving into something really exciting. Git and GitHub. But before

we go any further, let's clear one thing up. Git and GitHub are not the same thing. They are connected. Yes, but completely different. Think of it this way. G is the coffee and GitHub is the coffee shop where that coffee is served. Fun Analogy, right? Don't worry. In just a moment, you will see exactly what I mean. So, let's start by understanding what Git actually is and how it works. Simply put, Git is a powerful tool that constantly keep track of every change you make to your files. And I mean literally all the time, day

or night, 365 days a year. Git records what changed, when it changed, who changed it, and even where it happened. Now what Kind of files are we talking about? Almost any kind, not just code. It could be an image, a text file, JavaScript, PHP, Python, or even a video. No matter what you are working on, G tracks every single change. Which line was edited, when it was done, and by whom? Pretty amazing, isn't it? But here's the best part. The magic of Git doesn't stop there. The coolest thing about Git is that it saves different

versions of your files. Imagine you wrote some code and Then made a few changes to it after a few days. Now you want to make sure the old version doesn't get lost. That's exactly where Git comes to the rescue. It lets you keep multiple versions of the same file effortlessly and whenever you want, you can roll back to any previous version in just a moment. Git is most commonly used in coding projects, but its power goes far beyond just code. You can use Git to keep track of changes and maintain different Versions of almost any

file. This means you never have to worry about losing a file or accidentally overwriting something important. Let's look at a real life example. Suppose you are working on a project. You have spent hours writing code. Your client loves it and everything's going great. Then a month later, the client asks for some new changes. You make the updates as requested. But after a few days, the client comes back and says, "Actually, The old version was better. Now you are in trouble, right? because you have already overwritten the original code. How do you get it back? That's

exactly the kind of problem Kit solves. This is why Kit is known as a version control system. It keeps every version of your files or code safely stored. So you can go back to any previous state whenever you need to without losing a thing. G was created by Linus Torvs, the same brilliant mind behind Linux. And Honestly, what he built is nothing short of genius. Most tools we programmers use have a short lifespan, but Git is one of those rare ones that once you learn it, stays useful for the rest of your career. The best

part, Git isn't hard to learn at all. It's built around a few simple commands and concepts. Once you understand those, the whole system starts to make perfect sense. Still, for beginners, Git can feel a little confusing at first. And that's exactly Why I made this video. Think of it not just a tutorial but as a complete learning resource for mastering it. Here we will cover all the essential topics you will actually use in real world projects. And if you want to jump to a specific topic, you can easily find it from the video timeline. So

if you follow this video closely, I'm sure you'll easily understand every part of Git step by step. Now let's move on to another important topic. The difference Between Git and GitHub. Git is a tool that runs locally on your own computer. It tracks all the changes you make to your files and keeps everything organized. But imagine this, you and your teammate are working on the same project. You are coding on your own computer and your teammate is working from another one. That means you both have different versions of the same project, right? And if your

team has more members, there will be even more Versions each saved separately on their own machines. That's exactly where GitHub comes in. When the project is complete, you will need to combine everyone's work into one single place to merge all those changes together. For that, you need a central hub where everyone can upload their updates. You push your work there, your teammate pushes theirs, and GitHub brings it all together. GitHub acts as that central online server where your team's entire Project lives, making it easy for everyone to see, edit, and share updates in one single

place without any confusion. But GitHub isn't the only place where you can host your Git repositories. There are other popular platforms too like GitLab and Bitbucket. These are also widely used and trusted by developers around the world. Still, among all of them, GitHub remains the most popular and widely adopted platform. In today's discussion, we will Focus mainly on GitHub. It's now owned by Microsoft and is maintained with great care and attention, especially in the programming community. And in the world of open source projects, GitHub's contribution is truly remarkable. So without wasting any more time, let's

dive in and explore how Git and GitHub actually work and see some real world use cases that will help you understand their power in action. Before you start working with GitHub, the most important Thing is to understand its core concept, how it actually works and what its internal structure or architecture looks like. G is mainly divided into two major parts, local and remote. The local part refers to your own computer where you do all your work. This is where your files, code, and every change you make are stored. The remote part on the other hand

lives in the cloud. It's where you push or upload your local work. In most cases, when we say remote, we are Usually referring to GitHub. Now, let's start with how the local part works. In your computer, the folder where you are working on your project is called the working directory. This is where all the action happens. You write code, create new files, modify existing ones, and make changes as needed. And when you feel all right, this version looks good. I want to save this change. That's when you move on to the next stage in kids

workflow. So, what do we do next? We Move our work to the stage. At first, this word might sound a bit unfamiliar, but once you use it a few times, it will make perfect sense. In simple terms, when you finish your work in the working directory, staging means you are saying, "All right, my changes are ready. They can move to the next step." This staging process is the second phase in Git's workflow. Then comes the third phase where we take the staged files and send them to the local repository. You can Think of the staging

area as a middle ground, a temporary space where files sit between your working directory and the final save in the repository. Once you have reviewed everything and you are confident the work is correct, you commit it. Committing means permanently saving those changes to your local repository, locking them in as a recorded version of your project's history. Now, you might be wondering what exactly is a repository. Simply Put, a repository is a place where all the versions of your files and their complete change history are stored. In the case of a local repository, it's a specific

folder on your own computer. For a remote repository, it lives on a cloud server like GitHub. You can think of a repository as a digital cabinet for your code, a secure place where Git neatly stores every record of your work and every change you have ever made. Inside this repository, Git Automatically creates a few system files that track everything, your changes, history, commits and more. These files are managed entirely by Git itself and the whole system runs based on the data stored within them. So if we summarize everything we have learned so far, it goes

like this. First, we work inside our local working directory. Once we are done, we stage our changes and then commit those staged files to the local repository. Up to this point, everything Happens only on our own computer. Nothing has been sent to the cloud yet. We need the cloud only when we want to share our code with others, access it from another computer or keep it safely backed up. That's when we push our local repository to the remote repository. In other words, we upload it to GitHub. Think about it like this. Just as we use

Google Drive or One Drive to store files, photos or documents, we could technically keep everything only on our Own device, but we store them in the cloud so that we can access them from anywhere. And even if something gets deleted locally, it stays safe online. GitHub works the same way. It's our cloud backup for code. So you see the main purpose of this whole process is to make collaboration and remote access possible. Having a remote means we can easily send our code from the local repository to a cloud server and if needed pull that same

code back to any Other machine and that's the core idea of git. The foundation of the entire system rests on this simple concept. Beyond that there's nothing overly complex. Once you clearly understand this basic workflow, everything else in Git will feel much easier to grasp. All right. Now let's see how to get started with Git from scratch. The very first step before working with Git is installing it on your computer. To do that, just open Google and search for Git. Click on the official G website that appears in the search results. Then go to the

download section. There you will find different versions for three major operating systems, Windows, Mac OS, and Linux. Simply choose the one that matches your system and you will get clear download instructions right there. Since Git is already installed on my machine, I won't reinstall it. But if you are working on Windows, click on the Windows option and you will see two Download choices. One for 32-bit and another for 64-bit systems. Just pick the one that matches your setup. Download it and run the installer. For Mac users, when you select the Mac OS option, you will

also find instructions on how to install Git using Homebrew. Just follow those steps and your installation will be done in no time. And for those using Linux or other Unix based systems, you can follow the installation guide provided on the site According to your distribution. The entire process is really simple and straightforward. Once the installation is complete, the next step is to open your terminal or common prompt. If you are using a Mac, simply open the terminal app. For Windows users, you can use either common prompt or PowerShell. Both will work just fine. However, after

installing Git, you will usually get a separate terminal called G Bash. You can use that too if you prefer. Many Developers actually like working in Git bash because it feels very similar to a Linux terminal and makes running Gcommerce a lot easier and more intuitive. All right, I'm opening my terminal now. The first thing we need to do is make sure G is properly installed. To check that, we will type a simple command in the terminal g- version. Then just press enter. As soon as you do that, you will see an output on the terminal

showing the version of Git installed on your machine. Keep in mind the version number might not be the same for everyone. It depends on when you installed G and which update you are using. If G is installed correctly, you will see something like this version output. But if it isn't installed, you'll get an error message instead. Hopefully, G is now properly set up on your machine too and you are ready to start using it. Now it's time to get our hands dirty to do some practical work. As I mentioned earlier, G can be implemented in

any file or folder. Right? So first we need to create few files and folders to work with. Let's start by navigating to the desktop using the terminal. I'll type cd desktop and then press enter. Here cd is a terminal command that stands for change directory. It simply means we are moving from one folder to another. Hopefully you are already familiar with some basic terminal commands like cd, pwd, touch And mkdir. If not, no worries. You can easily learn them using Google or even charg. They are really simple to understand. Just remember for Windows users, some

of these commands might be slightly different. And keep in mind commands like cd, pwd, touch, and mkdir are general terminal commands, not git commands. All right. Now that we are inside the desktop directory, let's create a new folder where we will keep all our project files. We will name it Gy-en 1. So we will type in the terminal mkdir. That means creating a directory gy 1 and press enter. That's it. A new folder named gy-en 1 has been created inside the desktop directory. Now we will move into that folder by typing cd git - 1

and pressing enter again. Perfect. We are now inside the g one folder. And this is where our g project officially begins. So now that we are inside the g one folder, we will create two files. For that, type the following Commands in the terminal. Touch 1.xt and touch 2.txt. Next, we will create another folder named my folder. To do that, type mkdir my folder. Then use cd my folder to enter the folder. Inside this folder, we will create another file by typing touch3.txt. Now, let's check everything we have created in our file system. I will

open the kit one folder in finder on my Mac by typing this command in the terminal. Open dot. Here the dot means the current Folder. As soon as I press enter, Finder opens up. Inside the G1 folder, I can see two files 1.xt and 2.xt and a folder named my folder which contains the 3.xt file. Now I'm going to write something inside each of the files. I opened 1.xt in a text editor. Wrote one and saved it. Then I opened 2.xt, wrote two and saved that as well. Finally, I went inside the my folder directory,

opened three.txt, wrote three and saved it. So now all three of my files contain some Content. This git one folder is actually my working directory. As I mentioned earlier, this is the folder where I'm doing all my work and where all my files are stored. Now, if I want git to start monitoring everything inside this git one folder, I have to tell git this is my project folder. Track all the changes here. For that I'll go back to the terminal. Make sure I am inside the g one folder and type g init. The word init

means initialize. In other words, We are telling g to start working inside this folder from now on. Once I run the command, it shows a message initialized empty g repository. That means g has now started tracking this folder. How do we know that? Let me show you. Since I'm already inside the g folder, if I type ls in the terminal and press enter, I can see all the files and folders inside it. But if I type ls - la. Notice that now we can also see a hidden directory named git. The ls-la command lets us

View hidden files and folders in the system. So we can see a hidden folder named git inside our project directory. But who created it? The answer is g itself. This dogg folder is actually the core of the entire project. It's where git keeps all its internal data such as which files have changed, who made the changes, and what the previous versions were. In short, everything G does is stored right here. From now on, G will be able to track every change I make in My work. Let's say I made some changes to the three files

I created earlier. That means I now have a local repository. But we can also create a remote repository directly. I mentioned this earlier. So let's see how to do it. First I will open my browser again. Then I will go to the URL github.com. If you are new, you will need to create an account on GitHub first. Since I already have an account and I'm logged in, you can see my profile here. On the Left side, you can see my repositories, feeds, and other details. Our goal is to store our local files on GitHub. For

that we need to create a new repository. To do that I will check the blue new icon. Just like we used g in it to create a local repository here we can initialize one in the cloud. I will give it a name gy-en journey. And in the description I will write we are learning it and GitHub I will keep it public so everyone can view it. Then I will click The create repository button. And that's it. A new repository has been created on GitHub. Congratulations. Right now the repository is completely empty. It doesn't have any

files inside it. I want to add some files here. So I will create one. I click on the create a new file button. Name it 1.xt and inside the file I write one. Then I click on the commit changes button. Now the term comet basically means save. Comeing is just like saving a file. Nothing Complicated. Don't worry about this. We will explore comets in detail later. For now, there's already a default comet message saying so I will keep that as it is and click commit changes. Next, I create another file the same way. This time

naming it 2.xt, writing two inside it and saving it as well. Now, if I check my GitHub repository, I can see two files there. 1.xt and 2.xt. At this point, I have two repositories. one on the cloud, meaning on GitHub, and Another one locally on my computer. I initialized the local one myself earlier. But now I want to bring the GitHub repository down to my machine by cloning it. So what should I do? I will go back to my terminal. Right now I'm inside the G1 folder, but I want to clone the remote repository onto

my desktop. So in the terminal, I will type cd dot dot slash. This command takes me back to the desktop just one level back. Now I am going to clone the remote Repository the one I just created on GitHub. For that I need a link which is basically the repositories URL. So I will go back to GitHub open that repository and click on the code button. There I can see an HTTPS link. I will copy that link. Then in the terminal I typed g clone followed by the link I just copied and pressed enter. Now

notice g is pulling my github repository down into my local machine. After a few moments the cloning process is complete. Let's verify whether the repository has been successfully cloned. In the terminal I will type ls. This command shows the list of folders in my current location. As you can see, there's now a new folder named gy-en journey alongside my previous gy-en 1 folder. Now we will enter the g journey folder. To do that, I will type cd g journey. We have now entered the g journey directory. If I type ls, I can see the contents

of the folder and inside it there are two files 1.xt and 2.xt. And if we want to see the hidden files, we'll simply type in the terminal ls- a. Even here you will find agit folder that proves this is also a complete git repository cloned from the cloud. Earlier we saw the same thing in our local repository. Right? So this is how we can create a git repository in two ways. One by initializing it locally and the other by cloning it from GitHub or any other remote server. No matter which way we create it to

start working With g initialization is always required. Now let's look at something new. Suppose I am currently inside the gourney folder. This is the repository I just cloned from the remote. Now if I make any changes to this repository, for example, I open the file 1.txt in a text editor. Inside it I keep everything as it was but add the number one at the end and save the file. Now I want to know what exactly changed or whether G has detected the modification. To check that I will type in the terminal g status and as

soon as I run this command g immediately tells me modified 1.txt. That means g has already detected the change I made in that file. Now let's say I make a small change in 2.xt as well. Just adding a two at the end. Then I run g status again. This time it shows modified 2.xt. That means both files have been changed and g has detected both modifications. This is exactly how g continuously keeps an eye on every Change we make. It's like it's always watching over our project. At any point, we can simply run the g

status command to see which files have been modified or updated. In a real project, we usually work with multiple files at the same time. Right? In that case, g status give us a clear summary of the overall situation. What has changed? Which files are new and which ones are modified. So up to this point we have learned that git can be initialized in two ways Either locally or from a remote repository and with g status we can easily check what changes have been made in our working directory. Hopefully everything is clear up to this point.

So far we have only worked inside the working directory that means we have created and modified files but we haven't yet told g to keep those changes. Now we are going to move them into the staging area. In g terminology, the process of moving changes from the Working directory to the staging area is called adding. Simply put, g add means telling g I want to keep this change. So let's see how g add works. Right now inside our g journey folder, we have two files and both have been modified. Now I will create another folder

inside g journey named my folder. To do that I will type in the terminal mkdir my folder. Then I will use cd to enter that folder. Inside my folder, I will create a new file called free.txt by typing Touch3.txt. As soon as I run this command, a new file named 3.txt is created. Then I open the 3.txt file in my text editor. Inside it, I write three and save the file. Now, we have made quite a few changes, haven't we? Let's see what we did. We created a new folder, added a new file, and modified

some existing ones. In other words, our entire project has gone through multiple changes. So now it's time to move all these changes into the Staging area. To do that, I will first go back to the repository's root folder. Meaning I will move one step up. CD dot dot. Now I'm back in the root directory, which is the gourney folder. From here, I'll run the g add command. But before adding, let's first check which files have actually been changed. So I will type g status. And look, g is showing that two text files have been modified

and a new folder has been created. It is also saying that the old files are Tracked while the new folder is unttracked. Why is that? Because the old files came from the remote repository we cloned earlier. So, G already knows about them. But since my folder is newly created, G doesn't recognize it yet. If I want to move everything to the staging area at once, I have two options. I can either use the command g add d- all or the shorter version g add- a. Both commands do exactly the same thing. So let's first try

with g add d- all. In The terminal I type get add-all. After running this command I will check the status again by typing g status. Now we will see that g has staged everything. In other words, all the changes we made are now ready to commit. We'll talk about commits in detail a bit later. For now, just remember that when we use g add-all, g takes every change and prepares it for the next comet. Now, suppose I want to go back to the previous state, that is remove Everything from the staging area and return them

to the working directory. To do that, I'll type in the terminal get reset. As soon as I run this command, everything goes back to the way it was before. You can see in the terminal, it says unstaged changes after reset. Now, if I check the status again by typing g status, you will notice that everything is back to the earlier state just like before. All right. Now, let's take a look at how g addy- a works. Just like Before, I will type in the terminal g add- capital letter a. After running this command, I will

check the status again by typing g status. And you will see that git has tested everything just like before. That means all the changes we made are now ready to commit. So whether we use g add-all or g add- a do the same thing. G stages every change. You can use either one. It doesn't make a difference. Now I will run g reset again to unstage everything and bring All changes back to the working directory. Then I will check the status once more using get status. Everything looks good again back to the unstaged state. Now

in this state if I type in the terminal get add dot. What happens then? At first glance it seems like it's doing the same thing as g add-all everything appears to be test but actually that's not the case. Here's where the difference lies. Let's see what that difference really is. I'll run Get reset again to return everything to the previous state. Now all files are back in the working directory. Next, I will go inside the my folder directory by typing cd my folder. Now that I'm inside my folder, I will type g add dot. Then

to check the status, I will type g status. And look, g has only staged the three.xt file that's inside my folder. The other files in the root folder are still unstaged. This difference is really important. The options d-all or - A mean that g will stage every single change across the entire project. But using the dot means git will only stage the changes within the current directory you are in. Also keep in mind if there were a subfolder inside my folder using the dot would still include the files inside that subfolder too. In simple terms

the dot means the current directory and everything inside it. So now we have seen three variations of the g add command d- all- a and dot. The First two work exactly the same way while the dot version is a bit more limited in scope. Now I will run g reset to bring everything back to the previous state again. Next let's look at another important concept. I will go back to the root folder by typing cd dot dot. Then in the terminal I will type git add-all so that everything is staged again. Now we know all

our files are ready for commit. At this point I make some changes directly in the working Directory. For example, I delete the file 2.txt and create a new one named 4.xt writing four inside it. That means I have deleted one file and added another new one. Now if I check the status by typing g status, what do you see? G shows that under changes to be committed the previously staged files are still there. But under changes not test for commit, it now lists 2.xt as deleted and 4.xt as unttracked. So if I now type g

add star and then check again With g status, you'll see that g has st the newly created for.txt file, but it hasn't st the deleted 2.xt file. That's why it's important to understand that g add star only stages new or modified files but not deleted ones. The behavior of the aesthetics is that it stages all visible changes except for deleted files. In other words, if a file has been deleted, it won't be added to the staging area. That's the key difference between the star and the dot and the d- All options. This is how the

star works in g add. Now let's return to the previous state again by typing g reset. Then check the current situation with g status. Now if you want to stage only a specific file say 1.xt which has been modified you can do that by typing g add1.txt. Similarly if you want to stage a file inside a folder for example the file inside my folder you can write g add my folder/3.txt. Let's test it. I type g add2.txt. After running this command, if we check the status using g status, we'll see that only 2.xt has been

changed. So yes, we can also stage individual files by specifying their names. Now let's go back again by typing g reset. This returns everything to the previous unstaged state. We can also stage files by their extension. For example, if we want to stage all txt files, we will write g add star.txt. This command stages all txt files in the current directory excluding deleted ones. Note that g only stages the changes it finds in the root folder. It won't include deleted files or files inside subfolders. Finally, if we want to stage everything at once, the best

and simplest practice is to go to the root directory and type g add dot. After doing that, all the changes are staged together. If we now run g status, we'll see that everything has been staged Successfully. That means all our changes have been moved from the working directory to the staging area. So far, we have learned how to move changes from the working directory to the staging area using the git add command. Now let's see how we can save those changes from the staging area to the local repository. In g language, this is called a

comet. It means we are confirming and saving our changes permanently. You can think of it like Getting ready for a party. You don't just walk straight out the door. First, you stand in front of a mirror and check your clothes, shoes, tie, and hair. Then the stage where you make adjustments. Maybe you realize this shirt doesn't look good or let me change this shoes. That's an intermediate step. You haven't left for the party yet. You are just making sure everything is in order. If something's off, you can fix it right there. Once you are satisfied

and Everything looks perfect, that's when you finally leave for the party. G works in the same way. Instead of going straight from the working directory to the local repository, we first move our changes to the staging area. This is an intermediate step where we can review, adjust, or even remove changes before saving them permanently. We don't commit directly from the working directory because the staging area gives us a chance to verify everything before Finalizing. When you finally commit, it means you are sure everything is correct. No more mistakes and now the work can be saved

permanently. That's why this process is called a commit. Now let's see how to make a commit in practice. First we will check our current state using g status. It shows that the staging area contains some changes. These are ready but not yet committed. To commit them, we will write g commit / m space and a commit message. The /m flag lets you add a short message describing what you changed. For example, g committ/m I have made some changes to the files. Now, sometimes an error may appear the first time you try to commit. When you

install git for the first time and attempt a commit, you might see a message like please tell me who you are. Don't worry, this is completely normal. It's just G's way of asking for your identity before recording a comet. It needs to know who Is making the changes and from which email address. This information is attached to every commit in the project history which later helps track who made which changes. Fixing this issue is very simple. G actually tells us exactly what to do. Just run the following two commands. Get config- global user and pass

your email address. Then get config- global user.name pass your name. By running these two commands, the problem is solved. The first command Sets your email address globally and the second one sets your name globally. The d- global flag means that this configuration will apply to your entire computer. So every git commit you make from this machine will use the same name and email from now on. If you want to make the configuration specific to a single project, you can use the d-local flag instead of d- global flag. That way the settings will apply only to

that particular repository. In short, when You use git for the first time, setting up your user configuration is mandatory. It's part of the basic Git setup you need to do before committing. Once it's configured, G will automatically recognize your identity for all your future commits. Since I already have Git configured, I don't need to set it up again. All right, let's go back to our main task. We are going to make a comet. We already know what to type in the terminal. get commit minus m. I have Made some changes to the files. Perfect. The

commit is done. The terminal now shows how many files were changed, how many lines were added and how many lines were deleted. Let's verify everything by checking the status. G status. As you can see, everything looks clean now. Meaning all the changes have been successfully saved in the local repository. From now on, whenever you make new changes to any file, you'll have to stage and commit them again just Like before. One more thing about comets, you can always roll back to the previous state if needed. To do that, type in the terminal get reset head

and a t sign. This command will undo the last commit and bring everything back to the working directory. Now, if we type g status, you'll see that all the files have returned to the working directory, ready to be staged again. You can now modify or commit them as you wish. See how amazing it is. You have complete Control over your work. It's just about remembering the right commands. We will explore even more useful features soon. Now let's move on to the use of g remove. But before that, let's make a new commit just like the

one we did earlier. So in the terminal, I will type g add dot then get commit minus m. I have made some changes to the files. Perfect. Our commit is done. Now let's manually delete the 1.xt txt file from our file system and then go back to the Terminal. I'll type get status. Now you can see the change. It shows that our 1.txt file has been deleted. After that, if I type get add dot, the deletion will also be sted, right? So instead of deleting a file manually and then adding it again, you can actually

do both steps in a single command. If you want to delete a file and stage that deletion at the same time, just type get rm4.txt. Here we are taking for.txt as an example. This means we want to delete 4.txt and automatically move that change to the staging area. Once we run this command and then check the status with G status, you will notice that 4.xt has been deleted and at the same time staged. So we no longer have to perform two separate steps, deleting and adding manually. We can do both at once with this single

shortcut. If we check in Finder, we'll see that 4.xt has disappeared. Now let's look at another example. But before that, we'll roll Back the deleted file. To do this, we will use the get reset command. However, when you run a normal G reset, it only brings back the changes, not the deleted files. Once you execute reset, you'll see in the terminal the message unstaged changes after reset. But if you check your file system, the deleted file hasn't returned. That's because a normal reset only brings back the staged changes, not the actual files. We can confirm

this by running g status. You Will notice only the changes are back. Manually deleted files are still missing. If you want to restore everything, meaning both the changes and the deleted files, then you will have to run get reset- hard. Once you execute this, both your changes and the deleted files return to their previous state. Now let's explore the use of get remove a bit deeper. Suppose you want to remove a file. Now let's say we edit the 4.xt file and write four inside it. That Means there's now a change in the working directory. If

I try to delete it directly using g rm4.txt, what happens? The file isn't deleted and g starts showing an error. The following file has local modifications. This means it isn't allowing the deletion because it has detected uncommitted changes in that file. Before you can remove it, you either have to commit those changes or confirm that you truly want to discard them. If you are sure you want to delete The file anyway, you can force it by using get rm/f 4.xt. As soon as you run this command, the file is forcefully deleted. If you check your

file explorer, you'll see that 4.txt is gone. Now, let's look at another situation. I'll run another hard reset. Get reset- hard. This brings everything back again. I'll now modify the file for.txt by writing hello inside it. Now, if I type get rm-cached 4.txt, txt. This removes the file from the staging area but keeps it physically in your working directory. Let's check it with G status. You'll see that 4.txt has moved to the unttracked file section. It's no longer staged, but the file itself still exists in the system. That's the difference between the d-force and d-

cache flags. The d-force flag completely deletes the file while the d-cashed flag only removes it from staging. keeping the actual file intact In your working directory. Another useful command is get rm-r folder. Here the - r flag stands for recursive. This means if the folder contains other subfolders or files, all of them will be removed recursively. If you only mention the folder named without -ash r, then only that folder will be removed, not its contents. All right, let's try this out. But first I will reset everything again by typing g reset- hard. Now that the

reset is done, We'll experiment with our my folder. Okay, in the terminal I will type g rm- r my folder. And as you can see the folder has been deleted from our file system as well. If we now check the status using g status, we will notice that my folder is listed as deleted and has already been staged automatically. Now I will reset everything again by typing get reset- hard. Perfect. So far we have made quite a few comets. Right now let's learn how to view those Comets. Basically viewing comets means checking the comet log.

And doing that is very simple. In the terminal just type get log. That's it. Instantly you will see the full comet history. Here we can see three comets. Right. Along with each one, there are details and messages that clearly describe what was done in that comet. You will also notice some long random strings. Those are comet ids. Using these ids, we can go back to previous versions later on. Don't worry, We'll learn how to do that soon. For now, just remember this part. The first two commits were created when we made files while setting up

our GitHub repository. And the last one was made when we modified some files recently. Now if we want to view this log in a cleaner, more compact format, you can use this version of the command. Get log d- on one line. Once you run it, you'll see a nice short summary of each comet with just the essential information. The Unique comet ids are also shown in a shortened format. These shortened ids can also be used to return to any previous version later on. Now let's move on to one of Git's most powerful and important features,

branching. At the moment, our repository has only one branch. A branch in Git is like a separate line of development where you can work independently. If you check the online repository we cloned earlier, you will see that the default branch is Called main. It used to be known as the master branch before. This is the default branch where all work begins. In recent times, G has shifted from calling it master to main. But the idea remains the same. The main branch is your project's central line of development. To understand the concept of branching more simply,

imagine you are working in the kitchen of a large restaurant. The main branch is the main kitchen where all the dishes are prepared and served To customers. Now, if your client wants to try a new dish or recipe, you wouldn't experiment directly in that main kitchen because if something goes wrong, it could ruin everything. Instead, you create a separate taste kitchen where you can safely prepare and taste the new dish. Once the recipe is perfected, you bring it back into the main kitchen to serve it officially. It works exactly the same way. Instead of making

changes directly in the main Branch, you create a separate development branch where you test and commit all your changes. Once everything is stable and verified, you merge that branch back into the main branch. This ensures your main project stays safe while new features can be developed and tested without breaking anything. In short, branching in Git provides a secure and organized intermediate step that allows you to review, test, and manage changes before merging them into The main codebase. Now, since I have already mentioned the word merge, let's understand what it really means. Merge simply means combining

the changes from two branches into one. It's an important concept for understanding how branches work. In Git, you can create multiple branches like staging, development, front end or back end and work on each of them separately. Once all the changes are finalized and tested, they are merged back into the main branch. Right Now, our application has only one branch. To see how many branches we have, we can type in the terminal get branch. This command shows the list of all branches. At the moment, we have only one, and the branch we are currently in has

a star next to it. To create a new branch, we simply write g branch followed by the branch name. For example, let's type g branch development. Now if we run the same command again like get branch, we'll see Two branches listed, main and development. That star next to main means we are still on the main branch. When a new branch is created, it takes the exact state of the branch you were on at that moment. So in this case the development branch is an exact copy of the main branch. Remember whenever you create a new

branch it inherits the current state of the branch you are in. Now that we have created a new branch let's switch to it. To move to the Development branch type get checkout development. We are now inside the development branch. If we check the current status using g status, we will see that everything looks clean because the development branch has been created with the same content as the main branch and it was clean before. Now let's go to our file system and create a new file named 3.txt. Inside it, we will write three. Then back in

the terminal, if we type g status, we'll see that there's a New file. To stage it, we type g add dot. And to commit it, we write get commit/m I created 3.txt and entered three there. Now our commit is done inside the development branch. Next, let's switch back to the main branch. To do that, we type get checkout main. Now we have moved from the development branch back to the main branch. If you check your file system now, you will notice that the 3.txt file is no longer there. Why? Because the changes made in the

development branch exist only in that branch. those changes haven't been merged into the main branch yet. The moment you switch back to the main branch, G automatically hides the changes made in development, showing you only what exists in that main branch. This demonstrates just how much control G has over your file system. When you switch branches, G instantly adjusts which files are visible so that you only See the changes relevant to that specific branch. There's no duplication or conflict in your file system. G manages everything seamlessly. In this way, you can create hundreds of branches,

each containing its own set of changes. And G will always show you a separate isolated view for each one. But remember, for any change to actually take effect, you must commit it. Whatever branch you are working in, the commit must be made there. Once Committed, G understands that those changes belong exclusively to that specific branch. That's why when you switch back to the main branch, the changes made in the development branch don't appear there. Now let's say we make a new change to the for.txt file while we are on the main branch. Let's add a

four to it. Then if we check the status by typing g status, we'll see the new change. Let's stage it using g add dot and commit it with g commit minus m. I changed four.xt and added additional four. Now both branches have changes. The main branch has this new comet and the development branch still has its previous one. Since both branches now contain updates, we will merge the changes from the development branch into the main branch. But first, let's start by merging the main branch into the development branch just to synchronize everything. So, first we

switch to the development branch by typing geckout Development. Now that we are inside the development branch, we will run gge main merging main into development. After the merge, you will notice that the changes made in the main branch have now appeared inside the development branch as well. For example, the updated for.txt file is now present in the development branch alongside the previous changes. In short, updates of both branches have been combined and the Development branch now reflects all the latest modifications. Next, let's switch back to the main branch by typing git checkout main. Once we

are back on the main branch, we can see that the changes from the development branch haven't yet appeared here. So now from the main branch, we will merge everything from the development branch by typing gerge development/m merging on main with development. After running this command, you will see That the 3.txt file from the development branch has now appeared in the main branch as well. That means both branches changes have been successfully merged and the merge process is complete. However, sometimes during a merge, conflicts may occur. A merge conflict happens when the same part of the

same file has been changed differently in two branches. For example, if you modified 1.txt in the main branch and someone else modified the exact same section of 1.xt in the development branch, Git won't know which version to keep. In such cases, Git flags the file as having a conflict and you will have to resolve it manually by deciding which changes to keep or by merging both versions yourself. Right now we are on the main branch. From here we will create a new branch so that the main branch remains untouched while we simulate a conflict. Let's

move ahead quickly. I run the command get branch staging to create a New branch named staging. This branch now contains all the latest updates from main. Then I switch to it using get checkout staging. While working on the staging branch, I open my file system and go to the file named 4.xt. At the end of this file, there was the number four. I add 44 at the end and save the file. Now the staging branch has a change. When I run g status, I can see that the change is being tracked. So I add and

commit it by running g add dot And then get commit / m changed 44. The staging branch work is done. Next I switch back to the development branch by running g checkout development. When I open 4.xt here I don't see 44 I added earlier in the staging. So I write 444 and save the file. Then I run g add dot and commit it with g get commit / m added 444 on 4.xt. That means the development branch now has its own separate change. Now while staying in the development branch I try to merge The changes

from the staging branch using git merge staging. But g fails to merge automatically and shows an error. Automatic merge failed fix conflicts and then commit the result. This happens because the same line in 4.xt was modified in both branches staging and development. G can't decide which version should take priority. So it leaves the decision to us. In this case the developer working on the development branch or whoever is managing it has to Manually resolve the conflict. When you open for.txt txt in a text editor. Git marks the conflicting section clearly showing which part came from

staging and which part came from development. You will see both the double four from staging and the triple four from development. It's now up to you to decide whether to keep one, remove one or combine both changes. While staying on the development branch, you decide which version to keep. Let's say you Choose to keep the triple 4. You remove all the conflicting markers. Save the file and then run get add dot followed by get commit minus m merge conflict solved. The commit messages merge conflict solved. Now you switch back to the staging branch using get

checkout staging. When you open the file system and check for.txt, it still shows 4, meaning no change has been applied yet. At this point, you can choose to merge changes either into staging or Development since both branches are now in sync. Let's say we decide to resolve it from staging. We run the command gerge development. This time g marges everything smoothly without any conflict because both sides now contain the same content. When you check the status using g status, it shows everything is clean. Now if we want to bring these merged changes into the main

branch, we switch to it using get checkout main. Once we are on the main branch and open the file System, we notice that for.txt doesn't yet have the latest update. So we merge the staging branch with git merge staging. Immediately all the latest changes flow into the main branch. The double four from staging and the triple four from development now combine perfectly resulting in the final merged version. And that's how the entire process of merging and resolving merge conflicts is completed. So far we have learned how branching works. We have Already seen how to switch

from one branch to another using the checkout command. Now earlier when we talked about git log I mentioned that we can also go back to a previous version using a comet ID. That's what we are going to see now. And to do that we will again use the check out command. First let's check our comet history. We can do that by running get log d- on one line. Right now we have nine comets in our log. Now let's make a small change. I open the One.xt file and write hello inside it. Then I stage it

by running g add dot and commit it using g commit/m update 1.txt file. Next, I again run get log d- on one line. And all the comets are nicely displayed. Now, I want to switch back to one of my previous comets, especially the one named merging main into development. To do that, I will simply copy the comet ID of that comet and type get checkout that come ID. Earlier, when we switched branches, We used the branch name. But this time, we are using a comet ID instead. Remember your comet ID will be different from mine.

After running this command, the project will move from the main branch to the exact state it was in at that previous commit. However, you must ensure that all your changes on the main branch are tracked and committed before doing this. If there are many unttracked or uncommitted files, it won't allow you to check out to a previous version. Once You run the command, you'll see that in the terminal, instead of showing main, it now says head detached at your comet ID. That means you have successfully switched to that particular commit. If you open 1.txt now,

you will notice the hello line you added earlier is no longer there. That confirms you have returned to the previous version of your project. But now suppose you want to go back to your latest date. That means returning to the main branch. In that Case, you will use the same command as before. Get checkout main. Perfect. Now you have switched back to the main branch. Meaning you are back to the most recent version of your project. So we have seen how to switch between comets, how to move from one version to another. Now let's explore

something new. How to compare one comet with another. If we want to see the differences between our current comet and a previous comet, what lines of code were added? What lines Were deleted? We can do that easily using g commands. Before that, let's first check our comet history again by typing glo- one line. We can see that there are now 10 commits in total. Now we'll compare the comet update 1.txt file with the previous one. That means merging main into development. For that we will need the commit ids of both. Since we have already run

glog, we can just copy those two ids. Once we have them, we will Write the command g diff doublef then the first comet id space then the second comet id. After running this command, G will show us the exact changes made between those two comets. The terminal will display which files were changed. What was removed in red and what was added in green. Also notice one important detail in g. We place the most recent comet ID first and the older one second. This means it will show differences from the perspective of the Newer comet. What's

newly added or removed compared to the older one. If you reverse the order, that means putting the older comet ID first and the newer one second. G will show the opposite perspective. Try running the command both ways a few times. You will easily understand how the comparison works. All right, just a quick reminder. Right now, you can't exit the terminal view because you are inside the log window. As I mentioned before, to exit From there, simply press Q on your keyboard. That will close the log view immediately. So far everything we have done has been

inside our local repository. Meaning we have staged files, made commits and stored everything locally. But our real goal is to send those updates to the remote repository like GitHub. When we send local changes to a remote repository, that process is called a push. And if any changes have been made in the remote Repository that we want to bring into a local repository, we use fetch. When you run g fetch, the remote changes are downloaded into your local repositories memory, but they won't appear in your working directory yet. To actually update your working directory and see

those changes in your files, you need to run git pull. So in short, push means sending local changes to the remote. Fetch means bringing remote changes into your local repository but not merging Them yet. And pull means fetching plus merging. So your working directory immediately reflects the remote changes. In other words, gpool is equal to g fetch plus g marge. Let's see an example of how g push works. We have already made several changes in our local repository and now we want to push them to the remote main branch. Since we are currently on the

main branch, the command will be get push origin main. Here origin refers to the remote Repository and main is the branch we want to push to. After running this command, all your latest comets will be sent to the remote main branch. If you check your repository on GitHub, you will see that everything is updated. However, only the main branch is pushed. Other branches aren't uploaded yet. This means we have only pushed our main branch to the remote's main. Now if we switch to the staging branch using g checkout staging and then run g push Origin

staging g will create a new branch named staging in the remote repository and push all your staging changes there. When you check github again you'll see that the staging branch has been created and updated. Similarly, if you switch to the development branch by running gout development and then g push origin development, the development branch will also be uploaded to the remote. So now all three branches main, staging and development are fully synced With the remote repository. Finally, I switch back to the main branch again using g checkout main. By now the concept of g push

should be crystal clear. Now imagine we have already pushed our local changes to the remote. Let's see how fetch works. Suppose we make a change directly on GitHub. For example, we open the file 3.txt on GitHub. Type three and commit the change. Now the remote main branch has a new update that our local main branch Doesn't yet have. It's behind the remote version. While staying on the local main branch, I want to bring in the latest changes from the remote. So I run the command get fetch. It immediately fetches the new changes from the remote

repository, but those updates don't yet appear in your local file system. For example, you won't see any update in 3.txt until you merge the feted changes. Once you run get merge, the remote changes will finally reflect in your Local working directory as well. Now, let's say we edit the remote 3.txt file again. This time, we add 33 after three and commit it on GitHub. The remote main branch is now ahead once more. To bring in all those updates and merge them into your local main branch at once, we use gpool. Gpool automatically performs both fetch

and merge in a single command. Which means all the new remote changes including the latest updates in 3.xt will immediately appear in your local Files. So that's how gitpool helps you fetch and merge all remote updates into your local repository in one go. We have now learned how to push changes from local to remote, fetch changes from remote without merging, and pull changes from remote while merging them automatically. These three commands, push, fetch, and pull are among the most frequently used G operations and are more than enough for most of our daily development work. Now,

let's move on to Something new. Imagine you are working on a project. You start developing a new feature, writing a lot of new code, and modify several existing files. After some time, you realize that the approach you took isn't working at all. But by then, you have already made changes across 10 to 15 different files. Some with new code, some heavily modified. In this situation, you want to discard everything and go back to the previous state. Now, think about it. Would you Really open each of those 10 to 15 files manually, remove all the new

lines, and try to restore the old code one by one? How accurate or even possible would that be? Probably not at all. In this case, the simplest answer is it's actually not possible, almost impossible. And the complicated answer is you could try doing it manually, but there's no guarantee everything will return to its exact previous state. And this is exactly where the magic of the get Restore command comes in. The get restore command helps you revert any files or directory back to its previous state, that is to the state of the last comet. It's mainly

used to undo local uncommitted changes or to remove changes that were added to the staging area using g add. Let's test it out. Suppose in the 1.xt file, I write new feature. Remember this repository already had some committed history. Now I'm just trying to develop a new feature. But After writing the new code, I realized that the change I made in 1.txt adding new feature was actually a mistake. The previous version was fine and since this change isn't ready to be committed, I want to undo it and go back to the last committed state. To

do that, I'll simply run get restore 1.txt. As soon as you run this command, the file instantly reverts to its previous state, the exact version from the most recent commit. If you want to restore an entire directory Instead of a single file, just type the directory name after g restore and it will bring everything in that folder back to the last committed version. And if you want to undo all changes across the entire repository, you can run g restore dot. This will restore every file to its last committed state. Now, if you have already staged

some changes using g add, you can still undo them using the d-staged flag. For example, g restore d-staged file name or g restore D-staged dot. This removes the files from the staging area but keeps the working directory unchanged. So in summary, the get restore command helps you bring any file or directory back to its previous or last committed state. It's mainly used to undo local uncommitted changes before they're ever committed. Now let's move on and talk about G stash. Now imagine this. You are working on a new branch developing a big feature. It's a long

process and you Have already finished about half of it. But the work isn't yet in a state to be committed. Suddenly another developer messages you saying there's a new update on a different branch and you need to check it out and give feedback. Now the question is how will you switch branches without losing your unfinished work? Are you going to throw away all your progress using the g restore command? Of course not. There's no reason to go through that kind of hassle when gives Us a much smarter way to handle this using the g stash

command. With git stash, you can temporarily set aside your unfinished work. Switch to another branch to do something else and later bring all your changes back with a single command. Let's see how it works with an example. Suppose in our 1.xt file, you write another feature. You are currently on the main branch. Now let's say you need to switch to the development branch to review a new Feature. So you type git checkout development. But git throws an error. Your local changes to the following files would be overwritten by checkout 1.txt. Please commit your changes or

stash them before you switch branches. Aborting. This means because G doesn't allow switching branches when there are uncommitted changes, it's protecting your work. But since your feature isn't ready to be committed, this is exactly when we use Gash. So you can run g stash. The moment you execute this command, your uncommitted changes disappear from your working directory. But don't worry, they are not lost. It has safely stored them in a temporary area called the stash. This lets you freely switch branches without affecting your unfinished work. Now let's switch to the development branch. Get checkout development.

You have now successfully switched branches. You can review the new feature, make Notes, do whatever you need to. Once you are done, you switch back to your main branch again. Get checkout main. But now when you look around, you'll see that your unfinished feature, the one you were working on earlier, isn't there. Don't panic. It's still saved safely in the stash. To bring it back, you just need to pop it out of the stash using the command get stash pop. As soon as you run this, all your stashed changes reappear in your working directory. The

Pop command restores the most recently stashed work and simultaneously removes it from the stashed list. If you have stashed multiple times, G keeps them all in order. Newest on top, oldest at the bottom. When you pop it, brings back the most recent one first. But if you want to reapply the stashed changes without removing them from the stash list so that you can reuse them later, you can use the apply command instead. For example, get stash apply. This way your Changes are restored but they also remain safely stored in the stash for future use. So

now I run gash again and then this time I type the command get stash apply. After running it, you will notice it behaves almost the same before. The changes come back just like when we used pop. All right. Now, let's understand the difference more clearly. We already know that G can store multiple stashes and we can even view a list of all those stashed changes. To See that list, we type get stash list. Once you run this command, you will see a list of all your saved stashes. If you look closely, you'll notice that each

stashed item is marked with an identifier like stash zero stash 1 and so on. You can use these identifiers to apply or pop specific stashes as well. For example, get stash pop stash zero or get stash apply stash zero. Both commands will work. The only difference is how they handle the stash afterward. Let's walk through this difference step by step. First, I check my stash list using get stash list and I see there's just one stash in the list. Since I already ran g-ash apply once, the stash item is still there in the list. To

understand this better, let's first remove that stash manually using the get stash command. The drop command basically removes a specific stash from the stash list. All right. So, in the terminal, we will simply type get stash Drop. Now if we check our stash list we will see that it's completely empty. Type in the terminal get stash list. See the stash list is totally empty. Now since we previously used g-apply all the changes are still in our working directory. We can confirm that by typing g status. Let's do that g status. And as you can see

the changes we applied are still there. Now let's go ahead and stash those changes again by typing g stash. That means we have stored our Changes back into the stash. Next let's check our stash list again. Type in the terminal get stash list. What do we have here? We can see there's just one stash entry. So now we are going to look at the difference between pop and apply. Now I run get stash pop. The stashed changes are successfully restored into my working directory. Then I check the list again with get stash list and this

time the list is empty. That's because pop brings your changes back and removes Them from the stash list. It's like taking them out permanently like cut. That's because pop brings your changes back and removes them from the stash list. It's like taking them out permanently. Now let's dash something again. I run gash and check the list once more. g-ash list. This time I see one stash item again. Now I run g/ apply. The command works perfectly. My files are restored just like before. But when I check the stash list again using G stash list, boom,

the stash is still there. It didn't disappear. So here's the key difference. G-pop restores your changes and removes them from the stash list while g-apply restores your changes but keeps them in the stash list for future use. That's exactly what I wanted to show you. I walked you through both commands so you can clearly understand how they behave differently. Hopefully now the concept is crystal clear. Now let's talk about get revert. The get Revert command is used to undo the changes made in a previous commit. But instead of deleting that old comet, it creates a

new one that reverses those changes. In other words, it cancels out the effects of a previous comet while keeping the project history completely clean and traceable. That's why it's called revert because it doesn't delete any comet. Rather, it creates a new comet that brings back the project to its previous correct state. Simply put, Get revert means fixing an old mistake without erasing it. For example, imagine you accidentally added too much salt while cooking. Instead of throwing the whole dish away, you adjust the flavor by adding some extra ingredients to balance the saltiness. Similarly, get revert

doesn't delete the faulty commit. It corrects it through a new one. Now, to revert something, you will need its comet ID. Let's see an example. Suppose in the file 3.txt, you added the line Hello 3. Then you run g add dot then get commit minus m hello 3. Now if you check the log using g log one line you'll see let's say you realize that the hello 3 comet is introduced a bug and you want to remove it. Before that copy the comet ID of hello 3 and then run get revert that comet ID. After

running the command you'll see a prompt asking for a commit message. You can either type a custom message or simply keep the default one and exit it by typing colonw that means Write and quit. Once you do that, the changes from hello 3 will be undone. Now, if you check the logs again using g log one line, you will notice there's a new commit added specifically for the revert. At this point, you might be reminded of g reset, right? The main difference between g reset and g revert lies here. Get reset can take you back

to a specific comet and discard all comets after that point without creating any new comet. On the other hand, get Revert removes the changes from a specific comet by creating a new one that reverses it. So if your project is on GitHub or any remote repository, other contributors can also see the revert commit ensuring clarity and preventing confusion. Another key point is if you check the logs after a reset, there will be no record of the removed commits. But when you use revert, you will clearly see an additional comet indicating that a revert took place.

Crystal clear. Now let's talk about g rebase. Imagine you are starting to work on a new feature. So you create a new branch called feature by checking out from the main branch. You begin developing the new feature, making changes bit by bit and committing your progress as you go. Meanwhile, another developer adds more updates to the main branch for production. Now you also want to include those latest updates from the main branch into your feature branch. So What can you do? Well, there are several ways to handle this. As we have seen before, one option

is to merge the main branch into your feature branch. If you do that, G will create a new merge comet and all the latest updates from main will be merged into your feature branch. However, note that merging always creates an additional commit. You can see it clearly if you run git log. Some developers find these extra merge commits a bit messy and if you continue Merging multiple items, your commit history can look quite cluttered. In such cases, a better solution is to use git rebase. When you perform a rebase, the base of your feature branch

changes. That means if you rebase onto main, all the new comets from main will be applied directly into your feature branch. Then all your feature branch commits will be reapplied on top of them. So while your main branches code content remains the same, the comet history becomes much Cleaner and more linear. You can easily verify this using G log. Now let's understand this with an example. Let's say we create a new branch called feature from main. Get branch feature. Then we switch to that branch. Get checkout feature. Now we are inside the feature branch. Let's

open 1.xt and add the line adding dark mode functionality. Then stage it. Get add dot and commit it. Get commit minus m. Adding dark mode functionality. Now let's switch back to The main branch. Get checkout main. We are now in the main branch. Let's create a new file called 2.xt and write inside it adding dark mode UI. Then stage and commit it. Get add dot get commit minus m adding dark mode UI. Done. That means our main branch now has a new feature dark mode UI. Now we want that same dark mode UI update to

appear in our feature branch as well. So first we switch back to our feature branch. Get checkout feature. We are now inside the feature Branch again. Our goal is to bring the latest updates from the main branch into the feature branch. But this time we will do it using repace. How do we do that? To perform a git rebase, you need to be on the branch you want to rebase and then specify the branch from which you want to bring that changes. For example, if you are currently on the feature branch and you want to

bring in the changes from the main branch, the command will be get rebase main. That's It. Once you run this command, the rebase will be completed smoothly and the dark mode UI update from the main branch will now appear in your feature branch. Here's what actually happens behind the scenes when you use rebase. Kit first identifies the most recent common comet shared between your current branch that means the feature branch and the branch you are rebasing onto that means the main branch. Then all the comets in your feature branch that come After that common comet

are temporarily set aside. Next, it applies all the new comets from the main branch into your feature branch. Finally, it reapplies the saved comets from the feature branch on top of those main comets one by one. The result is a clean linear commit history much tedier than what you get with margin. You can easily see this difference by running git log. However, even though git rebase is very powerful, it's not recommended to use it on public Repositories or branches where multiple developers are working together. If you must use it, you should always inform your team

beforehand. Otherwise, it can cause serious issues. The reason is that rebase rewrites existing comet history. even the comet ids change. So if someone else is working on the same branch, your rebased comets won't match their local copies anymore and they won't be able to pull or sync normally. Therefore, before using rebase, make sure you fully Understand where you are applying it and whether it could cause problems for your collaborators. It's perfectly safe to use rebase on your local or personal branches where only you are working. Just avoid rewriting commits that already exists on a shared

remote branch. Now before we wrap up this tutorial, let's discuss one last important topic, the pull request. When working with G and GitHub, the term pull request, often shortened as PR, comes up Frequently. A pull request is essentially a request you make to merge your changes into another branch, usually the main branch. It's a way of saying, I have made some changes in my branch. Please review them, and if everything looks good, merge them into the main branch. In other words, you can't directly make changes to someone else's repository. So when you finish your work

in your own branch, you create a pull request to ask for permission to Merge your code into the main repository. That's what we call a pull request. All right, let's head back to our Git journey repository on GitHub. By now, we have already pushed our main staging and development branches. At the top of the GitHub page, you will notice several tabs. code issues, pull requests, and actions. We'll now click on the pull requests tab. Here we'll see a big green button labeled new pull request. This is where you can see I Want to merge the

changes from this branch into another branch. Once you click new pull request, GitHub will show you two drop-down menus. Base the branch where you want to merge the changes. We'll select main here and compare the branch from which you want to bring the changes. we'll select development. In other words, we are saying I have made some updates in the development branch and now I want those updates to be merged into the main branch. GitHub will Automatically show a detailed comparison which files have been modified, which lines have been added and which ones have been removed.

Everything clearly visible. If everything looks good, scroll down and click create pull request. Then give your pier a title such as merge development updates into main and in the description box write something like this pier adds the latest updates and fixes from development to main. After that click create pull Request to submit it. Now if you go back to the pull requests tab you will see your newly created PR development domain. Clicking on it you will find three sections. conversation where you and your teammates can discuss or commit on the changes commits which lists all

the commits included in this PR files changed which shows exactly what changes were made in which files if everything looks good after review click the green merge pull request button at the top and Then confirm by clicking confirm merge once it's done GitHub will display a message saying pull request successfully merged and closed That means all the updates from the development branch have now been successfully merged into main. This is how pull requests make code management so easier. Every change gets reviewed first and then merged into main. As a result, the main branch always stays

stable and the entire team can collaborate safely and efficiently. That's how software companies use Git and GitHub. This was my complete tutorial series on Git and GitHub where I tried to explain all the essential day-to-day concepts in the most simplest way possible. I truly believe this series will be specially helpful for those who are just getting started. If you have always felt a bit intimidated or confused about using Git for the first time, these videos were made exactly for you. In short, we have Learned how to create a local repository using Git in it from

our working directory. how to stage files, commit them to update the local repository and finally how to push that code to a remote repository or clone a remote one to work locally. Hopefully, by the end of this video, you now have a clear understanding of how git works. And one more important thing on my logic based labs Facebook page, I have published a git cheat sheet which is especially Useful for beginners. It's completely free. So feel free to grab your copy right now. The link is available in the video description. If you found this video

helpful, don't forget to give it a like and subscribe to the channel because I have got plenty more valuable topics coming up next. And yes, if you have any feedback or suggestions about this video, please share them in the comment section. I read every comment and try my best to reply every comment As well. Stay well and I will see you in the next video.