Header Ads


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.
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).

                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.

            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

Powered by Blogger.