What is the Git Life Cycle and How it works?

Hello everyone, welcome back to the session. So in this session, we are going to learn about the git life cycle and how it works. So without wasting any time, let’s go ahead and understand the git life cycle.

Guys. In the Git life cycle or about any file that exists or which exists in Git, it goes through the following stages, right? The file first exists in the working directory OK.

once it exists in the working directory, once we finalize the file, we start to stage the file for production or we start to stage the file for committing. So we stage the file using the Git add command and it gets staged in the staging area in the git life cycle.

Once it gets staged in the staging area, the next step would be to completely save the file inside the git version system by committing it, right? So the next stage of the third stage of the last stage is committing the file to the git file system.

OK, so these are the three Git Life Cycle stages of a git file in the git file system.

The Git Life Cycle stages in the Git File System

Now let’s understand each of these 3 stages separately.

Working Directory

So the first stage is the working directory. Now what is the working directory? Any folder in which your code resides can be termed as a working directory.

The working directory could or could not be tracked by Git. It is not necessary that you know git should be tracking or git should be versioning your files inside the folder. Only then it will be called your working directory.

Any directory that you’re working in which has your code in it will be called your working directory. Now you choose which files have to be saved in the git file system. For example, not all files will be saved.

For example, you know in your working directory you would have some output files, you would have you know you would have some input files probably.

Also, you only want the main code to be saved in Git, right? The input and the output files are arbitrary files that could also be generated while your program is being executed, right?

So you don’t want your input files or your output files to be there in your git file system. That’s why you have an option through stage files.

Staging Area

Now what is the staging area in the git life cycle? In the staging area, you choose which files you know you want to commit. So basically imagine it like this you know you have your working directory and then you have a stage for git.

On the stage, you put the files that you want to commit. So in the working directory, you choose the files that you want to be tracked by git.

Once you choose those files, those files automatically become staged hence the term staging area. So the files in the staging area are the files that are to be committed.

Commit

OK moving further to the git life cycle. Then we have to commit. So once we have come down to a list that we want to commit and they are ready in the staging area, all we have to do is pass the command git commit.

And all the files will now have a new commit ID attached to them and they will now be saved in the git file system. OK, so that is what commit is all about.

So, if the files are selected and are ready in the staging area, they can now be saved in the repository. Saving a file in the repository of Git is known as a commit. Right? When we commit a repository in Git, the commit is identified by a commit ID.

OK, so these were the three Git Life Cycle stages, guys.

The Git Life Cycle – explained

Now let’s understand the Git Life Cycle. Using a diagram like this, we have discussed what a working directory is, what the staging area is, and what a commit is.

Program Workspace

Now let us see it in action. OK so this is your programming workspace guys and this is your working directory. OK, now the first step to start saving your files or you know putting your files in git is to 1st initialize a git repository.

So inside this program workspace what you do is type the command git in the git life cycle. Now what it does it start tracking your files. So now git has initialized in your repository.

It creates a hidden dot git file which will have information about all the files that are there in a folder right now. So we have a git-initialized working directory now and inside this initialized working directory you have your files.

But mind you guys, these files are not yet saved in the git file system, they’re just existing in a git-initialized file, right?

Staged files in the Working Directory for Commit

Now the next step is to stage the files that you want to commit, right? So you choose the files that you want to commit and you type the command git add followed by the files that you want to commit and these files now get into the staging area.

Now the staging area is where you can see all the files that are ready to be committed, right?

Files Committed to Git Repository

Once you have staged the files, the next step would be to commit the files to your gate repository.

The moment you commit your file to a GATE repository, it gets attached itself to a commit ID and now your file is successfully saved inside the git repository.

But mind you guys, everything that happened from here till here is happening inside your local system, right? Everything is happening on the local. But git is all about collaborative effort. It’s all about teamwork.

It’s all about you contributing to a project on which hundreds or two hundreds or millions of people are working, right?

How do we Collaborate with the Team?

So now how do you get your file? Or how do you get your project which you have modified or created onto the Internet or the OR among the people who would be ready to contribute to it?

Now the next thing is we need an entity where we can put our files, right? We need an entity where everyone can access it. So this entity is called GitHub, right?

So after committing your files, the next step what you can do is you push your files to a remote repository, right?

What pushing means is whatever is there on your local repository, all the version history, everything gets pushed or gets uploaded to a remote repository that exists on GitHub.

So it could be GitHub, it could be Bitbucket, there could be any platform that could host your code. But we’re choosing GitHub because it’s a free and popular tool that probably each and everyone who is a developer or a tester would have used in his lifetime, right?

Also most, I’ll say and I’ll say almost every open source project is also actually hosted on GitHub. That is also an awesome thing.

OK, so this diagram depicts the whole Git Life Cycle where you start from a program workspace where you have your code, then you initialize the folder to become a git-initialized working directory.

Then once you have done with your code, what you do is you stage the files that you want to commit to the git repository which is called the staging area and then you move ahead and commit the files to the git file system, basically the files that were there in the staging area.

And once you feel that you know your repository is ready to be seen by the world, what you do is push your files onto a remote repository such as GitHub where all your teams can collaborate and add their code as well.

OK, so this is exactly how git functions and how the git life cycle is.

