This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of section called “Repositories and Branches” and the section called “Exploring Git history” explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for regressions, and so on.
People needing to do actual development will also want to read the section called “Developing with Git” and the section called “Sharing development with others”. Comprehensive reference documentation is available through the man pages, or git-help(1) command.
For example, for the command With the latter, you can use the manual viewer of your choice; see git-help(1) for more information.
Finally, see Appendix B, Notes and todo list for this manual for ways that you can help make this manual more complete.
It will be useful to have a Git repository to experiment with as you read this manual.
The best way to get one is by using the git-clone(1) command to download a copy of an existing repository.
If you don’t already have a project in mind, here are some interesting examples: # Git itself (approx.
40MB download): $ git clone git://git.kernel.org/pub/scm/git/# the Linux kernel (approx.
640MB download): $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/Git is best thought of as a tool for storing the history of a collection of files.
It stores the history as a compressed collection of interrelated snapshots of the project’s contents. Those snapshots aren’t necessarily all arranged in a single line from oldest to newest; instead, work may simultaneously proceed along parallel lines of development, called branches, which may merge and diverge.
A single Git repository can track development on multiple branches.
It does this by keeping a list of heads which reference the latest commit on each branch; the git-branch(1) command shows you the list of branch heads: A freshly cloned repository contains a single branch head, by default named "master", with the working directory initialized to the state of the project referred to by that branch head. Tags, like heads, are references into the project’s history, and can be listed using the git-tag(1) command: Tags are expected to always point at the same version of a project, while heads are expected to advance as development progresses.
Create a new branch head pointing to one of these versions and check it out using git-checkout(1): Note that if the current branch head was your only reference to a particular point in history, then resetting that branch may leave you with no way to find the history it used to point to; so use this command carefully.
Date: Tue Apr 19 2005 -0700 Remove duplicate getenv(DB_ENVIRONMENT) call Noted by Tony Luck.