pragmatic guide to git

Download from Wow! eBook <www.wowebook.com>
What Readers Are Saying About Pragmatic Guide to Git
I’ d heard a l ot of the hype surrounding Git. It wa s n ’t until I read T r a v i s ’
book that I learned why people are so e nthusiastic a bout i t. T r a v i s does a
great j ob e x p l a i n i n g the p o wer of Git in a digestible format.
Ivo Ja n s c h
PHP e v a n g e l i s t , author, and founder, Egeniq.com
Git can be i ntimidating and frustrating to n ew users. P ragmatic Guide t o Git
alleviates that pain with a s traightforward, concise w a l k - t h r o u g h that a rms
readers with ex a c t l y what they need to u se Git productively.
Luigi Montanez
Software d ev eloper, Sunlight Labs
This book i s a must-have for anyone u sing Git or just g etting started with
Git. I t has s aved me time in finding the best practices f or managing my Git
repositories and will sit on my bookshelf as the go-to r esource for anything
Git.
J o h n Mertic
Senior software e ngineer, SugarCRM
W i t h two y ears of e x p e r i e n c e with Git, I thought I wo u l d have known most
e v e r y t h i n g in Pragmatic Guide to Git. After reading it cover t o cover, I
learned that’s not t he case. It’ s a well-organized collection o f useful Git
techniques for all audiences.
Luke Pillow
Software e ngineer, pillowfactory.org
Download from Wow! eBook <www.wowebook.com>
Pragmatic Guide to Git
T r a v i s Swicegood
The P ragmatic Bookshelf
Raleigh, North Carolina Dallas, T e x a s
Download from Wow! eBook <www.wowebook.com>
Many of the designations used by manufacturers and sellers to distinguish their products are

claimed as trademarks. W here those d esignations appear in this b ook, and The P ragmatic Pro-
grammers, LLC was aw a re of a trademark claim, the designations have been printed i n initial
capital letters or in all c apitals. T he Pragmatic Starter Kit, T he Pragmatic Programmer, Pragmatic
Programming, Pragmatic Bookshelf and the linking g device are trademarks o f T he P ragmatic
Programmers, LLC.
Every precaution was taken in the preparation of this book. However, t he publisher assumes n o
responsibility for errors or omissions, or for damages that may result f rom the use of information
(including p rogram listings) contained herein.
Our Pragmatic courses, wor k s ho ps , and other products can help you and your team create better
software and have more fun. Fo r more information, as well as the latest Pragmatic titles, please
visit u s at .
The team that produced this book includes:
Editor: Susannah Davidson Pfalzer
Indexing: Potomac Indexing, LLC
Copy edit: Kim W i m p s e t t
Layout: Steve P eter
Production: Janet Furlow
Customer support: Ellie Callahan
International: Juliet Benda
Copyright
©
2010 Pragmatic P rogrammers, LLC.
All r ights reserved.
No part of this publication m ay be reproduced, s tored in a r etrieval system, or transmitted, in any
form, or by any means, electronic, mechanical, p hotocopying, recording, or otherwise, without the
prior consent of the publisher.
Printed i n the United States of America.
ISBN-10: 1-934356-72-7
ISBN-13: 978-1-934356-72-2
Printed on acid-free paper.

P1.0 printing, October 2010
V e r s i o n : 2010-10-29
Download from Wow! eBook <www.wowebook.com>
Contents
Acknowledgments 8
Introduction 9
Who I s This Book Fo r ? . . . . . . . . . . . . . . . . . . . . 9
How to Read This Book . . . . . . . . . . . . . . . . . . . . 10
How Git Is Different . . . . . . . . . . . . . . . . . . . . . . 1 2
The Git W o r k fl o w . . . . . . . . . . . . . . . . . . . . . . . 13
Online Resources . . . . . . . . . . . . . . . . . . . . . . . 16
I Getting Started 17
T a s k 1. Installing Git 20
T a s k 2. Configuring Git 22
T a s k 3. Creating a New Repository 24
T a s k 4. Creating a Local Copy o f an E xisting Repository 26
II W o r k i n g with Git 28
T a s k 5. Seeing What Has Changed 32
T a s k 6. Staging Changes to Commit 34
T a s k 7. Committing Changes 36
T a s k 8. Ignoring F iles 38
T a s k 9. Undoing Uncommitted Changes 40
T a s k 10. Moving F iles in Git 42
T a s k 11. Deleting F iles i n Git 44
Download from Wow! eBook <www.wowebook.com>
CONTENTS 6
T a s k 12. Sharing Changes 46
III Organizing Y o u r Repository with Branches and T a g s 48
T a s k 13. Creating and Switching Branches 54
T a s k 14. V i e w i n g Branches 56

