What is the Difference between Git and GitHub?
Git is a free and open distributed version control system, a tool to manage your source code history.
GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.
In short, Git is the tool, and GitHub is the service for projects that use Git.
The first thing you need to do is install Git on your Machine.
$ sudo apt-get install git
Download and install Git for Windows.
Create a GitHub Account
Create a free GitHub.com account.
Step 1: Create a local git repository
A repository (or often, ‘repo’, for short) is the Git version of a project folder. Git will track any changes inside of a repository.
Start by creating a directory on your machine and cd into the directory you created.
$ mkdir myProject
$ cd myProject
Set up name and email in Git config
$ git config --global user.name "Your Name Here"$ git config --global user.email "firstname.lastname@example.org"
Check your Git config using
git config --list command
$ git config --list
You can initialize a Git repository in the root of the folder by running
$ git init
The 3 States of Git
Files in a repository go through three stages before being under version control with git:
- 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.
In addition to these three states, Git files live in one of three areas: the Working directory, Staging area, and the Git directory (aka your local repository).
The manipulation among all the above states occurs locally, meaning that the changes affect no one else’s current repository but yours.
The basic Git workflow goes something like this:
- Working directory/tree: The current version of your project where you are making changes (which is reflected in your code editor)
- Staging Area(aka Index): The place where you stage your files when you are preparing them to commit
- Repository: When you commit, Git permanently saves only the changes from your staging area to the repo’s memory
If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified.
Step 2: Add a new file to the repo
Create a new file in your myProject directory named
$ touch hello.txt
The file is now in the directory, but Git won’t officially keep track of the changes of the new file unless you explicitly tell it to.
Check the status of your repo with
git status command
$ git status
Step 3: Add a file to the Staging area
We can add a file to the staging area using
git add command
$ git add hello.txt
Once a file is in the Staging area, you can unstage the file / untrack it using the
git rm --cached <file_name> command
$ git rm --cached hello.txt
The file is now returned back to the Working directory. So use the command
git addto add the file back to the staging area so that we can commit.
Step 4: Create a commit
Once you have one or more changes to the staging area, you can commit them with a message using
$ git commit -m 'adds the hello.txt'
saved changes are called commits. Each commit has an associated commit message, which is a description explaining why a particular change was made. Commit messages capture the history of your changes, so other contributors can understand what you’ve done and why.
Committing cleans the status of the staging area:
Committing also permanently stores the edit you made into a record store, which you can see by typing
git log command:
Your most recent commit is called the HEAD