Installing
Git on Windows is very easy. The msysGit project has one of the easier
installation procedures. Simply download the installer exe file from the GitHub
page, and run it:
To
download GIT click here
After
it’s installed, you have both a command-line version (including an SSH client
that will come in handy later) and the standard GUI.
The
GuI version is more user friendly and easy to use but there are so many
features missing in the GUI version. So it is more useful to use the command
line version of GIT which is called GIT bash.
Working
with GIT
The Three States
Now, pay attention.
This is the main thing to remember about Git if you want the rest of your
learning process to go smoothly. 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 directory,
and the staging area.
Figure 1-6. Working directory, staging area, and git directory.
The Git directory is
where Git stores the metadata and object database for your project. This is the
most important part of Git, and it is what is copied when you clone a
repository from another computer.
The working directory
is a single checkout of one version of the project. These files are pulled out
of the compressed database in the Git directory and placed on disk for you to
use or modify.
The staging area is a
simple file, generally contained in your Git directory, that stores information
about what will go into your next commit. It’s sometimes referred to as the
index, but it’s becoming standard to refer to it as the staging area.
The basic Git workflow goes something like
this:
1.
You modify files in your working directory.
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.
If a particular
version of a file is in the git directory, it’s considered committed. If it’s
modified but has been 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. In
Chapter 2, you’ll learn more about these states and how you can either take
advantage of them or skip the staged part entirely.
Go
to git bash then you will get a command window the common commands for using is
given below.
2.MAIN
GIT COMMANDS
1.git clone location
Using this command we can clone the date from the server.
Here in the command instead of location put the actual path of the date you
want to clone from server
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. If you’re familiar with other VCS systems such as
Subversion, you’ll notice that the command is clone and not checkout. This is an important distinction — Git receives a copy of
nearly all data that the server has. Every version of every file for the
history of the project is pulled down when you run git clone. In fact, if your server disk gets corrupted, you can use
any of the clones on any client to set the server back to the state it was in
when it was cloned (you may lose some server-side hooks and such, but all the
versioned data would be there
2.git status
After doing all the editing we have to know
the changes happened to our file with respect to cloned version for this we can
use this command. This will show the changes happened in the edited file.
Displays paths that
have differences between the index file and the current HEAD commit, paths that
have differences between the working tree and the index file, and paths in the
working tree that are not tracked by git (and are not ignored by gitignore(5)). The first
are what you would commit by running git
commit; the second and third are what you could commit by running git add before running git
commit.
3.git add
This command updates the index using
the current content found in the working tree, to prepare the content staged
for the next commit. It typically adds the current content of existing paths as
a whole, but with some options it can also be used to add content with only
part of the changes made to the working tree files applied, or remove paths
that do not exist in the working tree anymore.
The
"index" holds a snapshot of the content of the working tree, and it
is this snapshot that is taken as the contents of the next commit. Thus after
making any changes to the working directory, and before running the commit
command, you must use the add command to add any new or modified
files to the index.
This
command can be performed multiple times before a commit. It only adds the
content of the specified file(s) at the time the add command is run; if you
want subsequent changes included in the next commit, then you must run git add again to add the new content to the
index.
The git
status command can be
used to obtain a summary of which files have changes that are staged for the
next commit.
The git add command will not add ignored files by
default. If any ignored files were explicitly specified on the command line, git add will fail with a list of ignored
files. Ignored files reached by directory recursion or filename globbing performed
by Git (quote your globs before the shell) will be silently ignored. The git add command can be used to add ignored
files with the -f(force)
option.
4.git commit –m ”comments”
Stores the current contents of the
index in a new commit along with a log message from the user describing the
changes. Comments is given to identify the changes done in the data.
The
content to be added can be specified in several ways:
1.
by using git
add to incrementally
"add" changes to the index before using the commit command (Note: even modified files
must be "added");
2.
by using git
rm to remove files from the
working tree and the index, again before using the commit command;
3.
by listing files as arguments to the commit command, in which case the commit will
ignore changes staged in the index, and instead record the current content of the
listed files (which must already be known to git);
4.
by using the -a switch with the commit command to automatically
"add" changes from all known files (i.e. all files that are already
listed in the index) and to automatically "rm" files in the index that
have been removed from the working tree, and then perform the actual commit;
5.
by using the --interactive or --patch switches with the commit command to decide one by one which
files or hunks should be part of the commit, before finalizing the operation. See
the “Interactive Mode” section of git-add(1) to learn how to operate these modes.
The --dry-run option can be used to obtain a summary
of what is included by any of the above for the next commit by giving the same
set of parameters (options and paths).
If you
make a commit and then find a mistake immediately after that, you can recover
from it with git reset.
5.git push orgin
This command is used to push the edited data
to the server. This will make our work complete. On doing this the server data
is updated with our edited data.
Updates remote refs using local
refs, while sending objects necessary to complete the given refs.
You can
make interesting things happen to a repository every time you push into it, by
setting up hooks there. See documentation for git-receive-pack(1).
6.git pull orgin
Once you clone the server data you don’t need
to do it again all you have to do is excicute the above command. This will pull
the data in the server to your directory.
7.git push orgin
Git push command will push our updated data to the server
this will update the server data by adding the changes.
Updates
remote refs using local refs, while sending objects necessary to complete the
given refs.
You can
make interesting things happen to a repository every time you push into it, by
setting up hooks there. See documentation for git-receive-pack(1).
3.WORKING
WITH A DIRECTORY
Working as branches is a wonderful feature
provided by GIT. In this feature we can create branches. Then we will check out
(login) to a certain branch then we can do changes in the data and this changes
will not affect the data in another branch. To merge changes in different
branches use merge command.
1.git branch name1
This command is used to create a new branch. Here
name1 will be the name of the created branch.
2.git check out name1
This command is used to login to the new
branch. Here after executing this command the git will select name1 as the
selected branch.
3.git check out master
This
command is used to login to the master branch. Master branch is the default
branch. If don’t create any branch the changes will be done via this master
branch.
5.git merge name1
This
command is used to merge two branches. After executing this command the git
merge the name1 branch with the selected branch.
6.git checkout –b ‘name2’
This
command is used to simultaneously create and login to the branch name2.
4.CREATING A GIT REPOSITORY
A
GIT repository is where the original data is stored from where we clone it and
make changes. In this session we are going to create a new repository in a
local system.
1.select
path
By using cd command we select the path where we need to make the repository.
2. git init location
This
is the git initialize command. By executing this command the location will
become a repository.
3.git add.
Same
as described above.
3.git commit
Same
as described above.
4.git clone -- bare location
This
will make a bare clone of repository in the described location. Now this bare
clone data will be given to the local systems when they execute clone command.
Some Useful commands in git
- To delete a local branch: git branch -d Branch_Name
- To get a remote branch in local clone repository: git checkout origin/Repo_BranchName