So, What is Git?

Git is a Source Control (sometimes it is also called Version Control). Source control is the process/practice of tracking and managing changes to software code. Source control is specifically for source code, whereas Version control is for versioning all types of data, not just for source code, ex:- versioning images, documents, binary data etc. For better understanding check this BitBucket tutorial.

Another explanation from AWS "Git is an open-source distributed source code management system. Git allows you to create a copy of your repository known as a branch. Using this branch, you can then work on your code independently from the stable version of your codebase. Once you are ready with your changes, you can store them as a set of differences, known as a commit. You can pull in commits from other contributors to your repository, push your commits to others, and merge your commits back into the main version of the repository".

The whole concept of version control is to let multiple developers work on a single project. So there is a git central system (git remote repository ex:- github, gitlab, etc) where the project source is stored. And each developer will move their code from their local computer to the remote git repository (git server) and also pull code pushed by other developers from remote repository to their computers.

Git System Architecture

This is the most important step in understanding git.

Most of the other version controls before Git worked as follows.

As a developer you will write code using code editors like Notepad, Eclipse, etc., save those files (.js .py .java .html etc., files) in your local computer and then move those to the remote source server. This is true for git as well but there are a couple more steps with git.

‌Unlike other version control systems Git structures data into 4 areas, the first 3 of these are on your local computer and the last "Remote Repository" resides in the remote server.

Working Directory ---> Staging(or Index) ---> Local Repository =============> Remote Repository

​

To visualize, you can think of these as 3 different folders. Working Directory is the only thing which is accessible to edit with your editors like Visual Studio Code or notepad etc. Staging (also called Index) is another folder and 'Local Repository' is yet another folder (Staging and 'Local Repository' are hidden).

Now lets say you implemented a new feature called 'image compress' and for this new feature you created/modified two files, lets say these files are ImageComp.java, Util.java. To send your code to remote git reposity you need to do the following.

Step -1: You will select these two files and add it to staging area.

# And this is how you to add ImageComp.java, Util.java files to 'Staging Area'
​
git add ImageComp.java Util.java

Step-2: Then you move your code from Staging Area to the Local Repository (Remember you are moving your code to the to the local repository not to the remote repository).

And while you are moving your code to the local repository you can write a note about the changes. For example for the above commit you can say "code for image compression". Later when you are looking at git history and try to understand what these commits are for, this commit label helps you and other devs to quickly understand these changes. It's a good practice to give a brief and high level description for each commit.

# This is how you move your code from 'Staging Area' to your own 'Local Repository'
# Note:- This command not moving your code to remote git repository.
​
git commit -m "code for image compression"

With this commit action both of these files are grouped together and given a label called 'code for image compression'.

Step-3: Once you label your code changes and add it to the Local Repository now is the step to move that commit to the Remote Git Repository.

# This is how you push your local code (commit) to the remote git repository
​
git push origin master