GIT'ting Up: Ground Zero

All this time I've been avoiding Git-CLI and trying to work it out from GitHub, looks like I can't limit myself if I'm learning, learning Git and GitHub is the need of the hour for me, probably to anyone getting into tech, the need has reached its peak and I can't delay it anymore.

So let's do this one more time, yet another article on GIT but this time it's my gist, and I want it to be the resource that I can refer to, so I'll do my best and make it a good one.

starting with the obvious

What is GIT?

• Well, It's Distributed Version Control System(VCS) for your project/files, that's not helpful, let's break it down

What is a Version Control System(VCS)?

• Let's start with an analogy, you have a project and added some changes to it to make the project better, and doesn't seem to work the way you thought it should, VCS lets compare the changes you've made so that you can navigate through the changes and see where it went off the road

• Now you have a new idea for the project and you want to change the project design and start building from a specific version, it lets revert back to its previous or any specific state/version, hence the name version control system maintaining versions of your project, like who, what and when the changes are made

• It allows us to do a lot more tasks, there's much more to it and we aren't well-versed with this jargon, so we'll figure out along the way

Why do we need a Version Control System?

• Maintaining versions of a large project manually, we can't, it's error-prone and practically impossible because there'll be many folks working on it, and a project with a wide user base, it's most probable it has many files filled with features serving users

• So developers did what they do best, develop a VCS software

• It started with a simple idea that there is a database storing all the changes made to the project on your local machine, and the current version of the project, known as LOCAL VCS

• But it didn't solve the major issue, except for the individual projects, whenever there's an application being developed there are teams of developers working on different aspects of the project, and we need to work together to keep ourselves up to date about it, which wasn't possible using a LOCAL VCS

• And then comes into the picture Centralized VCS

• Now all the files of the project reside in a remote server that the developers working on it can access, they can make changes to the project and send(push) them to the server and the rest of the team can receive(pull) them

• This design had flaws too, there was a single point of failure if anything happened to the server, that centralized server could have been literally a server or a personal computer, it might be the electricity and the server is down, or a hardware failure(storage) which is dreadful, and none of them could access the application

  again developers being developers and we have a new solution for this i.e Distributed VCS(DVCS)

• This time when the developers are cloning the project in their local system, instead of one version of the project they get the entire history of that project, and if a new version is made and it is pushed to that server and stored in it

• If there is another developer working on it, when they clone the project on their local system they get the updated version

• So this time even if there's a hardware failure, there is no loss of data, and the team would still have data in their local system with the entire history, all the changes that ever existed of the project, making every clone a backup for it.

How Git happened?

• Up until 2002, updates of the Linux kernel were released as archives, and then they started using BitKeeper(owned by a commercial company) a distributed VCS

• Around 2005, the Linux community and BitKeeper had a fallout, they revoked their free-of-charge services which prompted the community which created the Linux kernel to create the distributed VCS of their own, solving those issues they had encountered with their previous DVCS, with a keen emphasis on

1. Speed
2. Simple Design
3. Support for Non-linear Development
4. Fully distributed

5. Efficiency with large projects

6. Hence Git was born

How's Git different from other VCSs?

1 . Snapshots

• here's what other VCSs do

• What Git does here is that it maintains snapshots of the project's file system, like taking pictures of the whole project's file system whenever a change is made, instead of listing down the changes made to the files from the base file

• A snapshot for each change shows what and how the contents of this project look like with a reference to it

• Don't have to understand all the contents of the above picture it's just a reference, we'll figure out as we go

2 . Nearly Every Operation Is Local

• We've already seen how DVCS works, Git allows us to the entire history of the project in our local system, so performing operations is instantaneous, like comparing the present changes with previous changes it can be any, and one can do it while being offline expect for pulling the projects and pushing the changes where we need interact with the remote server, this is the speed feature we were talking about

3 . Integrity

• Git knows about every change you make to the directory whether you're modifying a file, adding a new file, or deleting a file

• It is because everything in Git is checksummed, and due to that you don't lose any data (while uploading or retrieving)

• Git uses the SHA-1 mechanism for checksumming, to make up a 40-character string composed of Hexadecimal and it is calculated based on contents of the file or directory structure, It stores everything in its database

4 . It only adds generally

• It's hard to erase data from the database, if you remove a file you can still revert back, it keeps tabs on everything you've done with your project directory, and you can't lose your data once you've committed it to Git, making Git more reliable than other VCSs

• Hence it is the most widely used Distributed VCS

Three Stages of with Git initialized directory

• The files in your git directory can be in a modified state, staged state, and a committed state

1 . Modified State

• We know that Git maintains(like a database) a history of snapshots of the changes made to the directory

• Now modified is a state where the changes have been made but not committed to the local git database

2 . Staged State

• Let's say you have 3 files in your project's directory and you made the changes to all of them but you only want to reflect the changes in two of them and you don't want the other file to reflect the changes in git's database yet, so you stage the two files like marking them for the next commit, and you will have a snapshot of it, while the other is still in the modified state

• So staging is marking a modified file in its current state to go into the database in the next commit, and reflecting it as a snapshot

3 . Committed State

• The data is safely saved in the local git database

Three Sections of a Git Project

• From the .git repository you can go to the working tree of any version that you want, it maintains the working tree of all the versions of the project, and you can check out any version you want to, see how your project was looking like at that point like what were contents of it

1 . Working Tree

• It is a single checkout of any version of the project