T a s k 15. Merging Commits Between Branches 58
T a s k 16. Rewriting History b y Rebasing 60
T a s k 17. Deleting Branches 62
T a s k 18. T a g g i n g Milestones 64
IV W o r k i n g with a T e a m 66
T a s k 19. Adding and Removing Remotes 70
T a s k 20. Retrieving Remote Changes 72
T a s k 21. Retrieving Remote Changes, Pa r t II 74
T a s k 22. Sending Changes t o Remotes 76
T a s k 23. Handling Remote T a g s and Branches 78
V Branches and Merging Revisited 80
T a s k 24. Handling Conflicts 82
T a s k 25. Handling Conflicts with a GUI 84
T a s k 26. T e m p o r a r i l y Hiding Changes 86
T a s k 27. Cherry-Picking Commits 88
T a s k 28. Controlling How Y o u Replay Commits 90
T a s k 29. Moving Branches 92
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
CONTENTS 7
VI W o r k i n g with the Repository’s History 94
T a s k 30. V i e w i n g the Log 98
T a s k 31. Filtering the Log Output 100
T a s k 32. Comparing Differences 102
T a s k 33. Generating Statistics About Changes 104
T a s k 34. Assigning Blame 106
VII F ixing Things 108
T a s k 35. Fixing Commits 1 10
T a s k 36. Reverting Commits 112

T a s k 37. Resetting Staged Changes and Commits 114
T a s k 38. Erasing Commits 116
T a s k 39. Finding Bugs with bisect 118
T a s k 40. Retrieving “Lost” Commits 120
VIII Moving Beyond the Basics 122
T a s k 41. Exporting Y o u r Repository 124
T a s k 42. Doing Some Git Housekeeping 126
T a s k 43. Syncing with S ubversion 128
T a s k 44. Initializing Bare Repositories 130
A Glossary 132
Index 136
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
Acknowledgments
Like any book, this is the result of much more than an author such as me
sitting in front of their computer typing a b u n c h of wor d s. Please give me a
few minutes to thank those in v olved in b ringing this book to you.
First, I’ d like to thank a reader of my first book, who shot me an email that
planted the seed that b ecame this book.
Next, Dave, Andy , and the entire crew at Pragmatic Bookshelf have been
great to wo r k with a second time. Both books I’v e written for them have
been gambles—first as a r ookie author and then with this book as an author
charting the territory of a new format—and they haven’t blinked an e y e .
My editor, Susannah Davidson Pfalzer, has been indispensable. She wa s al-
wa y s there with advice, tips, the occasional tough love, and an e v e r - o p t i m i s t i c
attitude; e v e r y author should b e so lucky.
Reviewers of early drafts of this book provided me with a tremendous amount
of constructive f eedback that helped s haped this book i nto what you’ re hold-
ing in your hands (or looking at on your computer’s screen). Thanks to Joel

