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.
image
image
Git uses a distributed model
image
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
Modified
Staged
Committed
image
File Status Lifecycle
image
Remote repositories and local repositories
There are two types of Git repositories namely a Remote repository and a Local repository.
- Remote repository: Repository that resides on a remote server that is shared among multiple team members.
- 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.
image
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.
or
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.
Syncing
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>
