First Step towards Git and Github

Introduction

In the simple term , Git is software you install on your computer to interact with Git repositories and GitHub is a very popular website (and free to use), which is used to host GitHub repositories.

Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Let’s understand what is Version Control System.

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.

Daily life example: Imagine that your boss gave you a task to write an article on the paper in one hour. You are sure that you will finish perfectly but as we ,are human there are always possibilities, to make mistakes. After one hour, you just realized that made a mistake. Oh, no! Was there a way to fix it?

In real life, you can take precautions on time to avoid unwanted situations or if something has really happened before prevention, simply means that it happened. So, we cannot change things occurred in past in actual life. Fortunately, version control systems help us to go back in time without a magic wand. Besides, it has more benefits than undo steps. Let’s learn more.

Before understanding distributed version control system , let’s take a look at types of Version Control System.

There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.

• Centralized Version Control System
• Distributed Version Control System

Centralized Version Control System(CVCS)

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Drawbacks of CVCS

• It is not locally available, which means we must connect to the network to perform operations.
• During the operations, if the central server gets crashed, there is a high chance of losing the data.
• For every command, CVCS connects the central server which impacts speed of operation

​The Distributed Version Control System is developed to overcome all these issues.

Distributed Version Control System(DVCS)

In distributed version control most of the mechanism or model applies the same as centralized. The only major difference you will find here is, instead of one single repository which is the server, here every single developer or client has their own server and they will have a copy of the entire history or version of the code and all of its branches in their local server or machine. Basically, every client or user can work locally and disconnected which is more convenient than centralized source control and that’s why it is called distributed.

It doesn’t follow the way of communicating or merging the code straight forward to the master repository after making changes. Firstly you commit all the changes in your own server or repository and then the ‘set of changes’ will merge to the master repository.

Some Basic Commands to use GIT

Getting a Git Repository

There are two ways to obtain a Git repository :

1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or
2. You can clone an existing Git repository from elsewhere.

In either case, you end up with a Git repository on your local machine, ready for work.

Initializing a Repository in an Existing Directory

To create a new repo, you’ll use the git init command. git init is a one-time command you use during the initial setup of a new repo. Executing this command will create a new .git subdirectory in your current working directory. This will also create a new main branch.

$ git init

Cloning an Existing Repository

If a project has already been set up in a central repository, the clone command is the most common way for users to obtain a local development clone. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control operations are managed through their local repository.

$ git clone <repo url>

Recording Changes to the Repository

Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.

Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven’t edited anything.

As you edit files, Git sees them as modified, because you’ve changed them since your last commit. As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.

Checking the Status of Your Files

The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

This means you have a clean working directory; in other words, none of your tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on.

Saving changes

• git add
• git commit
• git diff
• git stash

git add

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.

$ git add <file> 
// Stage all changes in <file> for the next commit.
$ git add <directory>
// Stage all changes in <directory> for the next commit.

git commit

The git commit command captures a snapshot of the project's currently staged changes. Committed snapshots can be thought of as “safe” versions of a project—Git will never change them unless you explicitly ask it to. Prior to the execution of git commit, The git add command is used to promote or 'stage' changes to the project that will be stored in a commit.

$ git commit -m "commit message"

git diff

git status command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the git diff command. You’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although git status answers those questions very generally by listing the file names, git diff shows you the exact lines added and removed — the patch, as it were.

To see what you’ve changed but not yet staged, type git diff with no other arguments:

$ git diff

That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.

You can use git diff --staged. This command compares your staged changes to your last commit:

$ git diff --staged

git stash

Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.

Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch).

$ git stash
Saved working directory and index state \
  "WIP on master: 049d078 Create index file"
HEAD is now at 049d078 Create index file
(To restore them type "git stash apply")

You can reapply the one you just stashed by using the command : git stash apply

$ git stash apply
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   index.html
	modified:   lib/simplegit.rb

no changes added to commit (use "git add" and/or "git commit -a")

Thank you, for reading this post , hope you liked it please give an applause.