Clermont, Javier Collado, Geoff Drake, Chad Dumler-Montplaisir, W a y n e
Huang, Michael Hunger, Ivo Jansch, Jerry K u c h , J ohnathan Meehan, John
Mertic, Luigi Montanez, Karl Pfalzer, Luke Pillow, Christophe Portneuve,
T o m Sartain, Stefan T u r a l s k i , T o m V a n Herreweghe, Matt W a r r e n , and Nick
W a t t s .
No acknowledgments for a b ook on an open source tool wo u l d be complete
without acknowledging the wo r k of the legion of v o l u n t e e r s who made the
project possible. A h uge debt is o w e d by a ll of us who use Git to the nearly
700 people who have contributed to the project.
My family and friends, in particular my wife (whom I’m lucky enough to
count as both), have been amazing—as always. W i t h o u t their support, and
that of the rest of my fa m i l y and friends, t his book w o u l d not have happened.
Download from Wow! eBook <www.wowebook.com>
Intr oduction
The wo r ld of v e r s i o n control systems (VCSs) has undergone a major shift
o v e r the past few years. F a s t , reliable, and approachable distributed v e r s i o n
control systems ( DVCSs) s uch as Git ha ve b u r s t onto the scene and c hanged
the landscape of open source software development and corporate software
wo r kfl ow s .
This book is your guide t o this new p aradigm. It’s n ot a complete reference;
instead, it focuses on getting you up and running quickly . P ragmatic Guide to
Git covers the 95 p ercent of Git that you’ll use at least once a week, as well
as a few tasks that will come in h andy b u t aren’t used as often.
Git started when the license of VCS software that the Linux ke r n e l used to
track changes w a s revoked. After investigating the other alternatives, Linus
T o r v a l d s decided he could write a better ve r s i o n control system i n a few weeks
than what c urrently ex i s t e d , so he set off to do t hat.
Git, then in a v e r y rough form, wa s the result of that two weeks of hacking
together some s hell scripts b ack in the spring of 2005. Linus had to calculate
pieces of the commits by hand on the first few commits (commits are the

changes Git tracks for you). Since those original hand-rolled commits, Git
has become the l eader in the field o f D V C S .
Who Is This Book For?
This book is geared for someone new to Git who is looking to get up to speed
quickly. This book is for you if you’ re already familia r with another VCS
such a s Subversion and are l ooking for a quick g uide to the Git landscape or
if you’re a quick study and w a n t a concise guide. It’ s organized by task to
make it easy to translate from the task you need to accomplish to how the
process w o r k s in Git.
If y ou’ ve never used a ve r s i o n control system before a nd thought Subversion
wa s something you d id t o o v e r t h r o w governments, t his b ook will get you up
and r unning with Git. Fo r much more detail on ve r s i o n control concepts, you
should read Pragmatic V e r s i o n Control Using Git,
1
my other book, a s well.
1.
Download from Wow! eBook <www.wowebook.com>
HOW TOREADTHISBOOK 1 0
How to Read This Book
This book is organized in parts to guide you from starting out t hrough more
complex situations, with each part broken down into tasks. T a s k s follow a
specific f ormula: t he left page ex p l a i n s the t ask and t he commands r elated to
it, and the right page gives you the raw commands with a little bit of informa-
tion about them and a cross-reference t o related t asks.
Y o u can read this book in paper form as an open book to see the tasks side
by side, b u t it’s also an e x c e l l e n t reference in digital form, especially when
searching for a particular Git task.
If you’ re reading a digital v e r s i o n of this book on a computer with a large
enough display, I recommend setting your reader to display two pages side by
side instead of a single page. That gives you the same visual that’s intended

in the book.
On y our first pass, I suggest that you read the introductions to each part. They
give you a broad o v e r v i e w of how to approach e ach part o f the Git wo r kfl ow,
as well as a synopsis o f the t asks contained in that p art.
Armed with high-level information, y ou can determine where t o dive in. Y o u
can read this book from start to finish or cherry-pick the tasks relevant to what
you’ re trying to accomplish.
The parts of this book are organized to wa lk you through the v a r i o u s phases
of u se in Git.
• P a r t I, Getting Started, starts with the absolute basics—installing and
configuring Git and creating your fi rst r epository.
• P a r t II, W o r k i n g with Git, covers the basic commands you need as
part o f your d ay-to-day i nteraction with Git by y ourself. These are the
b u i l d i n g blocks, and they’re a must-read if this i s your first time u sing
Git.
• P a r t III, Organizing Y o u r Repository with Branches and T a g s , intro-
duces branches, a powerful a nd central part of Git t hat’ s necessary f or
understanding how e v e r y t h i n g wo r ks together.
• P a r t IV, W o r k i n g with a T e a m , c o vers the most powerful aspect o f any
VCS: collaborating with other developers. This part gets you up to
speed on how to share your w o rk with other developers and retrieve
changes from them.
• P a r t V , Branches and Merging Revisited, b u i l d s on the information in
P a r t III and teaches you how to handle it when things go wrong, as
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
HOW TOREADTHISBOOK 11
well as some of the more complex wa y s to handle merging and moving
branches a round.