How does Git Works actually?

Our next topic is how git works. OK so now for understanding. So we have understood the Git Life Cycle. We know how you know how a file goes through the process of a file from the part where it exists in a folder to a part where it exists in a remote repository.

We know the process now, but let us now understand what happens in the back end, right? How is git functioning internally? Let us discuss that.

Now, any file that you save or store on Git is stored using commit, right? We have already discussed this and each commit is assigned a commit ID.

So every commit that you do on git is assigned a unique commit ID to it through which it can basically save itself or it can go ahead and identify.

OK, so these six files in the state that they are, are saved as it is in this commit ID. Tomorrow if I change the CSV file, say I add one line or I add 2 lines and then I again save it on GitHub, it will be saved inside another commit ID, right?

But whatever you save in Git, whenever you have committed something on Git, it gets saved forever. You cannot edit that now, right?

So it gets frozen inside the commit ID. OK, so the first thing that you do on git is you commit your folder and now the folder becomes or your repository becomes a part of git using a commit ID.

Now if you want tomorrow to add a new file to your project, say I add this file CSS file to my project, I add that and I add some code to it. Now when I save my repository it will have 7 files instead of 6 and will be saved inside another commit ID.

Why is Commit ID important now?

OK, now why is commit ID important in the git life cycle?

For example, when I uploaded a code, the code stopped working. So all I want to do now is I want to revert to the previous commit and all I have to type in is get revert and this commit ID and my code will be up and running again.

Because my earlier code was running but this code had some fault in it so rather than identifying where the fault is exactly.

Meanwhile what I do is I do a git revert so that my previous application is up and running and now I can just do a bisection Or I can introspect what exactly went wrong in my code and once I’ve figured out what went wrong in my code, I can fix it again, commit it, and then my code will become live.

OK, so again, these are the things you can do. This is how files are stored inside Git. Now all these commits, these commits, basically exist on a branch in git life cycle.

What is a Branch?

OK, now what is a branch? A branch is nothing but a linear line that is unidirectional. That is, all the commits which are added will be added in front of the last commit.

So the starting of the branch would be commit. The first commit that you do, the second commit would come after that. The third commit would come after that, the 4th. After that, you can never add a commit on the previous position of the branch, OK? It always moves forward.

And a branch also has a component called HEAD. The head of the branch always points to the latest commit.

OK, so if I have a commit ID which is 0001, and if this is the only commit that is there on the branch, the HEAD will also point over here, right?

The moment I add one more commit to the branch, the HEAD will start pointing over there. Right? Now if I want to refer to this commit ID, all I have to do is. I can refer it to either by HEAD or I can refer to buy this commit ID.

OK, so this is what a branch is. Now this branch is called the master branch.

Master Branch

OK, so your project can have multiple branches, but by default, there is only one branch. Whenever you initialize a git repository that one branch is called the master branch.

So any files that you saved, and any commits that you made are all saved on the master branch. Unless you have one more branch that you’re working on, but that you have to do manually. If you’re not creating any branch, it is simply working on Git. Everything is being saved on the master branch now.

Why do we need Branches?

But why do we need branches? We have discussed what branches you understand. OK, so it’s a linear line that is unidirectional, which always moves forward. But the point is, why do we need a branch? Why can’t we just have committed, right?

So we need a branch because we use commit. Or we use git basically for team collaboration.

Now for example, you know you want to enhance this code, whatever code was there in commit ID 002 you added a CSS you want to further enhance and say probably I want a login page to also be added to this website.

Now what you do is you assign this code to a developer right? And how do you assign it? You create a new branch for this feature, So this branch would be called the feature A branch. This branch can also be called the login page branch. It’s up to you what you want to name it, right?

So you name this branch something and now what happens is the developer gets a new branch where a commit has now been made which is which corresponds to the commit that was there on my master branch.

And now what I can do is or What this developer can do is you can work on this code, add, add his feature, and again commit to it. Now when this developer commits back to GitHub or when he commits back to git, his code will be added to the feature A branch.

OK, it will not be added to the master branch. Why is it done So? It is done because my master branch should always contain ready code, which is, which is polished, which is ready for production.

It should not have any incomplete code. It should not have any untested code, right? So that’s why we isolate the development of the code from the master branch by creating a new branch with the name of that branch.

Right now this developer of several developers can work on this branch. Add as many commits as they want till they get the perfect finished code, and when they feel the code you know is finished is done, what they do is they commit. They finally commit to this branch that this is the code that we feel is perfect.

After that the testing is also done, everything is done and if everything goes well, what happens is you can merge this branch back to the master branch. Okay.

The moment you merge this branch back to the master branch, the commit gets added onto the master branch as a new commit and now your master branch again has completed code right.

So this is how git works and this is how team collaboration happens on GitHub right now.

So we discussed theoretically how git works and how different operations or different things can happen on the git life cycle.

Conclusion

In this article, you have learned about the git life cycle and how it works actually. we delve into the core of the Git life cycle, unraveling its intricacies and shedding light on the seamless orchestration of version control.

In every article I have tried to come up with a natural language for you to understand easily. Hope you enjoyed the Git life cycle and learned from this article.

People also read: What does Git stand for?