git use manual __git

Gitusermanualchinese-robin Wiki Gitusermanualchinese

Git User Manual (1.5.3 and subsequent versions applicable)

Luo Rong (Robin Steven) < vortune@gmail.com >

English version: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

Preface Preface

Git is a fast distributed revision control system.

Git is a fast distributed version control system

This manual was designed to being readable by someone with basic UNIX command-line skills, but no previous knowledge of git.

This manual is designed for people who have basic Unix command skills, but no Git knowledge.

Chapter 1, repositories and branches and Chapter 2, exploring git history explain how to fetch and study a project using G It-read these chapters to learn you and test a particular version of a software project, search for regressions, And so on.

Chapter One version library and branch and chapter II examine Git history to show you how to use Git to get and study a project, by reading these chapters, we learn how to build and test a specific software project version, learn "retreat", and so on.

People needing to do actual development'll also want to read Chapter 3, developing with Git and Chapter 4, sharing devel Opment with others.

People need to carry out real research and development, then learn chapter three, use Git for development and fourth, share research and development with others.

Further chapters cover more specialized topics.

More chapters will cover a number of topics.

Comprehensive reference documentation is available through the man pages, or git-help (1) command. For example, for the command "Git clone <repo>", your can either use:

Reference documents can be viewed by the system's hand-pages command, or by the Git-help (1) command. For example, if you want to refer to git clone <repo>, you can use the following two ways:

$ mans Git-clone

Or: Or:

$ git help clone

With the latter, your can use the manual viewer of your choice; Git-help (1) for the more information.

Later you will have the opportunity to use these manual viewer, see Git-help (1) will get more information.

Also appendix A, Git Quick Reference for A Brief overview to git commands, without any explanation.

Read Appendix A, which is a quick overview of a git command, but it doesn't take any commentary.

Finally, appendix B, Notes and todo list for this manual for ways so you can help make this manual more complete.

Finally, take a look at Appendix B, the Manual's work memo and plan, through which you can help the document become more perfect.

Chapter 1. Repositories and branches the first chapter. Version libraries and branches

How do I get a git repository a version library

It is useful to have a git repository to experiment with as you read this manual.

Having an experimental Git version library is very useful for us to read this handbook.

The best way to get one are by using the Git-clone (1) command to download a copy of the existing repository. If you don ' t already have a project in mind, here are some interesting:

The best way to get an existing version library is to use the Git-clone command, and if you don't have a project in mind, here are some interesting examples:

        # git itself (approx 10MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
        # The Linux kernel (app Rox. 150MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

The initial clone may is time-consuming for a large project, and but you are only need to clone once.

Initial cloning is time-consuming for a large project, but cloning needs to be done only once.

The Clone command creates a new directory named after the project ("Git" or "linux-2.6" in the examples above). After your CD into this directory, you'll be there contains a copy of the project files, called the Working tree, Toge Ther with a special top-level directory named ". Git", which contains all the information about the history of the project.

The Clone command creates a new directory and names the project based on the name of the project (such as "Git" and "linux-2.6" in the example above). When you enter this directory, you can see that it already contains all the files for the project, which we call the working tree, and a special directory called ". Git" in the top-level directory that contains all the information about the history of the project's development.

How to check out a different version of a project how to extract different versions of projects

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 of the project ' s snapshots. In git all such version is called a commit.

It is best to use Git as a collection tool for the history of file development, which compresses and preserves the associated snapshot of the development of the project. In Git, each of these changes is referred to as delivery (commit).

Those snapshots aren ' t necessarily all arranged into a single line from oldest to newest; Instead, work may simultaneously proceed along parallel lines of development, called branches, which may merge and diverge .

These snapshots do not need to evolve from the old to the new one; they can be developed synchronously and in parallel, called branches, which can be merged and segmented.

A single git repository can track development on multiple branches. It does this by keeping a list of heads which reference the latest commit to each branch; The Git-branch (1) command shows you the list of branch heads:

A git version library can track the development of multiple branches, and it does this by saving a list of branch headers, each of which is a reference (reference) that points to the last delivery (commit) of the branch; Git-branch (1) The command can show you each branch header:

$ git Branch
* Master

A freshly cloned repository contains a single branch head, by default named ' Master ' with the working directory Initializ Ed to the "State of the" project referred to by this branch head.

A newly cloned version library contains only one branch header, the default is "Master" (the primary branch), and the working directory has been initialized to the project state that this branch header points to.

Most projects also use tags. Tags, like heads, are references into the project's history, and can be listed using the Git-tag (1) command:

Most of the items also use tags (tags). tags (tags) are like headers (heads), which point to a historical scene of the project, which can be enumerated by the Git-tag (1) command:

$ git tag-l
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3 V2.6.12-RC5
v2.6.12-rc6
v2.6.13
...