• P a r t VI, W o r k i n g with the Repository’ s History, introduces you to all
the history you’ve been generating. Using this information, you can
figure out what another developer (or maybe e v e n you) w a s thinking
when y ou made a particular c hange.
• P a r t VII, F i x i n g Things, shows y ou h o w Git can help you fi x things in
your repository—be that commits that need to be adjusted or finding
b u g s in your code.
• P a r t VIII, Moving Beyond the Basics, introduces you to a few concepts
that don’t fit into the normal e v e r y d a y w o r k fl ow b u t a re useful when
they’re needed.
There are diagrams throughout this book. Whenever you see a circle, it repre-
sents a commit—with the e x c e p t i o n of Figure 2, on page 16, where the circles
represent repositories.
This matches the style used throughout the Git manual when it shows e x a m p l e
repository s tructures to e x p l a i n commands. In addition t o the standard graph-
ical d iagrams t hroughout, in some places I’ve opted for a plain-text diagram
to introduce y ou to t he Git manual d iagram style.
Throughout the book you’ll see e x a m p l e s of the output you can e x p e c t Git
to generate for a given command. K e e p in mind that your output w o n ’t be
e x a c t l y the same because of the wa y Git ke e p s track of commit IDs—more
on that i n a minute.
Several commands don’t generate any output after they run successfully,
though. Fo r these c ommands, I include an empty prompt> after the success-
ful c ommand to s how that there is n o output.
The fi rst reference to each new term includes an e x p l a n a t i o n of what the term
means. If you read t he book from start to finish, you’ll k now all o f the t erms
from previous introductions to them.
Did you forget a term or are you using the book as a r eference and not reading
it straight through? Y o u ’ r e covered there, too. Y o u can refer t o Appendix A,
on p age 1 32; there you’ll get ex p l a n a t i o n s of all the common—and some not

so common—jargon you’ll encounter in this book and in y our adventures in
Git.
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
HOW GITIS DIFFERENT 12
What V e r s i o n of Git to Use
I used the 1.7.x v e r s i o n of Git while writing the majority of this b ook. All of
the commands a s of this writing wo r k with 1.7.2.1 and s hould w o r k with the
majority of Git 1 .6.x ve r s i o n s .
The installation methods mentioned in T a s k 1, Installing Git, on p age 20 all
have recent v e r s i o n s of Git a v a i l a b l e , so make sure you’re running a recent
v e r s i o n , and you w o n ’t have any trouble following along. Y o u can run git
version from t he command line to s ee what ve r s i o n you have.
Before we dive into the tasks, let’s talk a bit about Git and what makes it
unique.
How Git Is Different
Git is a bit d ifferent from traditional ve r s i o n control systems. If you’re c om-
ing to Git from another c entralized system, this s ection ex p l a i n s some of the
differences and gets you thinking in Git style.
Distributed vs . Centralized
There are generally two models in v e r s i o n control systems: centralized and
distributed. T o o l s such as Subversion typically require a network connection
to a c entralized server . Y o u make a change to your project and then commit
that change, which is sent to the centralized server to t rack. Other developers
can t hen immediately a ccess your changes.
Distributed v e r s i o n control systems, such as Git, break the process of com-
mitting code and sharing it with others into two parts. Y o u can commit y our
code to your local private repository without having to talk to a centralized
server, removing the n eed to be connected to a network to make a change.

