What is Git ?

Git is a distributed version control system originally developed to manage Linux source codes.
Git is designed to help coordinate large, distributed group projects
Git provides a modern toolset
Fast command line utilities
Highly interactive graphical tools web viewers
Dedicated hosting sites (github, gitorious…)

Introduction to Version Control

Version control (or revision control, or source control) is all about managing multiple versions of documents, programs, web sites, etc.

Why You Should be Using Version Control:

The code programmers write changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and the code is changed by editing these files. If you make a change to a file, save it, compile it, and find out that something went wrong, it’s often helpful to be able to go back to the old version or to get a report of what was actually changed, in order to focus on what may have gone wrong.
That’s where Version Control Systems come in.

How Git stores data?

Git store its data like a set of snapshots of a miniature file system as opposed to other systems, which store information as a list of file-based changes.



Git uses a distributed model


Basic Workflow of Git

Possible init or clone of repository
Edit files
Stage the changes
Review your changes
Commit the changes

A Local Git project has three areas





File Status Lifecycle


Remote repositories and local repositories

There are two types of Git repositories namely a Remote repository and a Local repository.

  1. Remote repository:  Repository that resides on a remote server that is shared among multiple team members.
  2. Local repository:  Repository that resides on a local machine of an individual user.You can use all of Git’s version control features on your local repository such as reverting changes, tracking changes, etc. However, when it comes to sharing your changes or pulling changes from your team members, that is where a remote repository comes in handy.


Creating a repository

There are two ways to create a local repository on your local machine.
You can either create a brand new repository from scratch or by cloning an existing remote repository onto your local machine.


git init

The git init command creates a new Git repository. This creates a new sub directory named .git that contains all of your necessary repository files – a Git repository skeleton. At this point, nothing in your project is tracked yet.

Cloning an Existing Repository

If you want to get a copy of an existing Git repository – for example, a project you’d like to contribute to – the command you need is git clone
Every version of every file for the history of the project is pulled down by default when you run git clone
You clone a repository with git clone [url] [dir](optional). For example, if you want to clone the Git linkable library called libgit2, you can do so like this:

git clone https://github.com/libgit2/libgit2 mylibgit

That creates a directory named “mylibgit”, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version

git config

This command can define everything from user info to preferences to the behavior of a repository.
Several common configuration options are listed below:

Set the name and email for Git to use when you commit:

git config --global user.name “array151”
git config --global user.email array151@gmail.com

You can call git config –list to verify these are set.

These will be set globally for all Git projects you work with.
You can also set variables on a project-only basis by not using the
–global flag

Add and Commit

If you want to start version-controlling existing files, you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a git commit:

git add *.c
git add LICENSE
git commit -m 'initial project version'

The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn’t really affect the repository in any significant way—changes are not actually recorded until you run git commit.

 The “commit” operation enables you to record changes that were made to a file or directory in the Git history.

Undoing Changes

git checkout

The git checkout command serves three distinct functions: checking out files, checking out commits, and checking out branches.

git checkout <commit> <file>

Check out a previous version of a file. This turns the <file> that resides in the working directory into an exact copy of the one from <commit> and adds it to the staging area.

git checkout <commit>

Update all files in the working directory to match the specified commit. You can use either a commit hash or a tag as the <commit> argument.

git checkout master

Return to the master branch.

git revert

The git revert command undoes a committed snapshot. But, instead of removing the commit from the project history, it figures out how to undo the changes introduced by the commit and appends a new commit with the resulting content.

git revert <commit>

Generate a new commit that undoes all of the changes introduced in <commit>, then apply it to the current branch.

Reverting vs. Resetting

It’s important to understand that git revert undoes a single commit—it does not “revert” back to the previous state of a project by removing all subsequent commits. In Git, this is actually called a reset, not a revert.

git reset

If git revert is a “safe” way to undo changes, you can think of git reset as the dangerous method. When you undo with git reset, there is no way to retrieve the original copy—it is a permanent undo. Care must be taken, as it’s one of the only Git commands that has the potential to lose your work.

git reset <file>

Remove the specified file from the staging area, but leave the working directory unchanged. This unstages a file without overwriting any changes.

git reset <commit>

Move the current branch tip backward to <commit>, reset the staging area to match, but leave the working directory alone. All changes made since <commit> will reside in the working directory, which lets you re-commit the project history using cleaner, more atomic snapshots.

git reset

Reset the staging area to match the most recent commit.

git clean

The git clean command removes untracked files from your working directory. This is really more of a convenience command, since it’s trivial to see which files are untracked with git status and remove them manually. Like an ordinary rm command, git clean is not undoable, so make sure you really want to delete the untracked files before you run it.

git clean -n

Perform a “dry run” of git clean. This will show you which files are going to be removed without actually doing it.

git clean -f

Remove untracked files from the current directory.

git clean -f <path>

Remove untracked files, but limit the operation to the specified path.

git clean -df

Remove untracked files & untracked directories from current directory.


git remote

The git remote command lets you create, view, and delete connections to other repositories.

git remote

List the remote connections you have to other repositories.

git remote add <name> <url>

Create a new connection to a remote repository. After adding a remote, you’ll be able to use <name> as a convenient shortcut for <url> in other Git commands.

git remote rm <name>

Remove the connection to the remote repository called <name>


Leave Comment

Your email address will not be published. Required fields are marked *