What is git?

For many it is just a storing and retrieving an old project or file but to many it is a life saver
Git as you may know even as a beginner is a version control system now what does that mean "VERSION CONTROL SYSTEM" sounds like a heavy phrase isn’t it but isn't.
It simply means keeping track and record of your previous versions or stages of project in such a way that they could be later be retrieved and seen or reverted back to.
Let's understand that by an example,
You create a project a todo app with your friend and you do that with the help of a pendrive , you did basic CRUD and kept it as is ,Now let suppose you decide you are going to add dates and calender system features to the project , so you decided to divide the feature among yourselves,
so adding calendar system is your task and your friend will do the dates part to it.Now , after your finished the date feature he hands over the pendrive to you it's your turn now so let's say calendar part was a bit difficult you add this and that and suddenly the code is all messed up and it is not working anymore you have no way of getting back to the previous stage and you dont have a copy of the project so that you can use that as a backup. so you both decide to create a copy of the project everytime you share the pendrive ok now that is resolved but another problem occurs you added so many features together to the todo that it is causing multiple problems.

1. You have too many folders to track having multiple redundant files
2. Your pendrive space is almost full because of the too much redundant code files

So you decide to delete the oldest folders keeping track of the previous 1-2 versions of the project

Soon after sometime you realize that after you added some features and removed the oldest features folders. Now, the Todo needed some of its basic functionality added by someone of you and you have no records about the oldest versions of the project to retrieve the code and use, So that creates another problem .

This is where git comes in as a saviour now let's say all those things happened but now everytime you make some changes you stages or pushed(later on this) a tested code to git you have that version saved inside the .git folder in a amazing format so even if you mess up the code you can backtrack to the previous version and keep it running so your users don't forget about there todos.

You might be asking isn’t it the same thing as our pendrive , Soon the storage might get full . Yeah valid question but git have something up it’s sleeves it compresses the changes done each time not the FULL block of codes but only those changed or added to git at that point of time so when you figured that you needed the old feature you could go back and retrieve that version whenever required. git gets those code snapshots of the changes done at that point and the directory from that version and show it in your working directory this helps reduce the space significantly than the other version control systems which follow the traditional method of the no. of files changed and create version on those like you used to do with your pendrive , and not only that but they are also stored in compressed version , they have an amazing concept of tracking also.

when you commit the project what it does is inside the .git folder there is a objects/ folder containing 3 folders namely blobs(Binary large object)-(contains the actual changes made on the code ) , tree(directory history)-(how the file structure was at that version) , commit(metadata )-(contains the meta data and the hash-id) what it does is on every commit git creates unique hash-id using the SHA-1 algorithm and assign those to the snapshots saved in the blob and tree which connect it to the rest of the node so whenever you ask for a previous versions using a particular hash-id git first checks the commit folder containing the metadata and hash-id to the tree from there it retrives the folder structure and the blobs hash-id at that point of time and gather all the required blobs for that directory at that point in time , which is then shown in the working directory of the user which is you .
And that's how git core works and to keep this more user friendly and easy to understand github is used.

Simple Devloper Workflow,

Now now you maybe wondering what this init, add, commit, push, track and all this means.
Let's start from

Init command

git init 

This command initializes the git and creates .git basically saying that your files are ready to be tracked please stage your files.

Add command

git add <filename>

This command stages your file or files tells git they are ready to be pushed and no longer needed to work
REMEMBER add command doesn't mean your code is saved that might be dangerous
It's just gets you file staged to go and the snapshot of the directory have been taken.

Commit command

git commit -m  "your message here"

This may seem like a no-need command but this is useful later when you have so many versions and want to get to where you added a particular feature or block of code
The message you write should be in short describing what you did on that particular part what you added or optimised or deleted in the commit message make sure it's understandable to others clearly
Helps a lot when you get into big projects.

Final git push

git push origin <branch>

The push command is the command which pushes your code to git and the project is now being tracked by git
This is the final spell you write before git creates the version of the particular stage of the project you are/were in.
Finally push to the git

Now as you push more commits each version will be saved from when you made the CRUD for todo to the advanced features and all. So, how we do we handle such many commits and revert back.

Before we move to backtracking the versions lets first understand what is a branch?

Branch it just means multiple pointers each working in a diffrent part of the code , git by default creates the master branch in which you work but you shouldn't, because you can create multiple branches and push code to those branches and test the code before pushing it to the master branch which contains the safe and tested code working in the production

In a production level project there is no single developer but the project is made using multiple devs pushing the code in and out simultaneously to a single source , you might think that this may cause error and could cause overlapping exactly that is why this branches are made.

Let suppose your todo app has two devs you and your friend so what you will do is create a 3 three branches one for him, one for you and one to test if your code doesn’t conflict with each other when added, these branches help you to divide the projects into chunks for diffrent devs.

For more detailed information visit : Git Branch Docs

Now let's say what if you cooked so hard that the code is now cooked
How do we revert that code
There are very simple commands and steps

1. You need to check the version you want to jump back to.

   git log—> Displays the complete meta information about each of the commit and the hash-id to that version.

   git log - - oneline—> displays the short oneliners only displaying the hash-id and the commit message added at that time.

2. Get the hash-id of the version you want to revisit #01xyz2 once you have the hash-id checkout that branch

   git checkout 01xyz2 —> displays the branch/version of the code files in the project but keeps you in a detached state not connected to any branch as soon as you checkout to the previous branch you will get those latest codes

   git checkout -b <a-new-branch-name> hash-id —> displays the version of code but also creates a new branch of the given name so that it can be revisited again and the pointer is not in detached state it is connected to the new branch which was created on this command

3. After you revisit the code there are two options if you just wanted to check that you can do and use the previous code if needed but it you want to completely go back to that version there are three version of options

   git reset - - soft hash-id —> You revisit the previous code completely but you have all the after changes you did after that as staged so if you commit at that point all the code from the latest commit will be back to the latest commit

   git reset - - mixed hash-id or git reset hash-id—> You revist the branch and at that point if you stage and commit your latest code will be assigned to that commit / branch but with the latest code

   git reset - - hard hash-id —> You revisit the old branch but here all the code you have wriitten after that commit will be removed along with any unstaged changes (very harmful).

And that’s how you backtrack to any version of the code safely soundly.

This was a simple overview of what i understood git was and how it is used as beginner and how can we handle the code collaboration such that our Todo repository doesn’t get any bugs or conflict