Private vs. Public Repositories
Each developer who is sharing code with other developers has at least two
repositories: a private and a public repository . The private repository is the
one that e x i s t s on your computer a nd is the one you make c ommits to.
Public repositories a re the r epository that you use to share your changes with
other developers. Multiple developers might have access to push changes to
the same public repository, or each developer may have their o w n public
repositories.
Y o u can p ush to and fetch from multiple r epositories. This allows you to pull
in changes from a nother developer who’s w o rk i ng on t he same project.
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
THEGITWORKFLOW 13
Commit IDs Instead of Revision Numbers
Centralized VCS have the benefit of having one system that doles out revi-
sion numbers. Because e v e r y o n e is committing and sharing t heir code in one
repository , that repository can control what numbers it assigns to a particular
commit.
That model doesn’t wo r k in a decentralized system. Who’s to say which com-
mit is actually the second commit, me or you? Git uses commit IDs that are
SHA-1 hashes instead. The hash is based on the code, what came before it,
who made the commit, when they made it, and a few other pieces of metadata.
The chances are incredibly small of there being two different commits with
the s ame commit ID.
Forking Is Good
F o r the longest time, forking a project w a s a bad thing. It drained resources
a w a y from the main project, and merging changes between the two projects
wa s time-consuming when possible.
Git’ s superior merge capabilities, rooted in its distributed n ature, make merg-

ing changes from a “forked” repository trivial. In fa c t , the idea of forking is
so ingrained in the Git community that one of the largest Git communities
online, GitHub,
2
is b u i l t around t he concept. T o offer y our c hanges, you f ork
a repository, commit your changes, and then ask the original developer to pull
your changes in through a pull r e q u e s t .
Instead of an indicator of a project suffering from internal strife, the num-
ber of forks on a repository is considered the sign of an activ e community
wo r ki n g on a project.
The Git W o r k fl o w
W o r k i n g by yourself on a p roject with no v e r s i o n control, you hack a little, test
it out and see whether it does what you w a n t , tweak a few more lines of code,
and repeat. Adding v e r s i o n control into the mix, you start committing those
tweaks to keep a record of them. The high-level o v e r v i e w of Git’s general
wo r kfl ow is shown in Figure 1, on the next page.
My Standard W o r k fl o w
My standard day wor k in g with Git goes something like this: I fetch all the
changes from the other developers on my team to make sure I’m w o r k i n g
with the latest code, a nd then I start wo r k i n g on the user s tories I have for the
day. As I make changes, I create a handful of commits—a separate commit
for e ach change that I make.
2. http://github .com/
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
THEGITWORKFLOW 14
Fetch Changes
from the Team
Make Changes

& Commit Them
(repeat until done)
Review Commits
Share Changes
with the Team
Start your day here
Figure 1: The Git wo rk fl ow
Occasionally, I end up with sev eral separate changes that all n eed to be com-
mitted. I ’ll b reak out Git’s patch mode, stage, and finally commit e ach s et o f
changes separately .
Once I have the feature complete, I give the commits I’ ve created a quick
review to make sure all the changes are necessary . At this point I look for
commits that can be combined and make sure they are in the most logical
order .
Finally , once I have those commits ready , I share those commits by push-
ing them (push is the term for sending commits to another repository) back
upstream to my public repository so the rest of the team can view them and
integrate t hem with t heir repositories.
Small T e a m s with a Shared Repository
Many small teams use Git like a traditional v e r s i o n control system. They have
one main repository that all the developers can send changes to, and each
developer has their o w n private r epository to t rack their changes in.
Y o u make your changes locally; then when you’re ready to share them with
other d e velopers, you push t hem back to the r epository you all share.
If someone else has shared their changes since the last time you updated from
the shared repository, you will get an error. Y o u must first get the changes
from the shared repository and integrate them into your repository through
a process called merging. Once the changes are merged, you can push your
changes to share with the rest of t he team.
Report erratum

