Git is a version management system that saves changes to a file or collection of files over time so that particular versions may be recalled later. It lets you restore files to a prior state, check who last updated anything that could be creating a problem, return the entire project to a previous state, compare changes over time,who presented an issue and when, and much more. So, without further ado, let’s Git it (pun intended).

Git snapshots

Most other systems save information as a list of file-based modifications.
These systems think of the data they store as a collection of files and the changes made to each file over time. Git considers its data to be more like to a series of snapshots of a small file system. When you commit or save the state of your project in Git, it simply takes a snapshot of what all your files look like at that time and saves a reference to that snapshot. This enables Git to function more like a mini-file system, with some strong tools added on top.

Three states

Your files can be in one of three states in Git: committed, modified, and staged. Modified states that you have changed the file but are yet to commit. Staged means you have marked a modified file in its current version to go into your next commit. Committed means that the data is stored in your local database

These three states have corresponding sections in Git : the Git directory, the working directory, and the staging area. The Git directory is where Git stores the object database and metadata for your project. It gets copied when you clone a repository from another computer. The working directory contains a single checkout of the project’s current version.
These files are extracted from the Git directory’s compressed database and saved to disk for you to use or change. The staging area is a file that is typically located in your Git directory and holds information about what will be included in your next commit. It is occasionally referred to as the β€œindex”.

Most used commands

git init

git init command will initialize a repository in an existing directory.

git init

This creates a new sub directory named .git that contains all of your necessary repository files. Cool Innit?(unnecessary pun). This won’t start tracking your files though. You can start tracking your files with add command.

git add

You use git add to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as β€œadd this content to the next commit”

//adds all files in the current directory
git add .
//only adds README.md file
git add README.md

git status

This command will tell you which files are in which state. You will use this to answer two questions : What have you altered but haven’t staged yet?
And what are you about to commit to that you have staged?

git status

This commands output is a bit too wordy at times. For compact outputs for git status you can add -s flag.

git status -s

git diff
git diff is more detailed than git status command. It will tell you what exactly you changed, not just which files were changed. This command compares what is in your working directory with what is in your staging area.

git diff

If you want to see what you’ve staged that will go into your next commit, you can use the staged flag

git diff --staged

Note that if you’ve staged all of your changes, git diff will give you no output.

git commit

This saves the snapshot you created in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you commit, you’re taking a snapshot of your project that you can subsequently rollback to or compare to.

git commit -m "Your commit message"

m flag lets you add message to your commit which can help you differentiate between commits and know the reason for that commit. After you commit, it outputs which branch you committed to, what SHA-1 checksum the commit has (everything in Git is check-summed before it is stored and is then referred to by that checksum), how many files were changed, and statistics about lines added and removed in the commit.

git clone

This will allow you to get a copy of an existing Git repository. Git receives a complete copy of almost all data on the server. When you run git clone, it downloads every version of every file in the project’s history.

git clone repo_url

git log

git log will print commit history made in that repository in reverse order where most recent commits show up first. It lists each commit with its SHA-1 checksum, the author’s name and email, the date written, and the commit message.

git log

Undoing git commit

If you commit and you realize you forgot to add some files, git has got you covered. You can run commit with amend flag

git commit --amend

This command takes your staging area and uses it for the commit. If you’ve made no changes since your last commit your snapshot will look same.

Adding remotes

Remote repositories are versions of your project that are hosted on the Internet. When you need to share work with others, you must manage these remote repositories and push and pull data to and from them.

To add a remote Git repository you can use following command

git remote add origin repo_url

Here origin is basically an alias you give to this remote repo. Every time you use the keyword origin, git will know you are talking about this remote repository. You can choose any name instead of origin.

To get list of all remotes Git has stored you can use the v flag

git remote -v

Pushing to a remote repository

When you have your project at a point that you want to share, you have to push it to the remote repository.

git push origin master

If you want to push specific local branch to specific remote branch then you can use the following :

git push [remote-name] [branch-name]

Hopefully, this was a useful introduction to Git principles that will aid you when you explore further Git related topics like branching, Git tools, and Github. Until the next time 🌸.

--

--