Pro Git - Chapter 2

Chapter 2

Git Basics

Getting a Git Repository

Initializing a Repository in an Existing Directory

Go to the project’s top directory and type

$ git init

This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton.

To start version-controlling existing files,specify the files you want to track, followed by a commit:

$ git add *.c
$ git add README
$ git commit -m 'initial project version'

Cloning an Existing Repository

If you want to get a copy of an existing Git repository, the command you need is git clone.

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. 

 You clone a repository with git clone [url].

 If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option: git clone [url] [new_dir]

Recording Changes to the Repository

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; they can be unmodified, modified, or staged. 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.

 

Checking the Status of Your Files

The main tool you use to determine which files are in which state is the git status command.

$ git status

Tracking New Files

 In order to begin tracking a new file, you use the command git add (files/directory). File/directory are now tracked and staged.

Staging Modified Files

If you change a previously tracked file and want to stage it, you run the git add command (it’s a multipurpose command - you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved).

Ignoring Files

 You can create a file listing patterns to match them named .gitignore.

Viewing Your Staged and Unstaged Changes

  What have you changed but not yet staged? git status answers those questions very generally.

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

  If you want to see what you’ve staged that will go into your next commit, you can use git diff --cached. (In Git versions 1.6.1 and later, you can also use git diff --staged, which may be easier to remember.)

Committing Your Changes

$ git commit

  Doing so launches your editor of choice for you to write some comments about this change.

Alternatively, you can type your commit message inline with the commit command by specifying it after a -m flag

$ git commit -m "Story 182: Fix benchmarks for speed"

 You can see that the commit has given you some output about itself:

which branch you committed to

what SHA-1 checksum the commit has

how many files were changed

statistics about lines added and removed in the commit

Skipping the Staging Area

If you want to skip the staging area, Git provides a simple shortcut. Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part.

Removing Files

Case#1 To keep the file on your hard drive but not have Git track it anymore.

$ git rm --cached <files, directories, and file-glob patterns>

case#2 To remove a file from Git and emoves the file from your working directory

$ git rm <files, directories, and file-glob patterns>

Moving Files

$ git mv file_from file_to

Alternatively, You can use any tool you like to rename a file  then usethe following commands before you commit:

git rm 

git add

Viewing the Commit History

The most basic and powerful tool to do this is the git log command. A huge number and variety of options to the git log command are available to show you exactly what you’re looking for.

•  Show the patch(diff) introduced in each commit

$ git log -p -number_of_entries

• See some abbreviated stats for each commit

$ git log --stat

• Change the log output to formats other than the default by --pretty=
•  The oneline option prints each commit on a single line

$ git log --pretty=oneline

•  The format option allows you to specify your own log output format

$ git log --pretty=format:"%h - %an, %ar : %s"

%H Commit hash
%h Abbreviated commit hash

%an Author name

%ae Author e-mail
%ar Author date, relative
%s Subject
%ce Committer email
%cd Committer date
%cr Committer date, relative

The author is the person who originally wrote the patch, whereas the committer is the person who last applied the patch.

• Add a nice little ASCII graph showing your branch and merge history

$ git log --graph

• Time-limiting options

Option Description
-(n) Show only the last n commits
--since, --after Limit the commits to those made after the specified date.
--until, --before Limit the commits to those made before the specified date.
--author Only show commits in which the author entry matches the specified string.
--committer Only show commits in which the committer entry matches the specified string.

Using a GUI to Visualize History

A Tcl/Tk program called gitk which is basically a visual git log tool, and it accepts nearly all the filtering options that git log does.

Undoing Things

Changing Your Last Commit

$ git commit --amend

Unstaging a Staged File

$ git reset HEAD ...

Unmodifying a Modified File

$ git checkout --  ...

Working with Remotes

Showing Your Remotes

$ git remote

If you’ve cloned your repository, you should at least see origin — that is the default name Git gives to the server you cloned from.

You can also specify -v, which shows you the URL that Git has stored for the short name.

$ git remote -v

Adding Remote Repositories

git remote add [remote-name] [url]

Fetching and Pulling from Your Remotes

To get data from your remote projects,

$ git fetch [remote-name]

If you clone a repository, the command automatically adds that remote repository under the name origin.

It’s important to note that the fetch command pulls the data to your local repository — it doesn’t automatically merge it with any of your work or modify what you’re currently working on.

If you have a branch set up to track a remote branch, you can use the git pull command to automatically fetch and then merge a remote branch into your current branch.

By default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from (assuming the remote has a master branch). Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.

Pushing to Your Remotes

$ git push [remote-name] [branch-name]

This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime.

Inspecting a Remote

$ git remote show [remote-name]

Removing and Renaming Remotes

git remote rename [old-remote-name] [new-remote-name]

$ git remote rm  [remote-name]

Tagging

Listing Your Tags

$ git tag

Creating Tags

Annotated Tags

$ git tag -a tag_name -m 'tag_messages'

You can see the tag data along with the commit that was tagged by using the git show command.

Signed Tags

You can also sign your tags with GPG, assuming you have a private key.

$ git tag -s tag_name -m 'tag_messages'

Lightweight Tags

This is basically the commit checksum stored in a file — no other information is kept.

$ git tag tag_name

Verifying Tags

To verify a signed tag, you use git tag -v [tag-name].

Tagging Later

$ git tag -a tag_name check_sum

Sharing Tags

By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them.

$ git push origin tag_name

To transfer all of your tags to the remote server that are not already there.

$ git push origin --tags