Gi
from the bottom up
u,
Sep
by John WiegleyIn my pursuit to understand Git, it’s been helpful for me to understand it from the bottomup — rather than look at it only in terms of its high-level commands. And since Git is so beauti-fully simple when viewed this way, I thought others might be interested to read what I’ve found,and perhaps avoid the pain I went through
fi
nding it.I used Git version 1.5.4.5 for each of the examples found in this document.
Contents
1. License22. Introduction23. Repository: Directory content tracking4
Introducing the blob 5Blobs are stored in trees 6How trees are made 7
e beauty of commits 9A commit by any other name… 11Branching and the power of rebase 14
4.
e Index: Meet the middle man19
Taking the index farther 21
5. To reset, or not to reset23
Doing a mixed reset 23Doing a so
reset 24Doing a hard reset 25
6. Last links in the chain: Stashing and the re
fl
og267. Conclusion288. Further reading29
License
is document is provided under the terms of the Creative Commons Attribution-Share Alike3.0 United States License, which may be viewed at the following URL:http://creativecommons.org/licenses/by-sa/3.0/us/In brief, you may use the contents of this document for any purpose, personal, commercialor otherwise, so long as attribution to the author is maintained. Likewise, the document may bemodi
fi
ed, and derivative works and translations made available, so long as such modi
fi
cationsand derivations are o
ff
erred to the public on equal terms as the original document.
Introduction
Welcome to the world of Git. I hope this document will help to advance your understanding of this powerful content tracking system, and reveal a bit of the simplicity underlying it — howev-er dizzying its array of options may seem from the outside.Before we dive in, there are a few terms which should be mentioned
fi
rst, since they’ll appearrepeatedly throughout this text:
repository
A
repository
is an archive of what the
working tree
looked like at di
ff
er-ent times in the past — whether on your machine or someone else’s. It’sa history of snapshots, and allows you to compare your working tree tothose past states. You can even “checkout” a copy of the past, makechanges you should have made long ago, and then merge those changesforward into your current branch.
the index
Unlike other, similar tools you may have used, Git does not commitchanges directly from the
working tree
into the
repository
. Instead,changes are
fi
rst registered in something called the
index
.
ink of it asa way of “con
fi
rming” your changes, one by one, before doing a commit(which records all your approved changes at once). Some
fi
nd it helpfulto call it instead as the “staging area”, instead of the index.
working tree
A
working tree
is any directory on your
fi
lesystem which has a
reposito-ry
associated with it (typically indicated by the presence of a sub-direc-tory within it named
.git
.). It includes all the
fi
les and sub-directoriesin that directory.
les/git.from.bottom.up.php© 2008 John Wiegley
-
-
branch
A
branch
is just a name for a commit (and much more will be said aboutcommits in a moment), also called a reference. It’s the parentage of acommit which de
fi
nes its history, and thus the typical notion of a“branch of development”.
master
e mainline of development in most repositories is done on a branchcalled “master”. Although this is a typical default, it is in no way special.
e word
refers to the most recent commit of the last branch youchecked out.
us, if you are currently on the master branch, the wordsmaster and
would be equivalent.
e usual
fl
ow of events is this: A
er creating a repository, your work is done in the working tree. Once your work reaches a signi
fi
cant point — the completion of a bug, the end of the working day, a moment when everything compiles — you add your changes successively to theindex. Once the index contains everything you intend to commit, you record its content in therepository. Here’s a simple diagram that shows a typical project’s life-cycle:
Index
Repository
WorkingTree
Changes to the
workingtree
are registered in the
index
using
git-add
Changes are committed tothe
repository
from thestate of the
index
using
git-commit
Earlier states of the
workingtree
may be checked outfrom the
repository
at anytime using
git-checkout
With this basic picture in mind
1
, the following sections shall attempt to describe how eachof these di
ff
erent entities is important to the operation of Git.
1.Inreality,acheckoutcausescontentsfromtherepositorytobecopiedintotheindex,whichisthenwrittenouttotheworkingtree.Butsincetheuserneverseesthisusageoftheindexduringacheckoutoperation,Ifeltitwould make more sense not to depict it in the diagram.
les/git.from.bottom.up.php© 2008 John Wiegley
-
-
Search History:
Result 00 of 00
00 results for result for
p.
Git from the bottom up, by John Wiegley
In my pursuit to understand Git, it’s been helpful for me to understand it from the bottom up — rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, I thought others might be interested to read what I’ve found, and perhaps avoid the pain I went through finding it.
8.2K
Reads
14
Readcasts
2
Embed Views
Recommended
More From This User
Notes
Load more