this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
THEGITWORKFLOW 15
Git in Open Source
Each open source project has its o w n methods of accepting changes. Some
projects use a fully distributed model where only one person can push changes
to the main repository, and that person is responsible for merging changes
from all the c ontributors into the main r epository .
Having only one person capable of pushing changes is o ften too demanding
a job for a large open source project. Many h ave a main r epository that all o f
the c ommitters c an send changes to.
The main developers encourage people who are just starting out t o fork their
project—create a copy of the repository somewhere else—so the main de vel-
opers and other members of the community can review their changes. If
they’re accepted, one of the main contributors merges them back into the
project’s repository.
These different scenarios constitute different repository layouts. Git allows
several different l ayouts, and covering t hem deserves a section to itself.
Repository Layouts
The distributed nature of Git gi ves you a lot o f flexibility in how you manage
your repositories. Every person on your team has their o w n private repository
—the repository that only that person can update. However, there are two
distinct wa y s to handle public repositories. Fo r a v isual e x p l a n a t i o n of these
layouts, see Figure 2, on the following page.
One method is the fully distributed model. In this, each developer has their
o w n public repository that the developer uses to publish their changes to.
All the other developers on the team then pull changes from e v e r y o n e e lse’ s
repositories to keep current.
In practice, most t eams ha ve a l ead d e veloper who is r esponsible f or making
sure all the changes are integrated. This limits the number of repositories you

and your team have to pull changes from to one, b u t it increases the wo r k l o a d
on the person who h as to integrate e v e r y o n e ’ s changes.
Another method is the s hared r epository model, where a ll developers can push
to a shared r e p o s i t o r y . This resembles the standard centralized model and is
often adopted by teams when they first start using Git—it requires the least
amount of mental o v e r h e a d when i t comes to thinking about where a change
is shared.
Y o u can mix both of these as well to create a hybrid solution. Use a shared
repository for all of t he code that’ s ready for p roduction, and each d ev eloper
maintains their o w n public repository for sharing code that’s still a w o rk in
progress. This is the model I’ve employed successfully at my company and
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
ONLINERESOURCES 16
Y o uBob Alice
Shared
Repository
Y o u
Bob
Alice
Push
Pull
Distributed
Repositories
Figure 2: Shared and distributed repository layout with three d evelopers. Gray
circles are the p rivate repositories; outlined circles are public repositories.
that’s used by many open source projects—push final changes to the main
repository , and ke e p e x p e r i m e n t a t i o n in your o w n repository.
Online Resources

Several online resources are a v a i l a b l e for this book. The book’s website is the
jumping-off point f or all of t hem:
/>From h ere, you can view the errata (and add any errors you find) a nd head t o
the book’s forum where you can discuss and ask questions—both about the
book and about Git.
Now that you know what t his book is about, let’s get started.
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
P a r t I
Getting Started
Download from Wow! eBook <www.wowebook.com>
GETTINGST A R T E D 18
Ready to get started with Git?
3
Git is an extremely powerful tool
that’s relatively easy to start using. Like all software, it requires instal-
lation and minimal setup before y o u can start using it.
Covered in this part:
• W e start off with T a s k 1, Installing Git, on page 20 to handle
installation. Git’s heritage in the Linux w o r l d means it can be
compiled directly from source, but there are other (easier)
options f o r e v e r y m a j o r operating system.
• Y o u need to tell Git a f e w configuration settings before y o u
start using it, covered in T a s k 2, Configuring Git, on page 22.
• Now that Git is installed and configured, y o u star t using it in
T a s k 3, Creating a New Repository, on page 24. Y o u learn how
to create a completely new repository.
• Another w a y to start a Git repository is to create a clone of
someone else’s repository, covered in T a s k 4, Creating a Local

Copy of an Existing Repository, on page 26.
Once y o u ’ v e m a d e it through these basic steps , y o u ’ l l be ready
to start w o r k i n g with Git. F e e l free to skim the f o l l o w i n g tasks if y o u
already have Git installed and configured and have created a new
repository or cloned an existing one.
3. I promise, no more get/Git puns the rest of the book.
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
GETTINGST A R T E D 19
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
INSTALLINGGIT 20
1
Installing Git
Y o u can i nstall Git in several different wa y s : by u sing o ne of the GUI
installers, b y using a package management system, or , in the time-honored
Linux tradition that spawned Git, b y compiling it from source.
Don’t wo r ry if y ou’ re not ready t o start compiling software; all major
operating systems provide alternatives to c ompiling Git y ourself. F o r
e x a m p l e , Ubuntu p rovides Git v ia its apt-gettool, so a few commands f rom
the t erminal are enough t o get y ou going. Likewise, OS X users h a ve the
option of u sing MacPorts
4
or the new Homebrew
5
to handle the installation.
Not to be left out, W i n d o w s users who use C ygwin
6