Tags are expected to always in the same version of a project, while heads are expected to advance as development pro Gresses.

Tags are treated as a unified version of the project, and heads is the progress of each step of the project.

Create a new branch head pointing to one of the versions and check it out using Git-checkout (1):

The following creates a new branch header that points to one of the versions, and extracts it, using the Git-checkout (1) command:

$ git checkout-b new v2.6.13

The working directory then reflects the contents that project had as it was tagged v2.6.13, and git-branch (1) shows Two branches, with an asterisk marking the currently Checked-out:

The working directory will be mirrored to the content of the version marked as v2.6.13 in the project, with the Git-branch (1) command showing the two branches, preceded by an asterisk (*), which is the currently extracted branch.

$ git Branch
  Master
* NEW

If you decide so you ' d rather the 2.6.17, you can modify the current branch to point in v2.6.17 instead, with

If you're going to look at the 2.6.17 version, you can migrate your current branch, let it point to 2.6.17, and use the command:

$ git reset--hard v2.6.17

Note this if the current branch head is your only reference to a particular point in history, then resetting that branch May leave and no way to find the history it used to point to; So use this command carefully.

Note that if the current branch header is your only reference to a specific historical scene, then the reset (resetting) branch will not be able to retrieve all of the previous history records of this branch, so use caution.

Understanding History:commits Understanding History: Delivery

Every change in the history of a project are represented by a commit. The Git-show (1) command shows the most recent commit on the current branch:

Each historical change in the project is reflected in each delivery (commit). The Git-show (1) command shows the latest delivery of the current branch:

$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author:linus Torvalds < Torvalds@ppc970.osdl.org. (none) >
Date:   Tue Apr 14:11:06 2005-0700

    Remove duplicate getenv (db_environment) call

    noted by Tony Luck.

