Introduction to git — My everyday git flow Part -1

What is “version control”, “git” and why should you care?

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development, but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed, data integrity, and support for distributed, non-linear workflows.

Git was created by Linus Torvalds in 2005 for development of the Linux kernel .

The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.

Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area.

The basic Git workflow goes something like this:

  1. You modify files in your working tree.
  2. You stage the files, adding snapshots of them to your staging area.
  3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

** Source -

Getting started with git -

Please follow this link to install and setup git on various OS-

git Terminology -

repo: A place where the history of your work/code is stored
clone: Copy a git repository so you can add to it
fork (GitHub): Create your own server side copy of someone else’s repo
commit: A state of your project at a certain time
branch: A different line of development. A branch is just a “label” which points to a specific commit
master: The default branch we develop in
origin: The default upstream repo (Github)
HEAD: The current branch
remote: A repository stored on another computer

Simple workflow I follow for my Github / Gitlab projects-

  • Clone the main repo git clone https://sample-repo.git
  • Create a new local branch git checkout -b my-branch
  • Add changed files git add example.html
  • Work in that branch git commit -m "some work done"
  • Pull the latest code from master git pull origin master
  • Push up the branch git push -u origin my-branch
  • Create a Pull request

Bonus : Other great resources to learn and master git —

Please share this article with your friends who want to learn git and leave you comments telling me what you like and dislike about git.

Hope you have a good time leaning git.

Please checkout the Part 2 for a cool cheatsheet I use everyday.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.