Ultimate Git and GitHub Tutorial: Version Control & Collaborative Workflows

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.