2 . Staging Area

• It is a file located in the .git directory containing information about what changes will go in your next commit

3 . Git(.git) Directory

• Stores metadata of the snapshots for different versions of your project

Git Workflow

• You can simply check out any of the snapshots for any version and it'll become your working tree, and in that, you can modify the data, you can selectively choose the files that you want to commit into the git database wherever you make the next commit, send it into the staging area which is stored in your .git directory and commit those changes to reflect in your git database

Install Git for any Operating System

• check the version of the git using the git --version command, the output should be something like this git version 2.38.1

Git Hands-On

• Let's make a directory and initialize a git project and create a README.md file, .md extension is known as markdown

• You can either use gedit or vim, if you're using vim here are a few commands that'll help you,

i - entering the insert mode and adding text
ESC - to exit from insert/editing mode
:w - to save the changes
:q - to quit the editor
:wq - to write and quit
:wq! - to override the changes and quit

• Use git init to initialize the git

• You can see the .git directory, it's what we talked about earlier, .git is the folder where all the metadata about the project will be stored, the git init created .git directory for you

• execute git status, it shows the current state of the working tree, where files are yet to be in the staged area

• for it to be in the staged area, as it's shown you have to execute the git add <filename>

• You created a new file previously, hence new file: README.md

• You are working with two files here, it's better not to add file each time whenever you execute git add, so the better one here is git add . it adds all the files to the staged area

• Let's unstage names.txt file and commit the README.md file, we'll be working on large projects and collaborating with people it's important to add a meaningful message so that folks can understand what you did on that commit

• git commit -m "<message>" is the command for it, after committing the changes, No commits yet isn't visible anymore

• Edit the README.md file

• As you can see README.md is modified, you can commit the changes or you can revert them to their previous state using the git restore <filename> command

• Let's not do that and make sure that there are no errors with the changes made to that file, using git diff <filename> which shows what it was and what it is now, based on that you can decide it whether you want to proceed with committing or restoring it

• Let's proceed with committing the changes

• As of now, you're performing all the operations from your local system, as we discussed earlier that Git is a distributed version control system, so a friend of yours also wants to practice git, by adding their name as well to the README.md and names.txt, so let's move the local repository to a remote server, this is where GitHub comes into the picture

Creating a GitHub repository

• GitHub serves as a hosting platform for many folks globally, let's add the local repository

switch to GitHub and If you don't have an account signup for it

• After signing up go through Setting Git Config and Authentication section, because you'll need your username and password to be configured before you proceed further, you can find this section in the Table of Contents

• Now from your profile dropdown, click on your repositories and click on the new option, give the same name as it is in your local system and click on new repository, you don't have to choose the add readme option because we already we have it

• In your case, you're pushing existing files to the repository, so copy the commands regarding that, we'll understand those commands as move forward, and change the branch accordingly, if it's master put that in place of main

• And you have successfully created a repository, refresh the page and you should see something similar to this

• Click on the commits right below the code button, to see the commits you've made, click on the first commit and where you'll find browse files button, click on that, and now you'll be on the working tree of that commit

• GitHub gives you a good representation of your working trees with a nice user-interface

• Now let's delete this repository and do it again using GitHub GUI, click on settings of the repository, scroll down to the end, and delete it.

• Go through the process again, when you get to quick setup step click on creating a new file and name the file as README.md and fill it with contents of your choice, and commit the changes

• So, yes it's what I've been doing all along avoiding Git-CLI, you get a good amount of work done from GitHub, especially while working on documentation, for working on large projects with a large codebase you'll eventually opt for Git-CLI

• Now let's work on this by cloning this repository on your local machine, first, we have to remove the existing directory with the same name rm -rvf <filename>

• Get back to the repository, click on the code button and copy the HTTPS link and clone it in your local system

• GitHub enabled people around the world to collaborate on a project and work together, let's assume someone surfing through GitHub found this repo and felt this is a good initiative and wanted to experience the GUI, so they added their name as well and made a request to reflect their changes as well which are called as pull requests which will talk about later on very soon, there's a pen icon on every file which allows us to edit and commit the changes

• Now with Git you can keep your local repository up to date by pulling the changes made to the remote repository using the git pull command

• You got yourself an upgrade, you made a homepage for yourself and you want to update the README.md file with a link to it, let's do that

• Now execute git status and git diff README.md

• Let's commit the changes to the repo, you did it to the local repo but you want to push it to the remote repository so that it's available globally using git push

• Now the changes are visible on the GitHub

Setting Git Config and Authentication

• As you can see every time I pulled and pushed the changes I filled in the username and password section, your regular GitHub password won't work, you need a personal access token, it only takes that as a password, go to your GitHub account settings and navigate to developers settings

• Click on generate a new token, take time and read the permissions documentation, and generate your token

• Setting global config is like letting git know that your system is the owner of the changes you're going to make to the remote repo's so that it doesn't ask for username and password anymore

• Let's setup the configuration for username and email-id, authentication as well

• But it'll still ask after you restart your machine, you can use git config credential.helper store to store permanently or git config credential.helper cache to store them temporarily

We've made it buddy, congratulations, I hope now you won't be lost whenever you're dealing with git operations, there'll be another blog coming up soon, we still have a lot more to learn, like pull requests, how git branches work, and more, thanks for staying till the end, Keep working hard and Happy Learning

This is the course I followed while writing this blog Git and GitHub Masterclass by Apoorv Goyal