can a lso install it v ia
Cygwin’s setup.exe.
W i n d o w s and OS X users who prefer GUI installations h ave alternatives
a v a i l a b l e as well. W i n d o w s users c an use t he msysGit
7
installer to get up and
running, and OS X users can install Git using t he Git OS X Installer
8
to
install Git v ia a DMG.
The original wa y to install Git, which is still the best if you w a n t to remain
on the latest v e r s i o n , is to b u i l d it from source. The v a r i o u s dependencies can
be h ard to track down, especially if you plan on b u i l d i n g the user manual.
T o o l s like apt-getbuild-dep on Ubuntu are helpful f or tracking down a ll of
the d ependencies.
W a t c h mixing installation tools. Fo r e x a m p l e , if you use a Mac and have
installed most o f your software u sing MacPorts, stick with MacPorts; if you
compile all your o w n software on Linux, no w probably isn’t the time to s tart
using apt-get. S witching t o Git p rovides you with enough learning
opportunities, s o be c areful to g uard t hat installing Git d oesn’t cause the yak
to get a trim.
9
4. />5. http://github .com/mxcl/homebrew—Homebrew is relatively new t ool that handles compiling
software on a Mac. It stores all of its formulas, the instructions for installing software, in a Git
repository.
6. />7. />8. />9. />Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
INSTALLINGGIT 21
Compile Git from its source code.

Download the latest tarball f rom the Git website.
10
prompt> tar -xjf git-YOUR-VERSION.tar.bz2
prompt> cd git-YOUR-VERSION
prompt> make
prompt> make install
Y o u can c ompile the documentation from source as well. Replace the last
two lines i n the previous steps with this:
prompt> make all doc
prompt> make install install-doc
Install Git on Ubuntu.
prompt> sudo apt-get install git-core
T o install t he user manual, d o this:
prompt> sudo apt-get install git-doc
T o install t he Git t o Subversion functionality , do this:
prompt> sudo apt-get install git-svn
Y o u can use apt-getto h andle all of the d ependencies and then compile Git
from source using the previous steps.
prompt> sudo apt-get build-dep git-core git-doc git-svn
Install Git on OS X.
Y o u can use MacPorts a nd install Git with S VN functionality:
prompt> sudo port install git-core +svn
There is also a Git Installer for OS X a v a i l a b l e on Google Code.
Install on Windows.
Download latest msysGit installer f rom here:
/>Or, install a s part of Cygwin’ s setup process.
10. />Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
CONFIGURINGGIT 22

2
Configuring Git
Git requires some c onfiguration t o wor k . Y o u must tell Git your name and
your email a ddress since there is no c entral repository to ke e p track of that
information. Git uses both t o calculate the commit ID—an SHA-1
11
hash—that identifies each commit.
The first two commands on the next page use global to s pecify that they
are c onfiguration v a l u e s for e v e r y repository y ou interact with o n this
machine. The configuration file i s stored i n ~/.gitconfig. Y o u can edit the
file directly in addition to using the git config command.
Y o u can set e v e r y setting on a global or per-repository basis. B y leaving
global out o f the command, t he settings will b e stored i n the repository’ s
.git/config file.
Y o u might wa n t to s et a few other useful configuration v a l u e s while
configuring Git. Y o u c an set color.ui to auto if you like to have your
command-line interfaces c olorized.
The auto setting tells Git t o use c olor whenever i t is generating o utput to b e
displayed b u t to r ender plain t e xt whenever the output is b eing piped t o
another process. T his makes it easy to output a raw d iff—the changes
between two v e r s i o n s of the file—to a file b u t still allows you to see t he
colorized d iff when you v iew the output d irectly .
Finally , Git uses core.editor to specify a particular editor. Git l aunches an
editor whenever you need to create a c ommit message, e dit patches, and do a
few other tasks.
Git doesn’t require you to s et the core.editor v a l u e , though. I t tries to fi gure
out what e ditor t o use by checking the f ollowing v a l u e s , in order:
GIT_EDITOR environment v a r i a b l e ; core.editor configuration v a l u e ; VISUAL
environment v a r i a b l e ; EDITOR environment v a r i a b l e ; and, finally, plain vi.
The v a l u e is the command-line script to launch your editor. In W i n d o w s , this

