diff options
author | Holger Weiss <holger@zedat.fu-berlin.de> | 2014-01-11 21:45:56 (GMT) |
---|---|---|
committer | Holger Weiss <holger@zedat.fu-berlin.de> | 2014-01-11 21:45:56 (GMT) |
commit | 3cdb38519cf9ac94b20b9eba6e4195f7e7674de7 (patch) | |
tree | 42532a09924d4b8a7014f909b6bab9f40072f54a /web | |
parent | df26d5827b8118c01ef203b5e87833d3d7b7434b (diff) | |
download | site-3cdb38519cf9ac94b20b9eba6e4195f7e7674de7.tar.gz |
doc/faq/git.md: Add clarifications regarding index
Clarify the purpose of the staging area, and (try to) improve the "Basic
Concepts" section in another few ways.
Diffstat (limited to 'web')
-rw-r--r-- | web/input/doc/faq/git.md | 37 |
1 files changed, 20 insertions, 17 deletions
diff --git a/web/input/doc/faq/git.md b/web/input/doc/faq/git.md index 71200c8..53260ec 100644 --- a/web/input/doc/faq/git.md +++ b/web/input/doc/faq/git.md | |||
@@ -15,23 +15,26 @@ we can’t have a central shared Git repository (and we indeed have one), this | |||
15 | means distributed development can occur around that central repository. | 15 | means distributed development can occur around that central repository. |
16 | 16 | ||
17 | Git has an additional stage between the working directory and the repository. | 17 | Git has an additional stage between the working directory and the repository. |
18 | When you want to add files or changes, you use | 18 | The idea is that you might be working on multiple unrelated things without |
19 | **git add**. This adds the changes to the repository index, which can be seen | 19 | wanting to commit all changes in one go. Therefore, the changes that should |
20 | as a staging area. When you commit with **git commit**, only the changes in | 20 | be committed must first be added to the repository *index*, which can be seen |
21 | the index are considered. After committing, the changes are still local. To | 21 | as a staging area. This is usually done with **git add**, both for new files |
22 | share it with others, you have to push it to a remote repository, or gave | 22 | *and* for changes to existing ones. When you commit using **git commit**, |
23 | someone pull from your publicly accessible repository (in most case you will | 23 | only the changes in the index are considered. |
24 | still have to push changes there, unless if you were running a git daemon | 24 | |
25 | straight off your working repository). | 25 | After committing, the changes are still local. To share them with others, you |
26 | 26 | have to push them to a remote repository, or have someone pull from your | |
27 | Finally you can’t miss the fact that | 27 | publicly accessible repository (in most cases you will still have to push |
28 | there is no more revision numbers, and the distributed nature of Git is the | 28 | changes there, unless if you were running a git daemon straight off your |
29 | reason for that: there is absolutely no way a single number could be tracked | 29 | working repository). |
30 | in a distributed way. Instead Git uses SHA1 hashes to identify commits (as | 30 | |
31 | well as other objects in the repository). Each branch and tag refer to an | 31 | Finally, you can’t miss the fact that there are no revision numbers, and the |
32 | object name (SHA1 hash), and each commits have one or more parents (commit | 32 | distributed nature of Git is the reason for that: there is absolutely no way a |
33 | objects). Although SHA1 hashes are 40 digits long, with Git you only have to | 33 | single number could be tracked in a distributed way. Instead, Git uses SHA1 |
34 | type a handful of digits to reference one. | 34 | hashes to identify commits (as well as other objects in the repository). Each |
35 | branch and tag refer to an object name (SHA1 hash), and each commits have one | ||
36 | or more parents (commit objects). Although SHA1 hashes are 40 digits long, | ||
37 | with Git you only have to type a handful of digits to reference one. | ||
35 | 38 | ||
36 | ## Cloning a Project | 39 | ## Cloning a Project |
37 | 40 | ||