Git-0.99 README 第二部分 工作流

The Workflow
------------
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
index), but most operations move data to and from the index file. Either
from the database or from the working directory. Thus there are four
main combinations: 
通常，所有"Git"操作都工作于索引文件。一些操作只工作于索引文件(显示当前索引文件的状态)，但大部分操作都从索引文件中移出数据或移入数据。可以从数据库或工作目录。因此有四种主要的组合：


1) working directory -> index
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
工作目录到索引文件


You update the index with information from the working directory with
the link:git-update-cache.html[git-update-cache] command.  You
generally update the index information by just specifying the filename
you want to update, like so:
你可以通过git-update-cache命令使用工作目录更新索引文件。你通常更新索引信息通过给上述命令指定你需要更新的文件名，如下：


git-update-cache filename


but to avoid common mistakes with filename globbing etc, the command
will not normally add totally new entries or remove old entries,
i.e. it will normally just update existing cache entries.
但为了避免文件名globbing等常见错误，这个命令通常不会增加新的实体或移除旧的实体，它只会更新已存在缓存实例。


To tell git that yes, you really do realize that certain files no
longer exist in the archive, or that new files should be added, you
should use the "--remove" and "--add" flags respectively.
为了告诉git，你真的需要认识到当前的文件不再需要存在于归档中或新的文件需要添加，你必须使用"--remove"和"--add"参数。


NOTE! A "--remove" flag does _not_ mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
removed. The only thing "--remove" means is that update-cache will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
注："--remove"参数并不表示随后的文件名需要被移走：如果文件仍然存在于你的目录结构中，索引将更新该文件的最新状态，而不是移走。"--remove"只是表示更新缓存将认为一个移走的文件是可用的，如果该文件真正的不再存在，它将根据情况更新索引。


As a special case, you can also do "git-update-cache --refresh", which
will refresh the "stat" information of each index to match the current
stat information. It will _not_ update the object status itself, and
it will only update the fields that are used to quickly test whether
an object still matches its old backing store object.
特殊情况下，你可以使用"git-update-cache --refresh"，该命令将会刷新每个索引的状态信息以与当前状态信息相匹配。该命令不会更新对象自身的状态，只会更新用于快速测试的字段是否一个对象仍然与它旧的存储对象相匹配。


2) index -> object database
~~~~~~~~~~~~~~~~~~~~~~~~~~~
索引文件到对象数据库


You write your current index file to a "tree" object with the program
你使用git-write-tree程序将当前的索引文件写入到tree对象


git-write-tree


that doesn't come with any options - it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
other direction:
这个程序没有任何参数－该命令只是将当前的索引写入一组tree对象以描述当前状态并返回最高层结果树的名称。你可以在任意时间使用该树去重新生成索引。


3) object database -> index
~~~~~~~~~~~~~~~~~~~~~~~~~~~
对象数据库到索引文件


You read a "tree" file from the object database, and use that to
populate (and overwrite - don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index.  Normal operation is just
你从对象数据库中读取一个tree文件，并且使用该树文件来建立/重写（不要进行该操作如果你的索引中包含任何你没有保存并将在以后恢复状态）当前索引。通常操作如下：


git-read-tree <sha1 of tree>


and your index file will now be equivalent to the tree that you saved
earlier. However, that is only your _index_ file: your working
directory contents have not been modified.
操作完成后，你的索引文件的内容将是你以前保存的树的内容。虽然，这只是更新你的索引文件：你的工作目录内容并没有更改。


4) index -> working directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
索引到工作目录


You update your working directory from the index by "checking out"
files. This is not a very common operation, since normally you'd just
keep your files updated, and rather than write to your working
directory, you'd tell the index files about the changes in your
working directory (i.e. "git-update-cache").
你从索引中更新当前工作目录通过迁出文件。这个不是个常规操作，当你需要保持你的文件更新而不是写入到你的工作目录。你必须告诉索引文件关于你工作目录的改变（例如：git-update-cache）。


However, if you decide to jump to a new version, or check out somebody
else's version, or just restore a previous tree, you'd populate your
index file with read-tree, and then you need to check out the result
with
尽管，如果你决定跳到一个新的版本，或者迁出其它人的版本，或者恢复前面的一个树，你必须树中填允索引文件并且将结果迁出通过如下命令
git-checkout-cache filename


or, if you want to check out all of the index, use "-a".
或者，如果你需要迁出索引的所有内容，使用"-a"。


NOTE! git-checkout-cache normally refuses to overwrite old files, so
if you have an old version of the tree already checked out, you will
need to use the "-f" flag (_before_ the "-a" flag or the filename) to
_force_ the checkout.
注：git-checkout-cache通常会拒绝重写旧文件，如果你有一个旧的已迁出的版本树，你必须使用"-f"标志来强制迁出。




Finally, there are a few odds and ends which are not purely moving
from one representation to the other:
最后，还有一些不是纯粹的从一个数据表达到别一个表达的移动


5) Tying it all together
~~~~~~~~~~~~~~~~~~~~~~~~
To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
behind it - most notably the "parent" commits that preceded it in
history.
为了提交一个树你必须通过"git-write-tree"，你将创建一个commit对象引用该tree对象以及提交历史——大部分父提交将在历史中被处理。


Normally a "commit" has one parent: the previous state of the tree
before a certain change was made. However, sometimes it can have two
or more parent commits, in which case we call it a "merge", due to the
fact that such a commit brings together ("merges") two or more
previous states represented by other commits.
通常一个commit对象有一个父对象：在改变之前的一个树状态。尽管，一些时候可以有二个或多个父提交对象，在这种情况下，我们称之为“合并”。