is a bit tricky, b u t there’s an e x c e l l e n t thread o n Stack Overflow
12
that can
help you get started.
11. />12. />Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
CONFIGURINGGIT 23
Configure Git to know who y o u are.
prompt> git config global user.name "Your Name"
prompt> git config global user.email ""
prompt>
Set the Git user f o r a specific repository.
prompt> cd /path/to/repository
prompt> git config user.name "Your Name"
prompt> git config user.email ""
prompt>
T u r n colors on whereverpossible i n the Git UI.
prompt> git config global color.ui auto
prompt>
Configure Git’s editor.
prompt> git config global core.editor /path/to/editor
prompt>
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
CREATINGA NEWREPOSITORY 24
3
Creating a New Repository
Repositories in Git are stored on y our local file system right a longside t he

code they track. Y o u create a repository by t yping git init in the directory that
you wa n t to start tracking files i n.
Y o u use two repositories in Git to collaborate with others: a priv ate one and a
public one. Y o u r priv ate repository—the o ne we’re creating h ere—is where
you do all y our w o r k . It’s the repository with the w o r k i n g tree.
This two-tier system gives you the a bility to track local e x p e r i m e n t a l
changes while only sharing changes via your public repository that are ready
for o thers to wo r k with. Be careful that y ou don’t allow yourself to c ode in a
cave, though. Hoarding a ll your changes until they are “ just r ight” i s the
quickest w a y to harm a project. Share e arly; share o ften.
git init creates a .git directory in your current directory a nd initializes t he Git
repository i nside t hat. Once you’ ve initialized a repository, you still need to
add a nd commit t he files u sing git add (see T a s k 6, Staging Changes to
Commit, on p age 34) and git commit (see T a s k 7, Committing Changes, on
page 36), respectiv ely, b u t both o f these require an initialized repository first.
Y o u have to initialize the repository only o nce.
Once y ou’ ve initialized a repository, you have a working t ree that you can
interact with. The w o r k i n g tree is your view into what’ s stored in your
repository . It typically r epresents the latest copy of what’ s stored in your
repository .
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>
CREATINGA NEWREPOSITORY 25
Create a repository.
prompt> mkdir some-repository
prompt> cd some-repository
prompt> git init
F o r e x a m p l e , to create a repository called widgets in t he /work directory,
use this:

prompt> mkdir /work/widgets
prompt> cd /work/widgets
prompt> git init
Initialized empty Git repository in /work/widgets/.git/
Create a repository in an existing directory, a nd add all files
from that directory.
prompt> cd /path/to/some/directory
prompt> git init
prompt> git add .
prompt> git commit -m "some commit message"
F o r e x a m p l e , to create a repository inside an ex i s t i n g directory called
/work/existing-widget, use t his:
prompt> cd /work/existing-widget
prompt> git init
Initialized empty Git repository in /work/existing-widget/.git/
prompt> git add .
prompt> git commit -m "initial commit"
[master (root-commit) 6e477fa] initial commit
101 files changed, 4083 insertions(+), 0 deletions(-)
create mode 100644 AUTHORS
and 100 more files
Related T a s k s
• T a s k 4, Creating a Local Copy of an Existing R epository, on the next
page
• T a s k 7, Committing Changes, on p age 3 6
• T a s k 12, Sharing Changes, on page 4 6
• T a s k 44, Initializing B ar e Repositories, on p age 130
Report erratum
this copy is (P1.0 printing, October 2010)
Download from Wow! eBook <www.wowebook.com>