Diff--git a/init-db.c b/init-db.c
index 65898FA. B002DC6 100644
---a/init-db.c
+++ b/init-db.c @@ -7,7
+7,7 @@ -7,7

 Main (int argc, char **argv)
 { c13/>-       Char *sha1_dir = getenv (db_environment), *path;
+       char *sha1_dir, *path;
        int Len, I;

        if (mkdir (". Git", 0755) < 0) {

As you can, a commits shows who made the latest change, what they did, and why.

As you can see, delivery indicates who made the final change, what changed, why.

Every commit has a 40-hexdigit ID, sometimes called the "object name" or "SHA1 ID", shown on the The "Git-show" output. Can usually refer to a commits by a shorter name, such as a tag or a branch name, but this longer name can also Ul. Most importantly, it is a globally unique name for this commit:so if your tell somebody else the object name (for example In email), then your are guaranteed that name would refer to the same commits in their repository this it does in yours (assu Ming their repository has that commit in all. Since the object name is computed as a hash over the contents of the commit, and you are guaranteed the commit can never Change without its name also changing.

Each delivery has an identification number of 40 16 characters, called the "object name" or "SHA1 ID", which is displayed in the first row of the output of the Git-show command. You can usually use a shorter name to indicate a delivery, such as the label and the name of the branch, and so on, but this long name is very useful. Most importantly, it is the globally unique name for a delivery: for example, if you tell someone about an object name (via email), then you need to make sure that the name is in your version library, Or are they pointing to the same delivery in their version library (assuming that their version library is also being submitted a lot of things). When the object name is calculated from each deliverable by hashing algorithm (hash), you can ensure that the contents of each deliverable are not modified to be separated from its name.

In fact, in Chapter 7, Git Concepts We shall this is everything stored in Git history, including file data and directory Contents, is stored in a and a name is a hash of its contents.

In fact, in the seventh chapter, in the concept of git, we can see everything stored in Git's history, including file data and directory content, are saved as objects, and object names are the hash eigenvalues of their content.

Understanding History:commits, parents, and reachability deliveries, parent delivery and accessibility

Every commit (except the very in a project) also has a parent commit which shows what happened before this co Mmit. Following the chain of parents would eventually take your back to the beginning of the project.

Each delivery (unless it is the first delivery of the project) always has his father's delivery, which explains exactly what happened to the current delivery. By tracing the parent delivery chain, you can take us back to the project's starting point.

However, the commits does not form a simple list; Git allows lines of development to diverge and then Reconverge, and the point where two lines of development reconverge Called a "merge". The commit representing a merge can therefore have more than one parent, with each parent representing the most recent COM MIT on one of the lines of development leading to that point.

In any case, the organization of these deliveries will not be simple; Git allows development routes to go their separate ways, but also to the same point, the combination of two development lines we call "merging" (merge). Indicates that the delivery of the merge is equal to having more than one parent delivered, and each parent delivers the most close delivery that each development line develops here.

The best way to-to-to-you-GITK (1) command; Running GITK now on a git repository and looking for merge commits'll help understand how the GIT organizes history.

The best way to view this mechanism is to use the GITK (1) command, now run the GITK command in the repository, and look at those merge deliveries that will help you understand how git organizes history.

In the following, we say this commit x is ' reachable ' from commit y-if commit x is a ancestor of commit Y. Equivalently, You are could say that Y are a descendant of X, or that there are a chain of parents leading from commit Y to commit X.

We then say that delivery x is "accessible" for delivery of Y, if delivery x is the ancestor of Y. Similarly, you can say that Y is a descendant of X, or that there is a genealogy of descent traced from Y to X.

Understanding History:history Diagrams Historical Evolution Chart

We'll sometimes represent git history using diagrams like the one below. Commits are shown as "O", and the links between them with lines with-/and/. Time goes left to right:

At some point, we'll use the following illustration to describe Git's history. All deliveries are indicated by "O" and are connected to each of their development lines on the drawing/and/. The passage of time is from left to right.

         O--o--o <--Branch A
        /
 o--o--o <--Master
        /
         o--o--o <--Branch B

If we need to talk about a particular commit, the character "O" is replaced with another letter or number.

If you need to talk specifically about a delivery, replace "O" with other letters or numbers.

Understanding History:what is a branch? Understanding History: What is a branch

When we are need to be precise, we'll use the word "branch" to mean a line of development, and "Branch head" (or just "head" To mean a reference to the most recent commit on a branch. In the example above, the branch head named "a" was a pointer to one particular commits, but we refer to the line of three C Ommits leading up to, as all being part of "Branch A".

For the sake of accuracy, we use the word "branching" to express the developed line and use the "branch header" (or "header") to express the latest deliveries in a branch. In the example above, the branch header called "a" is a pointer to a specific delivery. But we point out that the three deliveries that have developed to this point on the line are all part of "Branch a".

However, when no confusion would result, we often just use the term "branch" both for branches to branch for heads.

However, without confusion, we often use the term "branching" to represent branches and branch heads.

manipulating branches Operations Branch

creating, deleting, and modifying branches are quick and easy; Here ' s a summary of the commands:

creating, deleting, and changing branches are quick and easy; Here is a summary of this command:

Git branch list all branches enumerate all the branches

Git branch <branch>

Create a new branch named <branch>, referencing the same point in history as the "current branch" creates a branch and refers to the present branch as the same Historical evolution

Git branch <branch> <start-point>

Create a new branch named <branch>, referencing <start-point>, which may is specified any way to you, includ ing using a branch name or a tag name

Create a new branch called <branch>, referencing <start-point> it can be specified arbitrarily, it can be the name of an existing branch or the name of a label

Git branch-d <branch>

Delete the branch <branch>; If the branch you are deleting points to a commit which are not reachable, this command would branch W ITH a warning.

Delete a branch called <branch> if you want to delete an unreachable delivery in the current branch to which this branch is pointing, the command will return a failure and make a prompt

Git branch-d <branch> Even if the branch points to a commit is not reachable from the current branch, your may know tha T that commit are still reachable from some other branch or tag. In, case it's safe to use this command to force git to delete the branch. Although it is necessary to delete an unreachable delivery of the current branch, you know that the delivery can still have other branches or tags available. In this case, it is safe to force the deletion of a branch with this command.

git checkout <branch>

Make the current branch <branch>, updating the working directory to reflect the version referenced by <branch>

Extracts a branch, which is the contents of a reference <branch> version status update working directory

git checkout-b <new> <start-point>

Create a new branch <new> referencing <start-point>, and check it out.

Reference <start-point> Create a branch called <new>, and extract it.

The special symbol "head" can always is used to refer to the current branch. In fact, Git uses a file named ' head ' in the '. Git directory to remember which branch be current:

The special label "head" is always used as a reference, pointing to the current branch. In fact, Git is using the "head" file in the. git directory to remember that this is the current branch.

$ cat. Git/head
Ref:refs/heads/master

examining an old version without creating a new branch does not investigate older versions by creating a branch

The git-checkout command normally expects a branch head, but'll also accept an arbitrary commit; For example, can check out the commit referenced by a tag:

The git-checkout command extracts branch headers as usual, but can also accept arbitrary deliveries; For example, you can refer to a tag for extraction.

$ git checkout v2.6.17
note:moving to "v2.6.17" which isn ' t a local branch
If you want to create a new branch fro M this checkout, the later of the
using-b with the checkout command again. Example:
  git checkout-b <new_branch_name> head are now at
427ABFA ... Linux v2.6.17

The head then refers to the SHA1 of the commits instead of to a branch, and Git branch shows this are no longer on a BR Anch:

At this point, the head will point to the delivered SHA1 instead of the branch name, and the git branch command indicates that your current project status does not belong to any one branch:

$ cat. Git/head
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git Branch
* (no branch)
  Master

In this case we say the HEA