In other words, while a "tree" represents a particular directory state
of a working directory, a "commit" represents that state in "time",
and explains how we got there.
换句话说，当一个tree表示一个工作目录下的特殊的目录状态，commit对象表示实时的反映该状态并解释我们是如何到达该状态的。


You create a commit object by giving it the tree that describes the
state at the time of the commit, and a list of parents:
你可以创建一个commit对象通过传递给它一个你能表示你提交时状态的树并列出它们的父树对象：


git-commit-tree <tree> -p <parent> [-p <parent2> ..]


and then giving the reason for the commit on stdin (either through
redirection from a pipe or file, or by just typing it at the tty).
以及给出进行本次提交的原因。


git-commit-tree will return the name of the object that represents
that commit, and you should save it away for later use. Normally,
you'd commit a new "HEAD" state, and while git doesn't care where you
save the note about that state, in practice we tend to just write the
result to the file ".git/HEAD", so that we can always see what the
last committed state was.
git-commit-tree将返回表出本次提交的commit对象的名称，你应该将其保存起来以备后用。通常，你将提交一个新的"HEAD"状态，git并不关心你在哪里存储该状态的注释，在实际中我们倾向于将结果写入到".git/HEAD"文件中，于是我们总是能查看最后一次提交的状态。


6) Examining the data
~~~~~~~~~~~~~~~~~~~~~


You can examine the data represented in the object database and the
index with various helper tools. For every object, you can use
link:git-cat-file.html[git-cat-file] to examine details about the
object:
你可以检查在对象数据库和索引中的数据通过不同的帮助工具。对于每一个对象，你可以使用git-cat-file命令以检查对象的详细内容：


git-cat-file -t <objectname>


shows the type of the object, and once you have the type (which is
usually implicit in where you find the object), you can use
显示该对象的类型，一旦你拥有了类型（通常隐式的位于你找到对象的位置），你可以使用


git-cat-file blob|tree|commit <objectname>


to show its contents. NOTE! Trees have binary content, and as a result
there is a special helper for showing that content, called
"git-ls-tree", which turns the binary content into a more easily
readable form.
来显示该对象的内容。注：tree对象有二进制内容，有一个特殊的帮助命令可以帮助你显示其内容：git-ls-tree，该命令将二进制内容转化成更易读的形式。


It's especially instructive to look at "commit" objects, since those
tend to be small and fairly self-explanatory. In particular, if you
follow the convention of having the top commit name in ".git/HEAD",
you can do
通常查看commit对象特别有帮助，该操作会将显示出很小并有效的自说明。如果你需要跟踪位于".git/HEAD"中最顶层的提交名，你可以


git-cat-file commit $(cat .git/HEAD)


to see what the top commit was.
查看最顶层的提交。


7) Merging multiple trees
~~~~~~~~~~~~~~~~~~~~~~~~~


Git helps you do a three-way merge, which you can expand to n-way by
repeating the merge procedure arbitrary times until you finally
"commit" the state.  The normal situation is that you'd only do one
three-way merge (two parents), and commit it, but if you like to, you
can do multiple parents in one go.
Git帮助你进行三方合并，你可以在任意时间扩展到多方通过重复执行合并处理直到你达到最终的提交状态。通常情况下你中进行三方合并（两个父对象）并进行提交。但是如果你愿意，你可以进行多个父进行合并。


To do a three-way merge, you need the two sets of "commit" objects
that you want to merge, use those to find the closest common parent (a
third "commit" object), and then use those commit objects to find the
state of the directory ("tree" object) at these points.
要进行三方合并，你必须有二组需要进行合并的commit对象，找个它们最近的共同父对象（第三个commit对象）并使用这些commit对象找到当时目录（tree对象）的状态。


To get the "base" for the merge, you first look up the common parent
of two commits with
要找到合并的基础，你首先必须找到两个提交的共同父对象通过


git-merge-base <commit1> <commit2>


which will return you the commit they are both based on.  You should
now look up the "tree" objects of those commits, which you can easily
do with (for example)
该命令将返回两个提交的共同基础。然后你会查看这些提交对象的tree对象，你很容易通过


git-cat-file commit <commitname> | head -1


since the tree object information is always the first line in a commit
object.
tree对象的信息总是显示在commit对象的第一行。


Once you know the three trees you are going to merge (the one
"original" tree, aka the common case, and the two "result" trees, aka
the branches you want to merge), you do a "merge" read into the
index. This will throw away your old index contents, so you should
make sure that you've committed those - in fact you would normally
always do a merge against your last commit (which should thus match
what you have in your current index anyway).
一旦你知道三个tree要进行合并，你使用"merge"读入到索引文件。该操作将丢弃索引中原有的内容，你必须确认你对其内容进行了提交——事实上你应该在最后一次提交到进行合并操作。


To do the merge, do
要进行合并，使用


git-read-tree -m <origtree> <target1tree> <target2tree>


which will do all trivial merge operations for you directly in the
index file, and you can just write the result out with
"git-write-tree".
该命令将为你在索引文件中进行全部琐细的合并操作，你只需要将结果通过git-write-tree写入。


NOTE! Because the merge is done in the index file, and not in your
working directory, your working directory will no longer match your
index. You can use "git-checkout-cache -f -a" to make the effect of
the merge be seen in your working directory.
注：因为合并操作在索引文件中完成，而不是在你的工作目录，所有你的工作目录将不再与在的索引匹配。你可以使用"git-checkout-cache -f -a"将合并的结果写入到你的工作目录。


NOTE2! Sadly, many merges aren't trivial. If there are files that have
been added.moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can _NOT_ be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
注：不幸的是，许多合并操作并不琐细。如果有文件被添加，移动或删除，或者两个分支全部修改了同一个文件，你将会得到一个包含合并实体的索引树。该索引树并不能写入到tree对象，你将要去使用其它的工具解决所有的合并冲突在你可以写入结果之前。