Chapter 2. Git Basics
$ git init
This command creates a new subdirectory named .gitthat contains all of your necessary repositoryfiles—a Git repository skeleton. At this point, nothing in your project istracked yet.
$ git add *.c
$ git add README
$ git commit -m 'initial project version'
$ git clone git://github.com/schacon/grit.git
That creates a directory named grit, initializes a .gitdirectory inside it, pulls down all the data for thatrepository, and checks out a working copy of the latest version. If you want toclone the repository into a directory named something other than grit, you can specify that as the command-line option.
$ git add README
If you run the git status command again, you cansee that your README file is now tracked and staged. You can tell that it'sstaged because it's under the "Changes to be committed"heading. If you add a directory, the command adds all the files in thatdirectory recursively.
$ cat .gitignore
*.[oa]
*?
The first line tells Git to ignoreany files ending in .o or .a—object and archive filesthat may be the product of building your code. The second line tells Git toignore all files that end with a tilde (?).
# a comment - this is ignored
*.a????? ?# no .a files
!lib.a??? ?# but do track lib.a, even though you'reignoring .a files above
/TODO? ?# only ignore the root TODO file, notsubdir/TODO
build/??? # ignore all filesin the build/ directory
doc/*.txt? # ignoredoc/notes.txt, but not doc/server/arch.txt
?
gitstatus output.
$ git rm --cached readme.txt
$ git rm log/\*.log (removes allfiles that have the .log extension in the log/ directory.)
$ git rm \*?? (removes all files that end with ?)
$ git mv README.txt README
this is equivalent to running something like:
$ mv README.txt README
$ git rm README.txt
$ git add README
Git figures out that it's a rename implicitly. If you runsomething like this and look at the status, you'll see that Git considers it arenamed file.
$ git log --pretty=format:"%h - %an, %ar : %s"
FormattingOptions for the git log pretty Output
The oneline and format?options are particularly useful with another logoption called --graph?. This option adds a nicelittle ASCII graph showing your branch and merge history, in which you can seeyour copy of the Grit project repository.
?
Option
Description
-p
--stat
--shortstat
--name-only
--name-status
--abbrev-commit
--relative-date
--graph
--pretty
$ git log --since=2.weeks
This command works with lots of formats—you can specify aspecific date ("2008-01-15") or a relative date such as "2 years1 day 3 minutes ago".
The --author option allows you to filteron a specific author, and the --grep option lets you search forkeywords in the commit messages. Use --all-match?to match all filter otherwise the command will match commits with any. If youspecify a directory or file name, you can limit the log output to commits thatintroduced a change to those files. This is always the last option and isgenerally preceded by double dashes (--) to separate the paths from theoptions.
Common git log Filtering Options
-(n)
--since, --after
--until, --before
--author
--committer
$ git commit --amend
This command takes your staging areaand uses it for the commit. The same commit-message editor fires up, but italready contains the message of your previous commit. You can edit the messagethe same as always, but it overwrites your previous commit. This commit willreplace the previous one.
$ git fetch [remote-name]
The command goes out to that remote project and pulls downall the data from that remote project that you don't have yet. After you dothis, you should have references to all the branches from that remote, which youcan merge in or inspect at any time. The fetch?commandpulls the data to your local repository—it doesn't automatically merge it withany of your work or modify what you're currently working on. You have to mergeit manually into your work when you're ready.
?
$git push [remote-name] [branch-name]
If someone else pushed upstream and then you push upstream,your push will rightly be rejected. You'll have to pull down their work firstand incorporate it into yours before you'll be allowed to push.
$ git tag ?l v1.4.2.*
$ git tag -a v1.4 -m 'my version 1.4'
$ git show v1.4
$ git tag -s v1.5 -m? 'mysigned 1.5 tag'
$ git tag -a v1.2 9fceb02
source ?/.git-completion.bash
If you want to set up Git to automatically have Bash shellcompletion for all users, copy this script to the /opt/local/etc/bash_completion.ddirectory on Mac systems or to the /etc/bash_completion.d/?directory on Linux systems. This is a directory ofscripts that Bash will automatically load to provide shell completions.
$ git config --global alias.ci commit
git ci <---->git commit
$ git config –global alias.unstage?'reset HEAD --'
git unstage fileA <---->gitreset HEAD fileA
$ git config --global alias.visual "!gitk"
git visual?<---->gitk
