From 3f2ec176672003b9bcbd25f2e63c1537e869f275 Mon Sep 17 00:00:00 2001 From: Tran Dinh Anh Tuan Date: Tue, 14 Jan 2014 11:04:44 +0700 Subject: [PATCH 1/4] Add Vietnamese Translation Template --- _layouts/vi_reference.html | 107 ++++ vi/basic/index.html | 973 +++++++++++++++++++++++++++++++++++++ vi/branching/index.html | 864 ++++++++++++++++++++++++++++++++ vi/cookbook.html | 12 + vi/creating/index.html | 142 ++++++ vi/images/snapshots.png | Bin 0 -> 23231 bytes vi/index.html | 119 +++++ vi/inspect/index.html | 475 ++++++++++++++++++ vi/remotes/index.html | 440 +++++++++++++++++ 9 files changed, 3132 insertions(+) create mode 100644 _layouts/vi_reference.html create mode 100644 vi/basic/index.html create mode 100644 vi/branching/index.html create mode 100644 vi/cookbook.html create mode 100644 vi/creating/index.html create mode 100644 vi/images/snapshots.png create mode 100644 vi/index.html create mode 100644 vi/inspect/index.html create mode 100644 vi/remotes/index.html diff --git a/_layouts/vi_reference.html b/_layouts/vi_reference.html new file mode 100644 index 0000000..c6916d5 --- /dev/null +++ b/_layouts/vi_reference.html @@ -0,0 +1,107 @@ + + + + + Tham Khảo Git + + + + + + + + + + + + +
+ +
+ Tham Khảo Git +
+ +
+ +
+   +
+ + + +
+ {{ content }} +
+ +
+
+ + diff --git a/vi/basic/index.html b/vi/basic/index.html new file mode 100644 index 0000000..6c765b5 --- /dev/null +++ b/vi/basic/index.html @@ -0,0 +1,973 @@ +--- +layout: reference +--- + +
+

+ + book + + Basic Snapshotting +

+
+

+ Git is all about composing and saving snapshots of your project and then + working with and comparing those snapshots. This section will explain + the commands needed to compose and commit snapshots of your project. +

+ +

+ An important concept here is that Git has an 'index', which acts as sort + of a staging area for your snapshot. This allows you to build up a series + of well composed snapshots from changed files in your working directory, + rather than having to commit all of the file changes at once. +

+ +

+ In a nutshell, you will use git add to start tracking new + files and also to stage changes to already tracked files, then + git status and git diff to see what has been + modified and staged and finally git commit to record your + snapshot into your history. This will be the basic workflow that you use + most of the time. +

+ +
+
+ +
+

+ + docs   + book + + git add + adds file contents to the staging area +

+ +
+

+ In Git, you have to add file contents to your staging area before you + can commit them. If the file is new, you can run git add + to initially add the file to your staging area, but even if the file + is already "tracked" - ie, it was in your last commit - you still need + to call git add to add new modifications to your staging + area. Let's see a few examples of this. +

+ +

Going back to our Hello World example, once we've initiated the project, + we would now start adding our files to it and we would do that with + git add. We can use git status to see what the + state of our project is. +

+ +
+$ git status -s
+?? README
+?? hello.rb
+
+ + So right now we have two untracked files. We can now add them. + +
+$ git add README hello.rb
+
+ + Now if we run git status again, we'll see that they've been + added. + +
+$ git status -s
+A  README
+A  hello.rb
+
+ +

+ It is also common to recursively add all files in a new project by specifying + the current working directory like this: git add .. Since Git + will recursively add all files under a directory you give it, if you give it + the current working directory, it will simply start tracking every file + there. In this case, a git add . would have done the same + thing as a git add README hello.rb, or for that matter so would + git add *, but that's only because we don't have subdirectories + which the * would not recurse into. +

+ +

OK, so now if we edit one of these files and run git status + again, we will see something odd.

+
+$ vim README
+$ git status -s
+AM README
+A  hello.rb
+
+ +

The 'AM' status means that the file has been modified on disk since we + last added it. This means that if we commit our snapshot right now, we will + be recording the version of the file when we last ran git add, + not the version that is on our disk. Git does not assume that what the file + looks like on disk is necessarily what you want to snapshot - you have to + tell Git with the git add command. +

+ +

+ In a nutshell, + you run git add on a file when you want to + include whatever changes you've made to it in your next commit snapshot. + Anything you've changed that is not added will not be included - this means + you can craft your snapshots with a bit more precision than most other SCM + systems.

+ +

For a very interesting example of using this flexibility to stage only + parts of modified files at a time, see the '-p' option to + git add in the Pro Git book.

+ + +
+ +
+ +
+

+ + docs   + book + + git status + view the status of your files in the working directory and staging area +

+ +
+

As you saw in the git add section, in order to see what the + status of your staging area is compared to the code in your working + directory, you can run the git status command. Using the + -s option will give you short output. + Without that flag, the git status command will give you more + context and hints. Here is the same status output with and without the + -s. The short output looks like this: +

+ +
+$ git status -s
+AM README
+A  hello.rb
+
+ + Where the same status with the long output looks like this: + +
+$ git status
+# On branch master
+#
+# Initial commit
+#
+# Changes to be committed:
+#   (use "git rm --cached <file>..." to unstage)
+#
+# new file:   README
+# new file:   hello.rb
+#
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   README
+#
+
+ +

You can easily see how much more compact the short output is, but the + long output has useful tips and hints as to what commands you may want to + use next. +

+ +

Git will also tell you about files that were deleted since your last + commit or files that were modified or staged since your last commit.

+ +
+$ git status -s
+M  README
+ D hello.rb
+
+ + You can see there are two columns in the short status output. The first + column is for the staging area, the second is for the working directory. + So for example, if you have the README file staged and then you modify + it again without running git add a second time, you'll see + this: + +
+$ git status -s
+MM README
+ D hello.rb
+
+ +

+ In a nutshell, + you run git status to see if anything has been modified + and/or staged since your last commit so you can decide if you want to + commit a new snapshot and what will be recorded in it. +

+ +
+
+ +
+

+ + docs   + book + + git diff + shows diff of what is staged and what is modified but unstaged +

+ +
+

There are two main uses of the git diff command. One use we + will describe here, the other we will describe later in the + "Inspection and Comparison" + section. The way we're going to use it here is to describe the + changes that are staged or modified on disk but unstaged.

+ +

+ git diff + show diff of unstaged changes +

+ +

Without any extra arguments, a simple git diff will display + in unified diff format (a patch) what code or content you've changed in your + project since the last commit that are not yet staged for the next commit + snapshot. +

+ +
+$ vim hello.rb
+$ git status -s
+ M hello.rb
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

So where git status will show you what files have changed + and/or been staged since your last commit, git diff will + show you what those changes actually are, line by line. It's generally + a good follow-up command to git status +

+ +

+ git diff --cached + show diff of staged changes +

+ +

The git diff --cached command will show you what contents + have been staged. That is, this will show you the changes that will + currently go into the next commit snapshot. So, if you were to stage + the change to hello.rb in the example above, + git diff by itself won't show you any output because it will + only show you what is not yet staged. +

+ +
+$ git status -s
+ M hello.rb
+$ git add hello.rb 
+$ git status -s
+M  hello.rb
+$ git diff
+$ 
+
+ +

If you want to see the staged changes, you can run + git diff --cached instead.

+ +
+$ git status -s
+M  hello.rb
+$ git diff
+$ 
+$ git diff --cached
+diff --git a/hello.rb b/hello.rb
+index d62ac43..8d15d50 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

+ git diff HEAD + show diff of all staged or unstaged changes +

+ +

If you want to see both staged and unstaged changes together, you + can run git diff HEAD - this basically means you want to + see the difference between your working directory and the last commit, + ignoring the staging area. If we make another change to our + hello.rb file then we'll have some changes staged and some + changes unstaged. Here are what all three diff commands + will show you:

+
+$ vim hello.rb 
+$ git diff
+diff --git a/hello.rb b/hello.rb
+index 4f40006..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
++  # says hello
+   def self.hello
+     puts "hola mundo"
+   end
+
+ end
+$ git diff --cached
+diff --git a/hello.rb b/hello.rb
+index 2aabb6e..4f40006 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+$ git diff HEAD
+diff --git a/hello.rb b/hello.rb
+index 2aabb6e..2ae9ba4 100644
+--- a/hello.rb
++++ b/hello.rb
+@@ -1,7 +1,8 @@
+ class HelloWorld
+
++  # says hello
+   def self.hello
+-    puts "hello world"
++    puts "hola mundo"
+   end
+
+ end
+
+ +

+ git diff --stat + show summary of changes instead of a full diff +

+ +

If we don't want the full diff output, but we want more than the + git status output, we can use the --stat + option, which will give us a summary of changes instead. Here is the + same example as above, but using the --stat option instead. +

+ +
+$ git status -s
+MM hello.rb
+$ git diff --stat
+ hello.rb |    1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+$ git diff --cached --stat
+ hello.rb |    2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+$ git diff HEAD --stat
+ hello.rb |    3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

+ You can also provide a file path at the end of any of these options + to limit the diff output to a specific file or subdirectory. +

+ + +

+ In a nutshell, + you run git diff to see details of the git status + command - how files have been modified or staged on a line by line + basis. +

+ + +
+
+ +
+

+ + docs   + book + + git commit + records a snapshot of the staging area +

+ +
+ +

Now that you have staged the content you want to snapshot with the + git add command, you run git commit to actually + record the snapshot. + Git records your name and email address with every commit you make, + so the first step is to tell Git what these are. +

+ +
+$ git config --global user.name 'Your Name'
+$ git config --global user.email you@somedomain.com
+
+ +

Let's stage and commit all the changes to our + hello.rb file. In this first example, we'll use the + -m option to provide the commit message on the command line. +

+ +
+$ git add hello.rb 
+$ git status -s
+M  hello.rb
+$ git commit -m 'my hola mundo changes'
+[master 68aa034] my hola mundo changes
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

Now we have recorded the snapshot. If we run git status + again, we will see that we have a "clean working directory", which means + that we have not made any changes since our last commit - there is no + un-snapshotted work in our checkout.

+ +
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

If you leave off the -m option, Git will try to open a + text editor for you to write your commit message. In vim, + which it will default to if it can find nothing else in your settings, + the screen might look something like this: +

+ +
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   hello.rb
+#
+~
+~
+".git/COMMIT_EDITMSG" 9L, 257C
+
+ +

At this point you add your actual commit message at the top of the + document. Any lines starting with '#' will be ignored - Git will put + the output of the git status command in there for you as + a reminder of what you have modified and staged.

+ +

In general, it's very important to write a good commit message. + For open source projects, it's generally a rule to write your message + more or less in this format:

+ +
+Short (50 chars or less) summary of changes
+
+More detailed explanatory text, if necessary.  Wrap it to about 72
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); some git tools can get confused if you run the
+two together.
+
+Further paragraphs come after blank lines.
+
+ - Bullet points are okay, too
+
+ - Typically a hyphen or asterisk is used for the bullet, preceded by a
+   single space, with blank lines in between, but conventions vary
+   here
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   hello.rb
+#
+~
+~
+~
+".git/COMMIT_EDITMSG" 25L, 884C written
+
+ +

+ The commit message is very important. Since much of the power of + Git is this flexibility in carefully crafting commits locally and then + sharing them later, it is very powerful to be able to write three or + four commits of logically separate changes so that your work may be more + easily peer reviewed. Since there is a separation between committing and + pushing those changes, do take the time to make it easier for the people + you are working with to see what you've done by putting each logically + separate change in a separate commit with a nice commit message so it + is easier for them to see what you are doing and why.

+ +

+ git commit -a + automatically stage all tracked, modified files before the commit +

+ +

If you think the git add stage of the workflow is too + cumbersome, Git allows you to skip that part with the -a + option. This basically tells Git to run git add on any file + that is "tracked" - that is, any file that was in your last commit and + has been modified. This allows you to do a more Subversion style workflow + if you want, simply editing files and then running git commit -a + when you want to snapshot everything that has been changed. You still need + to run git add to start tracking new files, though, just like + Subversion. +

+ +
+$ vim hello.rb
+$ git status -s
+ M  hello.rb
+$ git commit -m 'changes to hello file'
+# On branch master
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   hello.rb
+#
+no changes added to commit (use "git add" and/or "git commit -a")
+$ git commit -am 'changes to hello file'
+[master 78b2670] changes to hello file
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+ +

Notice how if you don't stage any changes and then run + git commit, Git will simply give you the output of the + git status command, reminding you that nothing is staged. + The important part of that message has been highlighted, saying that nothing + is added to be committed. If you use -a, it will add and + commit everything at once. +

+ +

This now lets you complete the entire snapshotting workflow - you + make changes to your files, then use git add to stage + files you want to change, git status and git diff + to see what you've changed, and then finally git commit + to actually record the snapshot forever.

+ +

+ In a nutshell, + you run git commit to record the snapshot of your staged + content. This snapshot can then be compared, shared and reverted to + if you need to. +

+ +
+
+ +
+

+ + docs   + book + + git reset + undo changes and commits +

+ +
+

git reset is probably the most confusing command written + by humans, but it can be very useful once you get the hang of it. + There are three specific invocations of it that are generally + helpful. +

+ +

+ git reset HEAD + unstage files from index and reset pointer to HEAD +

+ +

First, you can use it to unstage something that has been + accidentally staged. Let's say that you have modified two files and want + to record them into two different commits. You should stage and commit + one, then stage and commit the other. If you accidentally stage both of + them, how do you un-stage one? You do it with + git reset HEAD -- file. Technically you don't have to + add the -- - it is used to tell Git when you have stopped + listing options and are now listing file paths, but it's probably good to + get into the habit of using it to separate options from paths even if you + don't need to. +

+ +

Let's see what it looks like to unstage something. Here we have + two files that have been modified since our last commit. We will stage + both, then unstage one of them.

+ +
+$ git status -s
+ M README
+ M hello.rb
+$ git add .
+$ git status -s
+M  README
+M  hello.rb
+$ git reset HEAD -- hello.rb 
+Unstaged changes after reset:
+M hello.rb
+$ git status -s
+M  README
+ M hello.rb
+
+ +

Now you can run a git commit which will just record + the changes to the README file, not the now unstaged + hello.rb. +

+ +

+ In case you're curious, what it's actually doing here is it is resetting + the checksum of the entry for that file in the "index" to be what it was + in the last commit. Since git add checksums a file and adds + it to the "index", git reset HEAD overwrites that with what + it was before, thereby effectively unstaging it. +

+ +

+ If you want to be able to just run git unstage, you can easily + setup an alias in Git. Just run + git config --global alias.unstage "reset HEAD". + Once you have run that, you can then just run + git unstage [file] instead. +

+ +

If you forget the command to unstage something, Git is helpful in + reminding you in the output of the normal git status + command. For example, if you run git status without + the -s when you have staged files, it will tell you + how to unstage them:

+ +
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#   modified:   README
+#   modified:   hello.rb
+#
+
+ +

When you run git reset without specifying a flag + it defaults to --mixed. The other options are + --soft and --hard.

+ +

+ git reset --soft + moves HEAD to specified commit reference, index and staging are untouched +

+ +

The first thing git reset does is undo the last + commit and put the files back onto the stage. If you include the + --soft flag this is where it stops. For example, + if you run git reset --soft HEAD~ (the parent of the + HEAD) the last commit will be undone and the files touched + will be back on the stage again.

+ +
+$ git status -s
+M  hello.rb
+$ git commit -am 'hello with a flower'
+[master 5857ac1] hello with a flower
+ 1 files changed, 3 insertions(+), 1 deletions(-)
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+$ git reset --soft HEAD~
+$ git status -s
+M  hello.rb
+
+ +

This is basically doing the same thing as + git commit --amend, allowing you to do more work + before you roll in the file changes into the same commit.

+ +

+ git reset --hard + unstage files AND undo any changes in the working directory since last commit +

+ +

The third option is to go --hard and make your working + directory look like the index, unstage files and undo any changes made + since the last commit. + This is the most dangerous option and not working directory safe. Any + changes not in the index or have not been commited will be lost.

+ +
+$ git status
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+# modified:   README
+#
+# Changes not staged for commit:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   README
+#
+$ git reset --hard HEAD
+HEAD is now at 5857ac1 hello with a flower
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

In the above example, while we had both changes ready to commit and + ready to stage, a git reset --hard wiped them out. + The working tree and staging area are reset to the tip of the current + branch or HEAD.

+ +

You can replace HEAD with a commit SHA-1 or another + parent reference to reset to that specific point.

+ +

+ In a nutshell, + you run git reset HEAD to undo the last commit, unstage + files that you previously ran git add on and wish to not + include in the next commit snapshot

+ +
+
+ +
+

+ + docs   + book + + git rm + remove files from the staging area +

+ +
+ +

git rm will remove entries from the staging area. + This is a bit different from git reset HEAD which "unstages" + files. To "unstage" means it reverts the staging area to what was + there before we started modifying things. git rm on the + other hand just kicks the file off the stage entirely, so that it's not + included in the next commit snapshot, thereby effectively deleting it.

+ +

By default, a git rm file will remove the file from the + staging area entirely and also off your disk (the working directory). To + leave the file in the working directory, you can use git rm --cached + .

+ +

+ git mv + git rm --cached orig; mv orig new; git add new +

+ +

+ Unlike most other version control systems, Git does not track file renames. + Instead, it just tracks the snapshots and then figures out what files were + likely renamed by comparing snapshots. If a file was removed from one + snapshot and another file was added to the next one and the contents are + similar, Git figures it was most likely a rename. So, although the + git mv command exists, it is superfluous - all it does is a + git rm --cached, moves the file on disk, then runs a + git add on the new file. You don't really need to use it, but + if it's easier, feel free. +

+ +

+ In its normal form the command is used to delete files. + But it's often easier to just remove the files off your disk and + then run git commit -a, which will also automatically remove + them from your index.

+ +

+ In a nutshell, + you run git rm to remove files from being tracked in Git. It + will also remove them from your working directory. +

+ +
+
+ +
+

+ + docs   + book + + git stash + save changes made in the current index and working directory for later +

+ +
+ +

You're in the middle of some changes but something comes up that you + need to jump over to, like a so-urgent-right-now bugfix, but don't want + to commit or lose your current edits. git stash is there for you. +

+ +

+ git stash + add current changes to the stack +

+ +

Stashing takes the current state of the working directory and index, + puts it on a stack for later, and gives you back a clean working directory. + It will then leave you at the state of the last commit. +

+ +

If you have untracked files, git stash will not include + them. You can either stage those files with git add (you don't + have to commit) before stashing, or, if you have a recent Git version + (1.7.7 or above), you can use git stash -u to also stash also + unversioned files.

+ +
+$ git status -s
+M hello.rb
+$ git stash
+Saved working directory and index state WIP on master: 5857ac1 hello with a flower
+HEAD is now at 5857ac1 hello with a flower
+$ git status
+# On branch master
+nothing to commit (working directory clean)
+
+ +

+ git stash list + view stashes currently on the stack +

+ +

It's helpful to know what you've got stowed on the stash and this is where + git stash list comes in. Running this command will display a queue + of current stash items. +

+ +
+$ git stash list
+stash@{0}: WIP on master: 5857ac1 hello with a flower
+
+ +

The last item added onto the stash will be referenced by + stash@{0} and increment those already there by one. +

+ +
+$ vim hello.rb
+$ git commit -am 'it stops raining'
+[master ee2d2c6] it stops raining
+1 files changed, 1 insertions(+), 1 deletions(-)
+$ vim hello.rb
+$ git stash
+Saved working directory and index state WIP on master: ee2d2c6 it stops raining
+HEAD is now at ee2d2c6 it stops raining
+$ git stash list
+stash@{0}: WIP on master: ee2d2c6 it stops raining
+stash@{1}: WIP on master: 5857ac1 hello with a flower
+
+ +

+ git stash apply + grab the item from the stash list and apply to current working directory +

+ +

When you're ready to continue from where you left off, run the + git stash apply command to bring back the saved changes + onto the working directory. +

+ +
+$ git stash apply
+# On branch master
+# Changes not staged for commit:
+#   (use "git add <file>..." to update what will be committed)
+#   (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# modified:   hello.rb
+#
+no changes added to commit (use "git add" and/or "git commit -a")
+
+ +

By default it will reapply the last added stash item to the working + directory. This will be the item referenced by stash@{0}. + You can grab another stash item instead if you reference it in the arguments + list. For example, git stash apply stash@{1} will apply the item + referenced by stash@{1}. +

+ +

If you also want to remove the item from the stack at the same time, + use git stash pop instead. +

+ +

+ git stash drop + remove an item from the stash list +

+ +

When you're done with the stashed item and/or want to remove it from the + list, run the git stash drop command. By default this will + remove the last added stash item. You can also remove a specific item if + you include it as an argument. +

+ +

In this example, our stash list has at least two items, but we want + to get rid of the item added before last, which is referenced by + stash@{1}. +

+ +
+$ git stash drop stash@{1}
+Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
+
+ +

If you want to remove of all the stored items, just run + the git stash clear command. But only do this if you're + sure you're done with the stash. +

+ +

+ In a nutshell, run git stash to quickly save + some changes that you're not ready to commit or save, but want to come + back to while you work on something else. +

+ +
+
+ +

On to Branching and Merging »

+ diff --git a/vi/branching/index.html b/vi/branching/index.html new file mode 100644 index 0000000..27fd588 --- /dev/null +++ b/vi/branching/index.html @@ -0,0 +1,864 @@ +--- +layout: reference +--- + +
+

+ + book + + Branching and Merging +

+
+

Branching in Git is one of its many great features. If you have used other + version control systems, it's probably helpful to forget most of what you + think about branches - in fact, it may be more helpful to think of them + practically as contexts since that is how you will most often be + using them. When you checkout different branches, you change contexts + that you are working in and you can quickly context-switch back and forth + between several different branches. +

+ +

+ In a nutshell you can create a branch with + git branch (branchname), switch into that context with + git checkout (branchname), record commit snapshots while + in that context, then can switch back and forth easily. When you switch + branches, Git replaces your working directory with the snapshot of the + latest commit on that branch so you don't have to have multiple directories + for multiple branches. You merge branches together with + git merge. You can easily merge multiple times from the same + branch over time, or alternately you can choose to delete a branch + immediately after merging it. +

+ +
+
+ +
+

+ + docs   + book + + git branch + list, create and manage working contexts +

+ +
+ +

+ + docs   + book + + git checkout + switch to a new branch context +

+ +
+

The git branch command is a general branch management tool + for Git and can do several different things. We'll cover the basic ones + that you'll use most - listing branches, creating branches and deleting + branches. We will also cover basic git checkout here which + switches you between your branches. +

+ +

+ git branch + list your available branches +

+ +

Without arguments, git branch will list out the local + branches that you have. The branch that you are currently working on will + have a star next to it and if you have + coloring turned on, + will show the current branch in green. +

+ +
+$ git branch
+* master
+
+ +

This means that we have a 'master' branch and we are currently on it. + When you run git init it will automatically create a 'master' + branch for you by default, however there is nothing special about the name - + you don't actually have to have a 'master' branch but since it's the default + that is created, most projects do. +

+ +

+ git branch (branchname) + create a new branch +

+ +

So let's start by creating a new branch and switching to it. You can do + that by running git branch (branchname). +

+ +
+$ git branch testing
+$ git branch
+* master
+  testing
+
+ +

Now we can see that we have a new branch. When you create a branch this + way it creates the branch at your last commit so if you record some commits + at this point and then switch to 'testing', it will revert your working + directory context back to when you created the branch in the first place - + you can think of it like a bookmark for where you currently are. Let's see + this in action - we use git checkout (branch) to switch the + branch we're currently on. +

+ +
+$ ls
+README   hello.rb
+$ echo 'test content' > test.txt
+$ echo 'more content' > more.txt
+$ git add *.txt
+$ git commit -m 'added two files'
+[master 8bd6d8b] added two files
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+ create mode 100644 more.txt
+ create mode 100644 test.txt
+$ ls
+README   hello.rb more.txt test.txt
+$ git checkout testing
+Switched to branch 'testing'
+$ ls
+README   hello.rb
+
+ +

So now we can see that when we switch to the 'testing' branch, our new + files were removed. We could switch back to the 'master' branch and see + them re-appear.

+ +
+$ ls
+README   hello.rb
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README   hello.rb more.txt test.txt
+
+ +

+ git branch -v + see the last commit on each branch +

+ +

If we want to see last commits on each branch + we can run git branch -v to see them.

+ +
+$ git branch -v
+* master      54b417d fix javascript issue
+  development 74c111d modify component.json file
+  testing     62a557a update test scripts
+
+ +

+ git checkout -b (branchname) + create and immediately switch to a branch +

+ +

+ In most cases you will be wanting to switch to the branch immediately, so + you can do work in it and then merging into a branch that only contains + stable work (such as 'master') at a later point when the work in your new + context branch is stable. You can do this pretty easily with + git branch newbranch; git checkout newbranch, but Git gives + you a shortcut for this: git checkout -b newbranch. +

+ +
+$ git branch
+* master
+$ ls
+README   hello.rb more.txt test.txt
+$ git checkout -b removals
+Switched to a new branch 'removals'
+$ git rm more.txt 
+rm 'more.txt'
+$ git rm test.txt 
+rm 'test.txt'
+$ ls
+README   hello.rb
+$ git commit -am 'removed useless files'
+[removals 8f7c949] removed useless files
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README   hello.rb more.txt test.txt
+
+ +

You can see there how we created a branch, removed some of our files + while in the context of that branch, then switched back to our main branch + and we see the files return. Branching safely isolates work that we do into + contexts we can switch between.

+ +

+ If you start on work it is very useful to + always start it in a branch (because it's fast and easy to do) and then + merge it in and delete the branch when you're done. That way if what you're + working on doesn't work out you can easily discard it and if you're forced + to switch back to a more stable context your work in progress is easy to put + aside and then come back to.

+ +

+ git branch -d (branchname) + delete a branch +

+ +

If we want to delete a branch (such as the 'testing' branch in the + previous example, since there is no unique work on it), + we can run git branch -d (branch) to remove it.

+ +
+$ git branch
+* master
+  testing
+$ git branch -d testing
+Deleted branch testing (was 78b2670).
+$ git branch
+* master
+
+ +

+ git push (remote-name) :(branchname) + delete a remote branch +

+ +

When you're done with a remote branch, whether it's been merged + into the remote master or you want to abandon it and sweep it under + the rug, you'll issue a git push command with a specially + placed colon symbol to remove that branch.

+ +
+$ git push origin :tidy-cutlery
+To git@github.com:octocat/Spoon-Knife.git
+ - [deleted]         tidy-cutlery
+
+ +

In the above example you've deleted the "tidy-cutlery" branch + of the "origin" remote. A way to remember this is to think of the + git push remote-name local-branch:remote-branch syntax. + This states that you want to push your local branch to match that + of the remote. When you remove the local-branch portion + you're now matching nothing to the remote, effectively telling the + remote branch to become nothing. +

+ +

Alternatively, you can run + git push remote-name --delete branchname + which is a wrapper for the colon refspec (a source:destination pair) + of deleting a remote branch. +

+ +

+ In a nutshell you use git branch to list your + current branches, create new branches and delete unnecessary or + already merged branches. +

+ +
+
+ +
+

+ + docs   + book + + git merge + merge a branch context into your current one +

+ +
+

Once you have work isolated in a branch, you will eventually want to + incorporate it into your main branch. You can merge any branch into your + current branch with the git merge command. Let's take as a + simple example the 'removals' branch from above. If we create a branch + and remove files in it and commit our removals to that branch, it is + isolated from our main ('master', in this case) branch. To include those + deletions in your 'master' branch, you can just merge in the 'removals' + branch. +

+ +
+$ git branch
+* master
+  removals
+$ ls
+README   hello.rb more.txt test.txt
+$ git merge removals
+Updating 8bd6d8b..8f7c949
+Fast-forward
+ more.txt |    1 -
+ test.txt |    1 -
+ 2 files changed, 0 insertions(+), 2 deletions(-)
+ delete mode 100644 more.txt
+ delete mode 100644 test.txt
+$ ls
+README   hello.rb
+
+ +

+ more complex merges +

+ +

Of course, this doesn't just work for simple file additions and + deletions. Git will merge file modifications as well - in fact, it's very + good at it. For example, let's see what happens when we edit a file in + one branch and in another branch we rename it and then edit it and then + merge these branches together. Chaos, you say? Let's see. +

+ +
+$ git branch
+* master
+$ cat hello.rb 
+class HelloWorld
+  def self.hello
+    puts "Hello World"
+  end
+end
+
+HelloWorld.hello
+
+ +

So first we're going to create a new branch named 'change_class' and + switch to it so your class renaming changes are isolated. We're going to + change each instance of 'HelloWorld' to 'HiWorld'.

+ +
+$ git checkout -b change_class
+Switched to a new branch 'change_class'
+$ vim hello.rb 
+$ head -1 hello.rb 
+class HiWorld
+$ git commit -am 'changed the class name'
+[change_class 3467b0a] changed the class name
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+
+ +

So now we've committed the class renaming changes to the 'change_class' + branch. To switch back to the 'master' branch the class name will + revert to what it was before we switched branches. Here we can change + something different (in this case the printed output) and at the same + time rename the file from hello.rb to ruby.rb. +

+ +
+$ git checkout master
+Switched to branch 'master'
+$ git mv hello.rb ruby.rb
+$ vim ruby.rb 
+$ git diff
+diff --git a/ruby.rb b/ruby.rb
+index 2aabb6e..bf64b17 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+ class HelloWorld
+
+   def self.hello
+-    puts "Hello World"
++    puts "Hello World from Ruby"
+   end
+
+ end
+$ git commit -am 'added from ruby'
+[master b7ae93b] added from ruby
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+ rename hello.rb => ruby.rb (65%)
+
+ +

Now those changes are recorded in the 'master' branch. Notice that the + class name is back to 'HelloWorld', not 'HiWorld'. To incorporate + the 'HiWorld' change we can just merge in the 'change_class' + branch. However, the name of the file has changed since we branched, + what will Git do?

+ +
+$ git branch
+  change_class
+* master
+$ git merge change_class
+Renaming hello.rb => ruby.rb
+Auto-merging ruby.rb
+Merge made by recursive.
+ ruby.rb |    6 ++----
+ 1 files changed, 2 insertions(+), 4 deletions(-)
+$ cat ruby.rb
+class HiWorld
+  def self.hello
+    puts "Hello World from Ruby"
+  end
+end
+
+HiWorld.hello
+
+ +

Well, it will just figure it out. Notice that there are no merge conflicts + and the file that had been renamed now has the 'HiWorld' class name change + that was done in the other branch. Pretty cool.

+ +

+ merge conflicts +

+ +

So, Git merges are magical, we never ever have to deal with merge + conflicts again, right? Not quite. In situations where the same block + of code is edited in different branches there is no way for a computer + to figure it out, so it's up to us. Let's see another example of changing + the same line in two branches. +

+ +
+$ git branch
+* master
+$ git checkout -b fix_readme
+Switched to a new branch 'fix_readme'
+$ vim README 
+$ git commit -am 'fixed readme title'
+[fix_readme 3ac015d] fixed readme title
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Now we have committed a change to one line in our README file in a + branch. Now let's change the same line in a different way back on + our 'master' branch.

+ +
+$ git checkout master
+Switched to branch 'master'
+$ vim README 
+$ git commit -am 'fixed readme title differently'
+[master 3cbb6aa] fixed readme title differently
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Now is the fun part - we will merge the first branch into our master + branch, causing a merge conflict.

+ +
+$ git merge fix_readme
+Auto-merging README
+CONFLICT (content): Merge conflict in README
+Automatic merge failed; fix conflicts and then commit the result.
+$ cat README 
+<<<<<<< HEAD
+Many Hello World Examples
+=======
+Hello World Lang Examples
+>>>>>>> fix_readme
+
+This project has examples of hello world in
+nearly every programming language.
+
+ +

You can see that Git inserts standard merge conflict markers, much like + Subversion, into files when it gets a merge conflict. Now it's up to us + to resolve them. We will do it manually here, but check out + git mergetool + if you want Git to fire up a graphical mergetool + (like kdiff3, emerge, p4merge, etc) instead. +

+ +
+$ vim README   # here I'm fixing the conflict
+$ git diff
+diff --cc README
+index 9103e27,69cad1a..0000000
+--- a/README
++++ b/README
+@@@ -1,4 -1,4 +1,4 @@@
+- Many Hello World Examples
+ -Hello World Lang Examples
+++Many Hello World Lang Examples
+
+  This project has examples of hello world in
+
+ +

A cool tip in doing merge conflict resolution in Git is that if you + run git diff, it will show you both sides of the conflict + and how you've resolved it as shown here. Now it's time to mark + the file as resolved. In Git we do that with git add - + to tell Git the file has been resolved you have to stage it.

+ +
+$ git status -s
+UU README
+$ git add README 
+$ git status -s
+M  README
+$ git commit 
+[master 8d585ea] Merge branch 'fix_readme'
+
+ +

And now we've successfully resolved our merge conflict and committed + the result.

+ +

+ In a nutshell you use git merge to combine another + branch context into your current branch. It automatically figures out + how to best combine the different snapshots into a new snapshot with the + unique work of both. +

+ +
+
+ +
+

+ + docs   + book + + git log + show commit history of a branch +

+ +
+ +

So far we have been committing snapshots of your project and switching + between different isolated contexts, but what if we've forgotten how we've + got to where we are? Or what if we want to know how one branch differs + from another? Git provides a tool that shows you all the commit messages + that have lead up to the snapshot you are currently on, which is called + git log.

+ +

To understand the log command, you have to understand what information + is stored when you run the git commit command to store a + snapshot. In addition to the manifest of files and commit message and + information about the person who committed it, Git also stores the commit + that you based this snapshot on. That is, if you clone a project, what was + the snapshot that you modified to get to the snapshot that you saved? This + is helpful to give context to how the project got to where it is and allows + Git to figure out who changed what. If Git has the snapshot you save and + the one you based it on, then it can automatically figure out what you + changed. The commit that a new commit was based on is called the "parent". +

+ +

To see a chronological list of the parents of any branch, you can run + git log when you are in that branch. For example, if we run + git log in the Hello World project that we have been working + on in this section, we'll see all the commit messages that we've done. +

+ +
+$ git log
+commit 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
+Merge: 3cbb6aa 3ac015d
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:59:47 2010 +0200
+
+    Merge branch 'fix_readme'
+
+    Conflicts:
+        README
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+commit 3ac015da8ade34d4c7ebeffa2053fcac33fb495b
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:36 2010 +0200
+
+    fixed readme title
+
+commit 558151a95567ba4181bab5746bc8f34bd87143d6
+Merge: b7ae93b 3467b0a
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:37:05 2010 +0200
+
+    Merge branch 'change_class'
+...
+
+ +

To see a more compact version of the same history, we can use the + --oneline option.

+ +
+$ git log --oneline
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+
+ +

What this is telling us is that this is the history of the development + of this project. If the commit messages are descriptive, this can inform + us as to what all changes have been applied or have influenced the current + state of the snapshot and thus what is in it.

+ +

We can also use it to see when the history was branched and merged with + the very helpful --graph option. Here is the same command + but with the topology graph turned on:

+ +
+$ git log --oneline --graph
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

Now we can more clearly see when effort diverged and then was merged + back together. This is very nice for seeing what has happened or what + changes are applied, but + it is also incredibly useful for managing your branches. Let's create a new + branch, do some work in it and then switch back and do some work in our + master branch, then see how the log command can help us figure + out what is happening on each.

+ +

First we'll create a new branch to add the Erlang programming language + Hello World example - we want to do this in a branch so that we don't + muddy up our stable branch with code that may not work for a while so we + can cleanly switch in and out of it.

+ +
+$ git checkout -b erlang
+Switched to a new branch 'erlang'
+$ vim erlang_hw.erl
+$ git add erlang_hw.erl 
+$ git commit -m 'added erlang'
+[erlang ab5ab4c] added erlang
+ 1 files changed, 5 insertions(+), 0 deletions(-)
+ create mode 100644 erlang_hw.erl
+
+ +

Since we're having fun playing in functional programming languages we + get caught up in it and also add a Haskell example program while still in + the branch named 'erlang'.

+ +
+$ vim haskell.hs
+$ git add haskell.hs 
+$ git commit -m 'added haskell'
+[erlang 1834130] added haskell
+ 1 files changed, 4 insertions(+), 0 deletions(-)
+ create mode 100644 haskell.hs
+
+ +

Finally, we decide that we want to change the class name of our Ruby + program back to the way it was. So, we can go back to the master branch + and change that and we decide to just commit it directly in the master + branch instead of creating another branch.

+ +
+$ git checkout master
+Switched to branch 'master'
+$ ls
+README  ruby.rb
+$ vim ruby.rb 
+$ git commit -am 'reverted to old class name'
+[master 594f90b] reverted to old class name
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+ +

So, now say we don't work on the project for a while, we have other + things to do. When we come back we want to know what the 'erlang' branch + is all about and where we've left off on the master branch. Just by looking + at the branch name, we can't know that we made Haskell changes in there, but + using git log we easily can. If you give Git a branch name, + it will show you just the commits that are "reachable" in the history of + that branch, that is the commits that influenced the final snapshot.

+ +
+$ git log --oneline erlang
+1834130 added haskell
+ab5ab4c added erlang
+8d585ea Merge branch 'fix_readme'
+3cbb6aa fixed readme title differently
+3ac015d fixed readme title
+558151a Merge branch 'change_class'
+b7ae93b added from ruby
+3467b0a changed the class name
+17f4acf first commit
+
+ +

This way, it's pretty easy to see that we have Haskell code included in + the branch (highlighted in the output). What is even cooler is that we can + easily tell Git that we only are interested in the commits that are + reachable in one branch that are not reachable in another, in other words + which commits are unique to a branch in comparison to another. +

+ +

+ In this case if we are interested in merging in the 'erlang' branch we + want to see what commits are going to effect our snapshot when we do + that merge. The way we tell Git that is by putting a ^ in + front of the branch that we don't want to see. For instance, if we want + to see the commits that are in the 'erlang' branch that are not in the + 'master' branch, we can do erlang ^master, or vice versa. + Note that the Windows command-line treats ^ as a special + character, in which case you'll need to surround ^master + in quotes. +

+ +
+$ git log --oneline erlang ^master
+1834130 added haskell
+ab5ab4c added erlang
+$ git log --oneline master ^erlang
+594f90b reverted to old class name
+
+ +

This gives us a nice, simple branch management tool. It allows us to + easily see what commits are unique to which branches so we know what + we're missing and what we would be merging in if we were to do a merge. +

+ +

+ In a nutshell you use git log to list out the commit + history or list of changes people have made that have lead to the snapshot + at the tip of the branch. This allows you to see how the project in that + context got to the state that it is currently in. +

+ +
+
+ +
+

+ + docs   + book + + git tag + tag a point in history as important +

+ +
+ +

+ If you get to a point that is important and you want to forever remember + that specific commit snapshot, you can tag it with git tag. + The tag command will basically put a permanent bookmark at + a specific commit so you can use it to compare to other commits in the + future. This is often done when you cut a release or ship something. +

+ +

Let's say we want to release our Hello World project as version "1.0". + We can tag the last commit (HEAD) as "v1.0" by running + git tag -a v1.0. The -a means "make an annotated + tag", which allows you to add a tag message to it, which is what you almost + always want to do. Running this without the -a works too, but + it doesn't record when it was tagged, who tagged it, or let you add a tag + message. It's recommended you always create annotated tags.

+ +
+$ git tag -a v1.0 
+
+ +

When you run the git tag -a command, Git will open your editor + and have you write a tag message, just like you would write a commit + message.

+ +

Now, notice when we run git log --decorate, we can see our + tag there.

+ +
+$ git log --oneline --decorate --graph
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

If we do more commits, the tag will stay right at that commit, so we have + that specific snapshot tagged forever and can always compare future + snapshots to it.

+ +

We don't have to tag the commit that we're on, however. If we forgot to + tag a commit that we released, we can retroactively tag it by running the + same command, but with the commit SHA at the end. For example, say we had + released commit 558151a (several commits back) but forgot to + tag it at the time. We can just tag it now:

+ +
+$ git tag -a v0.9 558151a
+$ git log --oneline --decorate --graph
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+*   8d585ea Merge branch 'fix_readme'
+|\
+| * 3ac015d (fix_readme) fixed readme title
+* | 3cbb6aa fixed readme title differently
+|/
+*   558151a (tag: v0.9) Merge branch 'change_class'
+|\
+| * 3467b0a changed the class name
+* | b7ae93b added from ruby
+|/
+* 17f4acf first commit
+
+ +

Tags pointing to objects tracked from branch heads will be + automatically downloaded when you fetch from a remote + repository. However, tags that aren't reachable from branch heads + will be skipped. If you want to make sure all tags are always + included, you must include the --tags option. +

+ +
+$ git fetch origin --tags
+remote: Counting objects: 1832, done.
+remote: Compressing objects: 100% (726/726), done.
+remote: Total 1519 (delta 1000), reused 1202 (delta 764)
+Receiving objects: 100% (1519/1519), 1.30 MiB | 1.21 MiB/s, done.
+Resolving deltas: 100% (1000/1000), completed with 182 local objects.
+From git://github.com:example-user/example-repo
+ * [new tag]         v1.0       -> v1.0
+ * [new tag]         v1.1       -> v1.1
+
+ +

If you just want a single tag, use + git fetch <remote> tag <tag-name>. +

+ +

By default, tags are not included when you push to + a remote repository. In order to explicitly update these you must + include the --tags option when using git push. +

+ +

+ In a nutshell you use git tag to mark a + commit or point in your repo as important. This also allows + you to refer to that commit with a more memorable reference + than a SHA. +

+ +
+
+ +

On to Sharing and Updating Projects »

+ diff --git a/vi/cookbook.html b/vi/cookbook.html new file mode 100644 index 0000000..7818f55 --- /dev/null +++ b/vi/cookbook.html @@ -0,0 +1,12 @@ +--- +layout: reference +--- +
+

Git Cookbook

+ +
diff --git a/vi/creating/index.html b/vi/creating/index.html new file mode 100644 index 0000000..449859a --- /dev/null +++ b/vi/creating/index.html @@ -0,0 +1,142 @@ +--- +layout: reference +--- + +
+

Getting and Creating Projects

+
+

+ In order to do anything in Git, you have to have a Git repository. This + is where Git stores the data for the snapshots you are saving. +

+ +

+ There are two main ways to get a Git repository. One way is to simply + initialize a new one from an existing directory, such as a new project or + a project new to source control. The second way is to clone one from a + public Git repository, as you would do if you wanted a copy or wanted to + work with someone on a project. We will cover both of these here. +

+ +
+
+ +
+

+ + docs   + book + + git init + initializes a directory as a Git repository +

+ +
+

To create a repository from an existing directory of files, you can + simply run git init in that directory. For example, + let's say we have a directory with a few files in it, like this: +

+ +
+$ cd konnichiwa
+$ ls
+README   hello.rb
+
+ +

This is a project where we are writing examples of the "Hello World" + program in every language. So far, we just have Ruby, but hey, it's + a start. To start version controlling this with Git, we can simply + run git init. +

+ +
+$ git init
+Initialized empty Git repository in /opt/konnichiwa/.git/
+
+ +

Now you can see that there is a .git subdirectory in your + project. This is your Git repository where all the data of your + project snapshots are stored. +

+ +
+$ ls -a
+.        ..       .git     README   hello.rb
+
+ +

Congratulations, you now have a skeleton Git repository and can start + snapshotting your project. +

+ +

+ In a nutshell, you use git init to make an + existing directory of content into a new Git repository. You can do this + in any directory at any time, completely locally.

+ +
+
+ +
+

+ + docs   + book + + git clone + copy a git repository so you can add to it +

+
+

+ If you need to collaborate with someone on a project, or if you want to + get a copy of a project so you can look at or use the code, you will + clone it. You simply run the git clone [url] command with + the URL of the project you want to copy. +

+ +
+$ git clone git://github.com/schacon/simplegit.git
+Initialized empty Git repository in /private/tmp/simplegit/.git/
+remote: Counting objects: 100, done.
+remote: Compressing objects: 100% (86/86), done.
+remote: Total 100 (delta 35), reused 0 (delta 0)
+Receiving objects: 100% (100/100), 9.51 KiB, done.
+Resolving deltas: 100% (35/35), done.
+$ cd simplegit/
+$ ls
+README   Rakefile lib
+
+ +

+ This will copy the entire history of that project so you have it locally + and it will give you a working directory of the main branch of that project + so you can look at the code or start editing it. If you change into the + new directory, you can see the .git subdirectory - that is + where all the project data is. +

+ +
+$ ls -a
+.        ..       .git     README   Rakefile lib
+$ cd .git
+$ ls
+HEAD        description info        packed-refs
+branches    hooks       logs        refs
+config      index       objects
+
+ +

+ By default, Git will create a directory that is the same name as the + project in the URL you give it - basically whatever is after the last slash + of the URL. If you want something different, you can just put it at the + end of the command, after the URL. +

+ +

+ In a nutshell, you use git clone to get a + local copy of a Git repository so you can look at it or start modifying + it.

+ +
+
+ +

On to Basic Snapshotting »

diff --git a/vi/images/snapshots.png b/vi/images/snapshots.png new file mode 100644 index 0000000000000000000000000000000000000000..fe87f63ea144124fce16c89d19efe8db6c1bbdbf GIT binary patch literal 23231 zcmZs?b95!!^FExMiEZ0||owHs0Lt{oLPQ?^>sO^{U>x zc6aTwtLk}bcbL4aI6Mpv3Oc( z0wJQ~r5K$Q(bMmUr~vUs>-9yK_vMwpeu#>mZ)j=~`SB5Q{)!4>RT^ya-IJV`o={5( zF* zHtSn7*BT=y9(o?L?TYuuOgBhqwwTr1TfSF62ofm>$Z1HBXs&x$)Gv|?Tgnlie(4kdWHGw3rbfA{rbgwPFE(T@>paJI8tXX>B3wv1A^=1$fD@Du31SBb zK?P9Bg?98qW`g|Q3)%{TxCQGE#0mvm6Jeiy!zO~<3m}n)k@cI~;%x6wYzXovW z1;GN4>Z5f6=C=5r02sevzyw`G;h2T-kO;{Dl7cX?IEC=of*7&*djK~>hR5~CG)L*j5J$Q*UX<}+LLyH2@H087GIT`Ql+GwQC<1Y{WV-PvBmR5R zD?ez+7UJ3^jSAgZ(qu?~#bpg|?*;5h+2gvUzQy?$K*_UFAtc&LQ51#G%DPECOUV^u z7W^&Q6wCqYN$AOK$_ey?uwF5nF>x}BFyon)8XXzA_Cqn>Fk7%#|BN)EGqyCwGtM+3 zVF_c!W_@NZVpU;rV(Bt|85|$$Oj?fO3TsPjOM2$Im7}3l$vP4Gk)Nzsqx7e=g07Qp zg)W=!RlQu@UA%ioA_4q|!cAxH` zcgQ;*+@f#Rw$iqX4psK=cP0+3cD#Ov>?RyK?5|F_gk53_1nUL+@c3|l zl7AcmLVY`ZGkOL6DEy!W^K;8{YxJ}AJGLs3Dq_3k3#Xy;yz|HnkPSSxz54F^7|o2+ zA?Q<8Wjchl(DK4KLklC=!eqi&B2FU2!c-#=A`Au+2i^vw!|ucB!=%GI!U$0=kv>U? z$+oHNw=Lr=->ZNt-BG?*QBu)T!CXL_@0+(+Fr5!t=$e-+ zjj^cx#c76S#yeeTrfFts{$M?5#lDu_-6Rb=JG-z_;G}e#(%kG^?i}*Kh>xGe$DP#< zRFmWQ(ISpm@iRZA>~D?SV#}gHzJO(~Y3+LMxPG7f^z>%!knN z`lfED>ibamoFBPA3MRs<;;gdIZ><`wwpTUJk$7-B6g$j4z+a7D`5`eN8ABov1n{Hq zVe$01C3(oX?ztN{UpYBAKUb{Vx*T6CBhsaV$3kf**oT@{qfQP^otN=C!UYRh`{KKH(V{Vw3@A~PeWAn_5Jjc-gZ#xh6h$1TQ9$7Cn7 zN0}$u635~@cwA0mkMmyo&q9Z;B+3oiByve>v z#i`OM&50J1grT$h$kA>qezK_8{rUwJUIrc#R~6TVy}PS(_r^9sV{U?$MvdY7T>4lw zi{3;#gpPFQLlb$cN&Q08y+Vel)|Auv>ED(8)n7K#)|qEpXH=b%KCBg}$7^$Kp0pQ> zf2(V&moI!T$_S>iuU8pba@Oj4ZfpOxKkDYVZLW7vxLn@h-ao=&!8xwa^|+jNZ@g;- zyaebV!Vx$kVk4}(ncdW0#yuB!^e^@c$D9)iU@!BtJPhoP%qxACG)(nndwCJOdb&AI zVVTl7WO{dAfgeUBpf-lBq`)xNbj^A@dCc0|yN)_poZL_T-P|Di(Lcw-hO3sPEB|`^YkCvo5d1Z2?WM$KP{S$jP!3PKCQwHqY1o+1Rz{kO_ zr>%EWd&`F5s^$Oh_u0aLbd0~>l?JOn&4-5s(%a$yBCidSivSAjd$YOkaZB7>hUm>L zoQ9|i6m)~aVFJ1ZTQEh{gF#OtRRaDR7&D!Rverji^`HM zvtjB1LoGZb!s9vGPL6?*@)D5q>J8@e?(5~};;-Qh5y%$u0hJPQ70z3KDm$+kX>X~% zcKj43l2@3zu0;J&mh%8{cKYMznvDk$SmZasX>|~i=w&upJY=~*-E7|yf&I0T?}tRlY=kP z!uJmFrzzAw@YJ3%f@)@~XEX;ii&oKUXj{hCw=RL)8ylWWZikEK)g9}P?icIb9wj9$ z1vTf^zdoD%hCGrU8z4yuI1#b=mA%Qnk6&ZGx>_3_jU<&&W}67eVclc1Vjbe-c+GIf zeX_hIo$n=6CzsjO5O%h)dAU;DR88>Yxg<3BH8@-fPrEB$XAX+L{kf1c&w=mO@454y zcroRdOSRFM)-coF)0NTod|1DDy(I({I7oT;DE!oDrmI`4H*8~RNN*^v|9)Fxyl(I1 zD>a7I$-drN?T@4nr zOz^n*ysj!jGt)yyCX03vuj>X`cMQPKzb2^5j8PQEJ3g@_7>_lRSNJp{}R z5!6yV?rP&jOV6$ofr$gZBrg-%l<1TmFU(hXvW60?>o>Q1CnNU)LRjTYbjGd6jz_v& z%=WIvI@{hB00%JVsbv*lO1Kj zx^U@!>6~~n2I@w(qv_?W)z&cI+I!Dk(=JRzsdd!wS-Z`>G+7nlw+Wu;w~s82xJ8si z^kgiOx_OM@XX%ddmvmUauR@+(YOMVwocGLSBYTxUL;hqsHQL#2ii?pG%X#4Kxa;&} z`$^}rGdCacj~-{IXL zF>DX`Ebf4WFxvYqk-5=7JWpc@$_v8Q5C)0H9;E~P6)7b&Wk3$4{J1adg^XYp=9zsT z`CTWNVMt4+Ydoe*iEeW_^o#^=C9_)ldQIG|`U>HC0(uJ^Jg^z+bf!||Oyqo!ZqSLm zkgO~|La~1~ip8xy&wlYH9A+(?b8wKJRZ1@DRasMcsvKWsvjjQsxP3ugS};Q`q_m;% zRrNB>yXH50zk}GH$hjZRY3`|M8MKz;SAcU8#6rD4aUMrma;c{F@ZXxtwiRqjrXqV-Gps&{*wn7V-r5d+&3bO{jK@FToN0~^y?h?bacn?y zqJu=wfo|~ve60{cmWioaKEU^T!j8DWK_Hz#=pz**OKVkrVqPM~2OwT@Yi2#~?U6b1-T zAgLqge;kmA$GuXsjp~kqbz!_yCvw3XV;L(ORO*wkk~2*(t+Kkv50*a96Vh$aJ*u;- zGuA@aC)Fw~-*QsnwPm7BdNN>CD_VPB%<&rX9=a8|;XbiFy*%?hr+~qL6@gzuxxv1p zFqBvobs?2iS&Y_>8wxIivY|}F{rje3UvQuQy7ZBeHJ_KfV@v3-B<;m5#jO8lk z*e6JZS)^+wx`&F@n)a&7(L-9H;o+l43S3rR8DHex*aD(6X~Jb#E+UpGc=lpZOcx4W!Xxikx0^Y;fx$3*j+ zU@>~4e~Rtn-x=&V+;<*4R_6SukmJZ9fl%k-X^X!idJAR7a{8>G%!JGSI4$w|@nMpH1=_tLFBbLt|)*4|b${4;JMjuL;AfJ+&$V*m4+C=0f zI3$-W{!pf!*VzRq>1#9`O9m84>|4=Dm9JT-H;LZ6;Gm|*v>=$R&sr~Xm1tGE00kzA z)|kerhBznoT945iC=bSxJ5{+Cb-y1s|7>1w&S=zgHg=A8Xx_{|QM}|npX}-HFX(ev z(ORKgd2AQ>-pgG}W#(9-FJX2RWt$utI{cd|=qO&@Qrq%PCSQ8C%lJI;h0oI?rZ8?6 z7BSS+(bU~EAhTR}DCF=a0#*k0Z@6ZJl62*$*?t8jp=xH?ir30Hw>h-VhjaQpP^ zobF7&kZrUAs9kajr(%9n%!8PDM-1y^+RE>h4wh|a^=JKfBbkPoq}q^eO>Jtf+^%!a zku%-?&VK5G8ov>Rn)>qC+*aZxT8@yJ1?=FV#lp--Fv{@E8L`KMm~(6p6%T9i%i*#CLU8h+IzoZ z!^Q6vS09jkK@l^NMBgI6?Stdbbp|>%jPu)-wbU6tF5Y?ff)?2GZNTMQCp`T$DdNj3 zI(GXqWXK9o`(r!$q15u5bjYjv>RUk5xBSR+`N-%XOH!jd4kpO(ZzM*R_#bg46yVtE z1*wsvF)!k{@7GFobE|mgg5T~+-|Uquvq;0usV*X;8#siRNy9hEz_~a-jT*KNZJuKA zg1`AkO?a>Nj{jyh#jR7HMr6v1g^Gyc%B|B!*9R5y69^UM>3*BBlz~vs-!uvSJTn1; zT#2#Ul``N2`eLJnXD4(_yeB5`_Ui{+So$}hwnDTpK@dx^l#h|T+f^ab03 zVv9g42;U*$i=Zx)eKWd(xW{|?8IAkV&j2}qA0shu3nSEo`?-D?gTZN~3HkZ@?2`cs zMUdI?{qZM++2@|A9FcnwD1uJO%^Uo@Nq95dM+*Ir0I{jCF%ohb7CIgl8fk8b^N$y4 z*wmocQ7KreQQF}EpKq~|H*QQC{(@ipJ+!TahQk+ukMhp}`ZH(ti{2*!krWYB{vz=GxNtm=Vd~9O^aQuPQyG&nz3!41d$mDpo%j=(>i<7oS zcUs*d-}dNebQ;-&k#UGoUrl#fDp*x2(DojkV7Lq=!a~L$Yu?07(}A4@5`ZSL7Voif zI6@)6MHcMw2$^x7`#9gsl|GI3n5sw*tmgv54ia(t!e|tEBjpM)3{y^`gb|B!)T>!r z=xGT#6#IRz9dAyLd0XjgLoye_^>W7bv+e*H)#pKp-kDC`71vqW$>ARS!Ad!bGxgn{rvURbr zJ8{qktEo zE1jV?U?*>XZl66hBg5#=;Y{2Yn+e*7Qj-)Y zwOc|rYHdS>Z};V0u7M@^2NV}|7%gi8d@&R)D0wNb1FKAaNmn6UkMc4&Dn(3SQc|O) ze*sq*KeDZDt?=#%quOsnU0IT;T1ASzY891cS1Mo&9EHHfuEo>q%hdGyUJ5Sq<= z1xU)ZP!)l7F=M$Ukp~uvP7OLbUG;ie2~ui+b#=4wK;KkkLqxaM#9`a1|Mh?HT=4Mp zaBTqO1{?H_acrFB#_19Z^VE@0gT_=@I^qOP<8Weq2mOVs6SY3NCT0Y0u|)3SJR5Os zi1T7m#4p@{5jC%%i^Bx^vm~5*wxf`*eqp(nRt_n41z`NCa9MhIT>bT6zR+fm7PIno zR{L?;2=ORe#%ghp@9?dL(j@NIstAAWm~-(mtsMEiP}WEA;Br9VL66Y-X5tU|WWNzq$d1eUm`oVWR)v z81(;)q3Y#e{{O~+szu2a{Ehsd%3{&49&_b34D|mE3lFLaV515TGcMfu=&CeCxwfXz ze*;szTo<>1=*VaKNIyWqkOXE2i9;jCku$O+ZCo0Y=ZdH#1{oD>4k7)$yl(MRa}5h0 z3rhtWfGJjQJNy+)ZKvz5MeEFhP6hM3I|{&3KgU0dkYzu*sYj8|KVc2Aa*CTqZoj}x zge=MV1YbAFxGoiOvm>FtMM##iLqymA_jsxE|*J=}Jdn zhnw)`Li<wp*p>X_F_#&{$x>?TymtZ+7*xa@!j*$>LksDhH$d z3e{Oo2V|2DecTTnfD>Q?*k69;t>i!KV?q`iU20Onq;tycQjocGO_NOS6V8p`7}4$m z-|_j1zGyvqn*Er~_syu-1t|L5WN!(3{M6-QL$^^u7k=4}{-mE8D~7FT^wBpXjA_S~ zn4WHgg|LHiJ}l;JO5RAg3Yv6xBU_N1o#HOHCCKX>om1nKMXTk%diMO}Y^o&rmcJr& z@EaXVb&t;n{p1WkfRV#I!8Rbpg*X2=9U@(SGOEo?Apva-?%a7_*vhVa9%DfqM^kIM zBipw!RUQr*##hb7)ALTt)5Q_O^Rj|qYnI0gA^*UWiW;O_TA)9@L#y^?56<;+J)FAf zfP|t0Cm1Xyq*Y{PX2N!|oj)G1#qNc3aDfGK_WmtgwF~Kpv3wlf&*RW&4U0n(6l#f? zFo6QFdYI|&p7^K9LBP|?kst7l%FVu+lZtUz$(HX4Q6yV=!#BW%;19N@KqD7Q*|FOQ z=MdPa5RvI}NjzZM`o+}~zYE~Nfk+Mx#4eOAiCk6Rec@ln!e_o1hOv}c3vD}vAaYzh z#Cr1PthXF(pkKfyv}^?RhF)#HP!)#nD>Q?z>H z8&gO&&&K>pzHo=pq+}f*%pbYWf<(Q>ih_vR*lgBbuf3j5_$vCNH1F(yTij;krHdy9 zLx9CH)Pd8L;F98+QyS22woh@V&PJ7Y&6KeZau+uY47h-hYX1nkR{8+_aQQ-5494dB z&D{FE*wMFS&}WO?lY<-KJd`54X)CCz^?ew7!lOruqayiexq=!c{^MKaNu;h<1_^mm zbI4xQO)8IC(9e+a+78)OOj@~;=a#Z)K@W_rtW>=%wNFI42z6iX`0;c!JOh9UDbNO& zheG7H)eC0ovx&3`LDYKf3^}Z@r_FEw;9NzJ{w+t3v+zlt?nb)GE^imRA*7d`A!&X>@Q1x%+1Wt%J3Gq~ zOEJ9lplY^tm>QdNe@X$lFG5=^K3n8fUJXvp!ra0)6BCQ< za85GKMG>vfw{`+k%-_8YDO94%)zdK_DQs&f+U@Mg3X1>4IK(ETQQ*^W{48u$10U%u zP>i6McgW?EcYttmpMa>6NTzAirfb??lR@i!~BY;%^%SL^W5 z6Aaem3+faBa%Gi@tXRVt`T`2+dR6a-s@n>4n(6oCDFv`0%H@h1lrMyftr`7fQFILe zMdU=-TkL{!#Zurvw^np+t2g*8Ww&)2L9JTahwPemZxz1DQ3_H%;>5q6A08f{&0KDx ztY6OhXFq7OYY}~y;8|CskK>Day)Ee;7E6=Iu(2Z zUE@X6NvrFfmS%eYn&uLxv={8GA}Z#y$NoK7sY|-_Nr1KcJ^%hJ!gtNXZ#qPtwDaTx zzlw-szvW#HW&W7wqasIE=oymG$z|jq4?_QAcTB@~*3>6JIW?n+%Goi^quAC0?jYe@ zD~k0g`YFekT8u_hGMrJAyoF~107o9i;Mk|q?kx1sDH<9eI(hRt4vlXN+PQoN*Ir%u z+vcpDsj}XjNC+)qzxT-+_|HuGa^WC)MQ{>`=>K)%bofrdK|)ej)IvDqoE;wO+P=)y zn)la{Lqsks(k3~Jte{h5EgI^N5Dp9ygp&8ig6-=Oc_9%tCgNtWt8@!0=Cpzn9;X8p zpyUy+gyZ8^tL;1Sx}_v>?$bhs#xSxb#|;XNbsWAP!L(XbK}53fdV|YFEUlEt%&*j zCK*?RMA&wYyK%iDSJ0XwBDR@ZbMhI2=uhq`28}Ot@gj1YalKKrg28@I*>fARna`WM zjetpseI@biFG{mXRssVXUONOH@CJ@C=XySXV#ZdoE=%-P3`wy*yT;1U3;! zabo6uX1b9xBJL-Yi@6kb#kVDLGDRDElJ(s|C&B{v$$?;nj@)LuYfJydh@9<4a6Vjw z+^KWk4#QnZ>El!1H2UW9>UavMC0;<6a*iR}^9}8|n}#R;6}3NQX}s$raY3oewz&r; zEDvJ>T&e0ywP=5bu!5*IFsmh3($I&x`>_AKyap1%@MZ7i$-3UP;Dta*wLAKplvX~o znb9ozJYf%O(=Pi2%&-oZb@d{7u`Ag-!fp3d!meV7|H;vvjQ^AaJEM@^`YMYLzJ`7J zqC4LCiV&5G8FcD8$ADqrFX-*?lAK#=h7X}9Hzm-7Q3>A&wMVpQM$f?RkmyJE`Oyk4 z&pK{1_Vtpctd)WJEs_j0iKse$epwe4qjOb_^YFa$7Sx?CE2v(xO40p;;1+^UD<-dZ z?qpPoOs*{eLxq{n9Q^Fd5=nPK$=t4TIgubQFkyLgk()-{YI6K^sC&gy_}ZplOt+FIH7A-Lj>b<$PVeYJ;m9s_OG^b96lgvV^{aU@X>_urYG) z#qw$_AJp2{(x`77Qt5Mh?Qxsz9Hz4#n40kXso^OpGnzn%HiJ6)$wPEK;FK*JAdR6~ zTk@+Sm#8~OwuG3?0a9yemFl$^M(VM%*`!EbF0BZ?@(ze$4O>*>m)l^XI~pq zCHi}Rr&*o}v#u$(SsrSrkJZiFWBmB{h4S688PbOCPonOly(#w^t`Wmux0O?U&lz~2 z$J~tV^Qw~%@kx#|W!am$w2ES!Onx^M^6{sgWagt<)%iDbk6$bPJE&;hp4Y!%{wuo& zx}oTk=kl7{>;5N#3k9JCg;3U@qxoN+?RP`gD+P3$-Rt}>(!P2OV0Nt zeUp4|3P;?S|HBMKU->+iyh&Z@e|kp~d<(($O!tRJS(PSF2T_p{fOb^)esAYQv`YJ> z`HsuB7XN7T{f#950H&VaG?T1OVUz{T2q7N2{hODT#Pth&P}$ht*`nGxe%D9LqQ-tr z0?Jm4s+)wcm~XaCZ{W{5!v~RU-Xqve4_7Zk(xyEf4xFKUu+?d|ntN3G8%1n-xg%~hgV5T!I8Dgj34Q0d9Iz1_ z98GP0)n=o$;QxTun+Kz$mb=?pIV*KMN-TYXp8Vy=WHRZ&4f{O}BYa{neU+Frjn_-o zDP{tEBh{3Or9B9rl2>0v-L)%_p_~iryPq^>wFL~&MhH4QKy73jDr5%=sUl~=d@`#I zq)q!zPlr1uBYbG@acB?Qtm3P06(Hjyf5^F#D)zsf-Sfck!WwEh| z!sbx1va!P7*70pBxr_E8o7uQhbv0X<=>x`%O*b=iN20n1MzEL799_<-3APvvR63%} zn}%d4a25LYGRJ{X(+}q%uHIc)d-G14%IZkDCO>fTO<+F@$~Dy0lpy zu%=*u%(*w`(R%1@{_Z2)qb+G_@aeuJDt>F;l^}`LC^l}DXduMd#gst$UsVcK>1i287*(&c*1ztZb#YKYMZcT7`@|wJ@mSxd*$T&N=NMP< z6^qLCTBZZ)o97FLf|Fj9xyTcP2=rr2V$VlLM?ZR2Pbc@WArr4$WyRz`)5gcW94m-| zWUfK$?u;pdrGVFrlHJs_lwOnPgbZeMU^()D`N4$yl(fH&*4yP06QfMcauye7VdfNa zBRDF*LjS&=+~ABU8kksn+zJkP4L-oG6)4FjoqS)L5HnC2(GaUD$*iBxu(Y;}%r>(A zW!LDw3DI*JCBIJ;ntCf}YGdNyu#n~xc&)@`JfeZ*Ck5(+Pd`Dkw3MEKz5c#G6ytN= zTy7xHT<((96IE8ff3R%2tZ{(xxr&seF5d>D0)UaSq+69}I2SWXljR8c8&xEujX)uf z@kMGh&)S8Q(pS=tU3|4eUCHk0Kmi%sBjme+mQ?7VN-BUQ zrds6`XiC$6=}e<9&*sa#NRtxwKcWH%4V7At(i`kY-U{Rln?XhTqDB5;KokJQU-X2< z@{c>kLqpd8^Kn3LK=BKaaewcd8ldK1k?#mHlM1;n{I?$$iid#z*Q^q3kFxLdzqgPH z{PM39iZj|W|GmL8^gm*6v zrXapiouOA7seVw%G91Ek8cpTqC+HvYbUsGlzErkM=l}tELBct?by$kzofN^I`@7v< zu*htX_1lE9*x%*;2R5*Vn~Y+JelS!p)+l~7+MVY$MS7~;fQXFkQO{M^Bxo#FznoHA zLo6bnR@rkhichhx)KE-j%Y!Dv6~YXXnXWTz#a|K*F(VQsw|sk{Q5g}mlvbybP_gDJ z9vX`Ww7qS;goPk4#~llZ#+BqfCK~t+m5CUTj~`0FbWWs;HQ3Nc<}XPNTHcbWUX_lX zz9F{4K$G>=h8(b|U@#b3<6lLJ)> z#>~pPpTk0WT0uCOK$S?ZXwlWzX(^KX7{r#wZS?`gV!&5yqVCA&#YB+Qe3aTO8ufSc zz0ac|m&rt$%&}20FwpjkAV6ofcb}M8WLS8e!q?31LCI^iN(FW2)3hETuUbkW$;d+I z!pP;pVB~m(w&b7}D=%xSQpCpeA~rHyfEucwJ$k-=nJX0q)Buq*8`@`@btjt|eQhrh zL}fqxS|0g3HRjtCm`n`F`Wb_K*`U@mclco{0Vo4A>NL`l7;_$6MGkyA{t$tJO9ZY5 zm(!>?N2hH%)sBZI#nIUo`agw$fv2CL$LJZ-<6t*X(+xx#yr^aolH>5PYWC?=Auu&v z)u@zIrb)OD6Ep+;pKa2!gJKMTtn&vC*C8nlCBT#sJ{^Q_jw z_!e8( zH{_3mOIpz&X!rK9(mh`g9n9e7jrLuqyZQcd$?zZud^tTg2CBS8G=b`Se(2|qFuj~S1q!jQb-EtO>VUcuNaq0DsR_hfVQ!)vG(IB`Z& z68XzZPuL=T##WKk?d81+G z$cq_MHN-3tL=gm#$O9^%M_5+BaN5a+2Y7gJF4gFw;p?odH5jv&w8b9Z$os#VfS8s? zh)XGbCrP}fy870b+-HQl)0&hm8RZNIAR6Hz_349Yc-)v1#aW1cqXW%=9QdOkw5Uz! zLGMJc4pmY+GmFV*5^ZT!vfU0@{F=dwZ0l?IvJX%NA=~VJX@u+usTFpZzSAQ6U|^W-Zt(UfLP%{ z;9`E4UHQ#0G1*GNKf{3c=Rc~S$uA$eHtgq&rz_)s+z zJM#s9dd(`5VTb-#n8-B)a5o5{XC*$e{13`dr2_X>Hn186uyrzhR}n9z!^;2uiiq}3 zV9M>HjCDY*5MSuycMXW&%A<*rI0}?b{M(MnR5gs>iZ8$gX5C^EfNHo z=-w36;@yF=*Q2HvNPVYMLzB44pL;%QsQP>8a`h*-vVVQGCj<$Knzfq_w;`9Nya>p#mjsU zQDh6XEbS)x^?}Hk9rKS0u!AJ|6vyz;SouaTH9P@~`#PA0A-BA#c&}kH_TDZp0l3g8 zv4MwesEDyxgl_b1j8nOw9jU3`t_uzBVa7Au6*FRA8QuSzp=?6XzwY?c6$w|mD+D@S z9=}UYiQZg3_~8oZU-PZ!dRR4`@q;(;JGW;{sWwiS;dF323hYvdkA(RxN$cyW;oGj9 z%@KMwK3v0g`uTPI7?uL9O01<`6Md4lS8Y&4yJiM!7&p$4Lt}ar^gsQXTkBT{dj^Vn zi*$MB6`lvz@i9crm25o^X^w4UG|#7}_xDjo@_BRYJ{wT<*Y3xP{xu{AAkE&cTt?z@ zgUg;w_XU;GOxo!c1_!&o0ncv#jaWo1#Avk-18NO9;vquT&}E7uolO!Mw-y}~Ygz#5 z+t*Ik6f5C)Q^qX8Z0f3!B*tgOwSqt5@qKl#Pbx&`-@RkV$qnzYMCiB!TLT5^o|QpN zBX9pC2_IfbB&kV$nXF1dY|I!n*6kPN%gaN;kR{OQJEFP#(8vh<1a}Ouw^!Ge9nw0; zJCb2nHa{ZIwj}Dmy#O(!iWl-Y^qvcPIbnmSuYKvwgYPWR>-;czj@F3?M?GewZ)^C< zW&50hMm&1Kn-jRg_T_=j_(O(ETivBn*iaf`&y%2cEh>c| zyZoOrz_o>d>GJKs&fCW9s2X>+Nv)Rr*H=Gi_4K2tkdmY2nQ@fri;3-W$v8g&j*0w` z-w4VDRENf>9-B}djv#W@y@!3d-z#kDnp)}W#*Ec|ThrkO&qb3^H zHM?-BRFf&E3@x=r=TY@9=Ajb0Q=>xIOamwqu4eYQj%M0nRLAedUuz!XG$8c#sz^;E zod*o0ls>JPA6U_MH!{M0*K}-O5kgD-h@0hV>k3;=Sd}^^F?=+<8QLt|UC6CqJBvJF zi$>i(iL%=*$xkUEU1U57k)8NfWJhu;6*XPQ9`&B78FYz|sX&m77M#1EVW!1)!to0% z1!Xj!pOP^RC<&dYrBz$)?|f+`#(~4gCu5X_OsrJLbEBJ$^<}Tws;E^V0>M`t*XTnNMSVJGjzGn{uBkR;?u05|sCVujh>$b1^DZh?jI8;gHbn~Z z-o6=Be(x@YtkkyVanGIwwiO7!Vm;j5V^4CE>@a%Lm3+ZOztNHnTQ(^ z-;JSItiI_`J7*uA5d#0rrOxJeNfho^4X@8~m+~B+PiB)Ri#j1OrUJvD6ZN!g#dvUp zt>%2K)%gyMq~!FEi}ebd3(<<7?BuOs$*aH1K1D*QM{r!ZXPc?_qk5yN89}Ufq(nc} zL>uJX#b+0x^>%$qb#4~JAUrn(ZGtj8%XRgO|0M>@)xAD;K*4qg*G_jV361t8EsWVJ zaKV7UE@XIb(DKD%)j`l6JrPu$#vAyNi}=_luYvv$dy7OLliSI1H;iC8!qW|;JGmR` zq)R{{0*#}M;#6cwOjj{ggo_prJgHTTMm!&ko3;(SO!pIf_ZHGb_py9Fw%Vf(whw$q z6VVY6oPCmG6fxSJxz&6&7A_}Enh9Mp&?&&=&pZ<~;=wGe%etFKYsBUw>|(C?G8k)Gej$;&+g*F zOS{brM%YW`>q3wE(0PSMJ@h*~MtoQckI|w{o=; zF)R(6lh7@4kvgYmaz}~{zrh%4B_@|RFgs&gZ3@LM?vGuDV&NKRIGCH&lj|I1u;k(O zDl)Mgob2EbIxQ?YTUf4Y=%})~0zE8byJ6me8RPh?IT4M;Vp3et*wF6){=dM}huY?f zu;kGV?ET3-RQ2vGvAD(XD26LSn8>$1O0qla$nxi#8QrGZd>auJBOVM1i1O~}7D|s@ zogVH+FOp`Nn}P0y)kbvD<0}%A8Gg_|X+UbIL~$(%-WKGLvO~HnbjYQ&*LX!9^i!e9 zUP|C8?lGnDEDmIm*BVAP$k(R~sD4N1pjd6`7q@8s5W0iWO2lT0O_<&~OmS!36#Ch# zw6+j3{UCqGUSmDont}y!fVfbMa^ml`*<=*V82QbK;r=be{OwTv z$Yh+T!Eee1PXQZBvrlRdbpN@KYT~WYnt|_3uZ9wy*0@AU%ix?Jg(vxPu%>_~H$Uix z%1I4)T~BqpU1N_&67<6&x@3pzg`GYauj}v>P(7 zbo>x%UgRtdIv37_)duuNq$jvsbqdE)SzjfctSlumV*M@pdqs@ zdu+Y?hk@MZ-<-$i5hKF*R}+-fPe2x!yq1^V=yqF=>H^4n6;B@X!ql7pR zMm(*(APvZY1GDiLPs+-4?@~O{aQtX~+{9(aV*$dP9u9&Zcz#!xf65-@LF1C~Mmv$UTaKq+i;v*}^x#A2<+KP)>{Zcz^I zZz*v>VM-2mDgu5em=N<_QKNApNUipB*lWdtd~sX)0CEZ#h>8`}Ql zCcS>$`XObT?V>zn36IQZzkW*dfiKYQ7#*YcUxmk(XF8Xu9I7Q~R*mxO#L5~-3S$9l z(gMvCh|&=GAN)uK=KX_N(BLosw@=E8@`~zf*HKcstly&0x+n}ocS|D;LwAF83WziU z(jh&B%+N6-C5_YoLrEhgNOyN$0qF)oQeY%LuJ=2Czmr?z23Ebox(n(Oj&7DhGBupoVZkq{xK1xt|60LfiS-^=7>%-ZoPD{Zi+;3g;wP5Fp70fHW89A!boLfGyme^p zG6Z9u;2$h3!Wzma_oK+Mw%G48*M%$AD@YP)bDr#sMQTyUrwbJ*#%K&yHth9H!#5UH zG>!QubqFUi|I>2#Y4W?Kac--Mw;B~K_*X;u=9TBO#y6E+wQOH(n~j6!8@jvV=ntq4 zy>M*X=LTe6*7zj6H~W<1u(c)W`xgUobwXp}J7LDP`CN-rS<8y-fLx z`Z?33Gity!>sd=6>oF9fbEVLzS}R;SLYl}J3o|$s`I>LH>i&B z`gaXSrx3}abxwd*OxZOREn`~H`%a9HL0H@gSBr5MYYp86Fy9)>wB>?z^10RyGLkdB zWIAALI;y*fo7Xe27RW83!y=n9zpGRT9D_lGC4(U&mx|NI32?=~Dj2!|`7B;n6q zs?neGIBpowyR9)qBXUI?2g>|KT(@GyrSJzTuFBuZ;?qw#&uF+V)=>8Df4?y(R+3KA z)rjzyXkx=y7Xu&vAc05Cio7{)n|2rZq8(HjKaqXgICQst?IjsV8?OosVt18oz*2J# z8ho%~O`(s#UPzO&{&C6|0hYog0s^P<7Io zD(U~^cumw_Pw<26)b$p0@)9wJ&ae_Af6D*H>j2Z2(5N(09QINH>-}C^V2l7vaYEbm z{!q)DR2(r#F?Ddicv_aUrzpx#7BBeZT&|-e_fTXQ1uokxoO8ZLVPFaV zV-D}gEDGQ(JAu+DMW-%MtQ*tz$K8xVOV2TzK;rikuQBfr@uOF3E9t6$E+SwC-8wX3i{XRp`eu!+HsD6=QF#7Fd(fq%H-@1pgQ+xD3bXS5?kiU+;VMHN&h2&qAMoS2Dm7{~ARDkPti zzo2>kG&kArkosQTtlcXEhY)>N|$T7jg3h{mo;qqlHEejpzQ6OD;@T+Z^m#OlY!P#7ex)G_J4#(!x zm0&V_YWHX(dgUKj8#tiIsqAVg?e>kMgNKZ;s@{u6w{MrBxkG|CkZ(k)SfwQIk4 zZuhi%sNVh2tXzKoGTD$y$*uT`z{QwZNKcfQ3%}pMTzT<&twqh_PFsX-Ao*v)recln ztho>-8goxb^7;3cAZjt!rRY9KSzjs&bmm?SC=yE_g23I)Kb z=AD$v&L#EoK>p+dB9N8NtCr*j z?8bNqHnp+1M6+YJP#gNJv41hlWwmc}cirCqU5G}atyCDszZkCU`=_xCTU_dB@5Oyo ztk<5`X1e`r+IRBT_=ZUhc3hpMuYaG9CV1Nb*p<65s{j##>!JLOjk)onTUoZhrh>n} ze}}(tH;2_pblLxl(%t4Tu@F1vAd2F$=8ecoUIT>IC#L~WkBQk`_$VcmSkS~6>mzb` zOmK8VtPGDC2(50P4n^MSSHA1EoYgcOc-8yRouB{k%^cH~bDh1zZ4X+!4fURex$T=Y zk-EdpKLn>BH#{8#__Ti--M#rRLUm|&7*tjb6*NdU4qbjvCs;PxI)da-swEP4RfXn9 z)Fw2x8I%c?gAI~@UuCtS*}koUj@`VvtBb8H=wFcL7^XTTH4WpKjVR(>x<0Cq2FCfY zJ|6I*g0Qbwq8Q7#?=QNXok*mxd^8e`7x|~y?^u8x!6!oIM_UmvyF09OhkcWT)J|ig zE?x6|GbZ5Ets9zMu|)cj2Gm0q!+X5=CZ{Ho>N2xV`t1_2G-?Fvp!d@U&JN!V z<*xY~275&Z1F^G18U5n?n;7rb!QN_1#-0U$zQ&0H)@RMds7}Q5Ze8EO#Bh#9BC=N)1|m z0e7*hj=s?8h3A`}Cv@84rAYFox#%xP2>37$FN8Xa03HgYB^7K@v1e5oQ&=XcuVFVp zg;4*4-aOLf6yk#|gL}Vf0-o^A0eZ}9>!pOTCx;UR(IwrgkgB@)e*J90EQ!>XPd`vQ z4Y6=xNprh zpa5z6A+-F_UKCb9h($}|SnTQV?ugXTtLo%f^K9^wBbgu4d=mC(rAt5y>BQ{q+wW2a zZO&j@{}*l;@~j4Dqg?kKmP;iY-)%WZS=Y#m2d5ziqEDv+QInvkX(glU*r$g{A7Gq_MIK!uL=*xAy+`4^s>6KuxbCG z4%RnHv_D0Uqg{oz;J4Q}lunY}mVeBc6Eo0dO%x;doZuiWpV<}{8d3lBTIUvsQ%gx< z*69P6`)ammSTUlNOCI*61Zg#dmEy^)AiD6_2gVhE&1j~8U7iml0j3=GUGYmfThz-go3xL@J62>DDUV8ETQw)i#&EaBexqvvhX~md`AQSwtvg{3DD#OQ_sy zOLqm>&!C#+(3%dJE@Bew<0mH>>`mHK_ZVyxoo-NYJJ1I5p2_g71!HTCHptkPswRZ_ zAYhKP-(F9K$=tF(v_P~p$<$PhsY9SlT)l*gi#nyt4T4;dOT@4tyVXY5hCle2uEDD! zw9~e?)@9n$_2WE}E38PprGb*0Fp7Fj@vLSM1vE9ITH>B2PE;(IYR}7k=j+P*nb!;> z-zv`CDU3U*wZ^B7MJy48L|HDlXGSpRSzbANUI-?PIr_*7HB2;N6Ra5AI zoS7W-HPDczx2Eh=HZ=!TDBKA0}zctc+YdZ>OC(NSQ}GuiGeq8kcFQn?OMmA^t`1!1NDo5Flaw%|Lq z_$t4No$cT%y_5@wf=M7Qo+lX_5%}9J|5E6TL{}GqXnczF=uW12TLDx^)mtgTE!4g+ zU#wXb&n6xTs*gBZ`gz!@o|wSB z(d6EwXaRT8h*bj&y#LcZ;qtc2YzHix?QzGBbXUXz+e7FO=^itL$? z!?8>9TCBD)4Hut8sQH%wY`F)H;G|tLCN)zDoxM?IBO^l}+MCTFJ5OEt?)k|#|M{v2 za`egy-<~X8j+x4gfCB|_D(T;9TiIR@$xUsA+uHh(4O-mO8k{I{^|kho1ax?E5!Cm; zwl2DmH^}eWS;vQRd>=e|r#W|&3?xdVG>@czV=1-jZ*2Z%N(Ko0oVAL~QCIx#4%)u* z#K8n745&D(j*z44vSD;NV)W?PZw21ik1=rF8K*L*DnD~6F08aHcZC*KW|_s;$pxm- z*{`%FPU;y61m~NQy{D7J1Ff9(pk1T4opM>B{_QKM%6GMJnKczPfg#JQvVT~dH_O;< zos33y0=(|6aRbYjn70QRmvqUjf`s+6Q1D8l^YdU#7yOhw=Jk{;%L#*j)*=~S?Wnt4 zFA(S8RI+MH3Vvq?6T{=1q`?Xgzg~p4Q$h&vyA~$JHg2x$o%U4{#5go_AY_7+I*1r= z`-YPy+*la~1Vn=)zwS4W<+Ci5vG#t(KngQ@iXpv))+*?AcVK*-`JnCAiJ+#MZHLy` ziZCdZtrpmuSA;$#v-8Pb;uF!dEdUp)m{2^cI}P%#w_D2fWRUSk4`{_j0(rFh(JvE2 z&G}Ss0t!DtK)~i1!BmhTwOV_+o}QYYW5e&lrpx;U8Z|`~sgepPXE~UTgLME`2^29iDt9hQ^ZkmZ`C3XhO7xnJVtvyFueD zJ_kH42pyVHG7I;7tHaO7Q}q&MBF`8Y;d&~N`q$1eSDz%s4iGxsZAMs=I#Dx`qprFJ z*^Hx>p!Fm5_^H!VTt6(Kt%Nz~q@IuW+Xno-xK01n*c`pRhHe0~=jGNvqa!n9vuIIOZ$SFik!v*?@6 zH(#Bg3z2z>oip19kd)Yv75(&3VMveLW!8l<0cSDgekF5gLn3}%cGD>jSg7?>)z3lK zaPWo~4X4yYw28vb9g2N)C@5*e^8Udr$W3QkPMCRVh+lFfOE_N#<4pkNvd9plK1s6c60Vp)Ysc zHl}MVMF>jfC~+*FXq@wv4yScJ+D0+4OZ*KhPW0EWUz0#Y0L#I0Q9sOguu;B3`Ad1n z1X6|CI3@Gi(U>I1nNCq8?JyVvO*q{!b9vmnCd&FA>}VRA8XKWGUy&CI_HrPQdKwGd zHi@jVp}}Wp+)Zyx)nP z3LO4kRv3T*M5V#&TBZzEXXXW?w2QrN62#hKeA+b32IVObUNK%l86uHh(PeU|wBf!r zlV1P=A3u%#Mf^J#V0L*9m-B>Cx`cxp1@cCP=Q|!VLJ!b)`^DS@{4zIlIg&igqipRW zgkPOq?s%4zI0g=&tpn9%_2<6zU3ab*?%#R>#2F{Yot1u*OGCAxKp_E`P;65Oq}jA| zNU=U6V}69%DK6j29FzT(4tj14RVT#vihd*jeluT1yPlEl!l57h!a~P!+clRO^^6*k zX_~dU^mQEQv$eHxRKm&&LFbGOwtH^1dm=Xww%n}`2#Ws@+i2wsoctJVTG&V&5bwCB zFNoU9bQ(#D;6=_?WZw{|(?)goiBrcF!5BFY^n1#GCNT|-2>nHLG?nBXB@iN5p#P_j z1qcA|PtNyiY8OPfQ3uTG&H4U)#pS7S`ueLhnQTV_4tx3EHh=!h^0Tt-Xv5iHaUMTv zG;P_sLb+2_9RC6}cmNyhm!G@*d{-R{&)J{rdu$bNkVw$7Irtc0P`gJ(*PGzHLfc^b zuXFE&&6)V89>R7Qh#xFXT5Y*gj7s_~XwSoSG3mON$~0ck+ox! zUvo*^`OB%aF#=9b3M)*OGgYR4W*S;1Vh1jP*yS4;L_WYbt1|E^en(e=B@l2_Z@<58 zge?;>WfStbN@JVkxD=@akG;?iXo|RNg|4}v-VBwP=Nm^?>KAN2>3`3IKu7P3G|eSI zQ=2BU%}``=(NRK&-rfNf+~M0`QsTF$iMmf%1O-xOs5aws(xdU8yQi%8?7GB%wIJ7! z_g|_stoRg^6zyNKN}M=4E99}ZTI~aT6Ke2CM5&$bLc`utkMguMRCJW96|KVm2bwQ2 A5&!@I literal 0 HcmV?d00001 diff --git a/vi/index.html b/vi/index.html new file mode 100644 index 0000000..df003d8 --- /dev/null +++ b/vi/index.html @@ -0,0 +1,119 @@ +--- +layout: vi-reference +--- +
+

Giới thiệu về Tham Khảo Git

+
+ +

+ Trang này là tài liệu tham khảo nhanh cho việc học và nhớ những điều quan trọng và những lệnh thường dùng trong Git. các lệnh được tổ chức theo từng phần loại tác vụ, và sẽ trình bày các tùy chọn và các lệnh thông thường cần thiết để hoàn thành tác vụ đó. +

+ +

+ Mỗi phần sẽ liên kết đến phần kế tiếp vì thế có thể được dùng như một hướng dẫn. Mỗi trang cũng sẽ liên kết đến các tài liệu Git sâu hơn như các trang hướng dẫn chính thức của Git và các phần liên quan trong Sách Pro Git để bạn có thể học sâu hơn về bất kỳ lệnh nào. Đầu tiên, chúng ta sẽ bắt đầu suy nghĩ về quản lý mã nguồn như Git. +

+
+ +
+

Làm Thế Nào Suy Nghĩ Như Git

+
+ + Điều quan trong đầu tiên để hiểu Git là suy nghĩ về điều khiển phiên bản + rất khó khăn hơn Subversion hay Perforce hoặc bất kỳ SCM nào bạn đã dùng. + +

+ Let's start from scratch. Assume you are designing a new source + code management system. How did you do basic version control before + you used a tool for it? Chances are that you simply copied your + project directory to save what it looked like at that point. +

+ + 
 $ cp -R project project.bak
+ +

+ That way, you can easily revert files that get messed up later, or + see what you have changed by comparing what the project looks like + now to what it looked like when you copied it. +

+ +

+ If you are really paranoid, you may do this often, maybe putting the + date in the name of the backup: +

+ + 
 $ cp -R project project.2010-06-01.bak
+ +

+ In that case, you may have a bunch of snapshots of your project that + you can compare and inspect from. You can even use this model to + fairly effectively share changes with someone. If you zip up your + project at a known state and put it on your website, other developers + can download that, change it and send you a patch pretty easily. +

+ + 
+ $ wget http://example.com/project.2010-06-01.zip
+ $ unzip project.2010-06-01.zip
+ $ cp -R project.2010-06-01 project-my-copy
+ $ cd project-my-copy
+ $ (change something)
+ $ diff project-my-copy project.2010-06-01 > change.patch
+ $ (email change.patch)
+ +

+ Now the original developer can apply that patch to their copy of the + project and they have your changes. This is how many open source + projects have been collaborated on for several years. +

+ +

+ This actually works fairly well, so let's say we want to write a tool + to make this basic process faster and easier. Instead of writing a tool + that versions each file individually, like Subversion, we would probably + write one that makes it easier to store snapshots of our project without + having to copy the whole directory each time. +

+ +

+ This is essentially what Git is. You tell Git you want to save a snapshot + of your project with the git commit command and it basically + records a manifest of what all of the files in your project look like at + that point. Then most of the commands work with those manifests to see + how they differ or pull content out of them, etc. +

+ +
+ +

+ If you think about Git + as a tool for storing and comparing and merging snapshots of your project, + it may be easier to understand what is going on and how to do things + properly. +

+ +
+
+ +

On to Getting and Creating Projects »

diff --git a/vi/inspect/index.html b/vi/inspect/index.html new file mode 100644 index 0000000..cbf46f4 --- /dev/null +++ b/vi/inspect/index.html @@ -0,0 +1,475 @@ +--- +layout: reference +--- + +
+

+ + book + + Inspection and Comparison +

+
+

+ So now you have a bunch of branches that you are using for short lived + topics, long lived features and what not. How do you keep track of them? + Git has a couple of tools to help you figure out where work was done, what + the difference between two branches are and more. +

+ +

+ In a nutshell you can use git log to find specific + commits in your project history - by author, date, content or + history. You can use git diff to compare two different points + in your history - generally to see how two branches differ or what has + changed from one version of your software to another. +

+
+
+ +
+

+ + docs   + book + + git log + filter your commit history +

+ +
+

We've already seen how to use git log to compare branches, + by looking at the commits on one branch that are not reachable from another. + (If you don't remember, it looks like this: git log branchA ^branchB). + However, you can also use git log to look for specific commits. + Here we'll be looking at some of the more commonly used git log + options, but there are many. Take a look at the official docs for the whole + list. +

+ +

+ git log --author + look for only commits from a specific author +

+ +

+ To filter your commit history to only the ones done by a specific author, + you can use the --author option. For example, let's say we're + looking for the commits in the Git source code done by Linus. We would + type something like git log --author=Linus. The search is + case sensitive and will also search the email address. The following + example will use the -[number] option, which will limit the + results to the last [number] commits. +

+ +
+$ git log --author=Linus --oneline -5
+81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
+3bb7256 make "index-pack" a built-in
+377d027 make "git pack-redundant" a built-in
+b532581 make "git unpack-file" a built-in
+112dd51 make "mktag" a built-in
+
+ +

+ git log --since --before + filter commits by date committed +

+ +

+ If you want to specify a date range that you're interested in filtering your + commits down to, you can use a number of options such as --since + and --before, or you can also use --until and + --after. For example, to see all the commits in + the Git project before three weeks ago but after April 18th, you could run this + (We're also going to use --no-merges to remove merge commits): +

+ +
+$ git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges
+5469e2d Git 1.7.1-rc2
+d43427d Documentation/remote-helpers: Fix typos and improve language
+272a36b Fixup: Second argument may be any arbitrary string
+b6c8d2d Documentation/remote-helpers: Add invocation section
+5ce4f4e Documentation/urls: Rewrite to accomodate transport::address
+00b84e9 Documentation/remote-helpers: Rewrite description
+03aa87e Documentation: Describe other situations where -z affects git diff
+77bc694 rebase-interactive: silence warning when no commits rewritten
+636db2c t3301: add tests to use --format="%N"
+
+ +

+ git log --grep + filter commits by commit message +

+ +

+ You may also want to look for commits with a certain phrase in the commit + message. Use --grep for that. Let's say there + was a commit that dealt with using the P4EDITOR environment variable and + you wanted to remember what that change looked like - you could find the commit + with --grep. +

+ +
+$ git log --grep=P4EDITOR --no-merges
+commit 82cea9ffb1c4677155e3e2996d76542502611370
+Author: Shawn Bohrer
+Date:   Wed Mar 12 19:03:24 2008 -0500
+
+    git-p4: Use P4EDITOR environment variable when set
+
+    Perforce allows you to set the P4EDITOR environment variable to your
+    preferred editor for use in perforce.  Since we are displaying a
+    perforce changelog to the user we should use it when it is defined.
+
+    Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
+    Signed-off-by: Simon Hausmann <simon@lst.de>
+
+ +

+ Git will logically OR all --grep and --author + arguments. If you want to use --grep and --author + to see commits that were authored by someone AND have a specific message + content, you have to add the --all-match option. In these + examples we're going to use the --format option, so we can see + who the author of each commit was. +

+ +

If we look for the commit messages with 'p4 depo' in them, we get these + three commits:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s"
+ee4fd1a Junio C Hamano Merge branch 'master' of git://repo.or.cz/git/fastimport
+da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+
+ +

If we add a --author=Hausmann argument, instead of further + filtering it down to the one commit by Simon, it instead will show all + commits by Simon OR commits with "p4 depo" in the message:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
+cdc7e38 Simon Hausmann Make it possible to abort the submission of a change to Pe
+f5f7e4a Simon Hausmann Clean up the git-p4 documentation
+30b5940 Simon Hausmann git-p4: Fix import of changesets with file deletions
+4c750c0 Simon Hausmann git-p4: git-p4 submit cleanups.
+0e36f2d Simon Hausmann git-p4: Removed git-p4 submit --direct.
+edae1e2 Simon Hausmann git-p4: Clean up git-p4 submit's log message handling.
+4b61b5c Simon Hausmann git-p4: Remove --log-substitutions feature.
+36ee4ee Simon Hausmann git-p4: Ensure the working directory and the index are cle
+e96e400 Simon Hausmann git-p4: Fix submit user-interface.
+38f9f5e Simon Hausmann git-p4: Fix direct import from perforce after fetching cha
+2094714 Simon Hausmann git-p4: When skipping a patch as part of "git-p4 submit" m
+1ca3d71 Simon Hausmann git-p4: Added support for automatically importing newly ap
+...
+
+ +

However, adding --all-match will get the results you're + looking for:

+ +
+$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
+1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
+
+ +

+ git log -S + filter by introduced diff +

+ +

+ What if you write really horrible commit messages? Or, what if you are + looking for when a function was introduced, or where variables started + to be used? You can also tell Git to look through the diff of each + commit for a string. For example, if we wanted to find which commits + modified anything that looked like the function name + 'userformat_find_requirements', we would run this: (note there is no '=' + between the '-S' and what you are searching for) +

+ +
+$ git log -Suserformat_find_requirements
+commit 5b16360330822527eac1fa84131d185ff784c9fb
+Author: Johannes Gilger
+Date:   Tue Apr 13 22:31:12 2010 +0200
+
+    pretty: Initialize notes if %N is used
+
+    When using git log --pretty='%N' without an explicit --show-notes, git
+    would segfault. This patches fixes this behaviour by loading the needed
+    notes datastructures if --pretty is used and the format contains %N.
+    When --pretty='%N' is used together with --no-notes, %N won't be
+    expanded.
+
+    This is an extension to a proposed patch by Jeff King.
+
+    Signed-off-by: Johannes Gilger
+    Signed-off-by: Junio C Hamano
+
+ +

+ git log -p + show patch introduced at each commit +

+ +

+ Each commit is a snapshot of the project, but since each commit records the + snapshot it was based off of, Git can always calculate the difference and + show it to you as a patch. That means for any commit you can get the patch + that commit introduced to the project. You can either do this by running + git show [SHA] with a specific commit SHA, or you can run + git log -p, which tells Git to put the patch after each commit. + It is a great way to summarize what has happened on a branch or between + commits. +

+ +
+$ git log -p --no-merges -2
+commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 15:46:55 2010 +0200
+
+    reverted to old class name
+
+diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+-class HiWorld
++class HelloWorld
+   def self.hello
+     puts "Hello World from Ruby"
+   end
+ end
+
+-HiWorld.hello
++HelloWorld.hello
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+diff --git a/README b/README
+index d053cc8..9103e27 100644
+--- a/README
++++ b/README
+@@ -1,4 +1,4 @@
+-Hello World Examples
++Many Hello World Examples
+ ======================
+
+ This project has examples of hello world in
+
+ +

This is a really nice way of summarizing changes or reviewing a series + of commits before merging them or releasing something.

+ +

+ git log --stat + show diffstat of changes introduced at each commit +

+ +

If the -p option is too verbose for you, you can summarize + the changes with --stat instead. Here is the same log output + with --stat instead of -p

+ +
+$ git log --stat --no-merges -2
+commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 15:46:55 2010 +0200
+
+    reverted to old class name
+
+ ruby.rb |    4 ++--
+ 1 files changed, 2 insertions(+), 2 deletions(-)
+
+commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
+Author: Scott Chacon <schacon@gmail.com>
+Date:   Fri Jun 4 12:58:53 2010 +0200
+
+    fixed readme title differently
+
+ README |    2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+ +

Same basic information, but a little more compact - it still lets you + see relative changes and which files were modified.

+ +
+
+ +
+

+ + docs   + book + + git diff + +

+ +
+ +

Finally, to see the absolute changes between any two commit snapshots, + you can use the git diff command. This is largely used in two + main situations - seeing how two branches differ from one another and + seeing what has changed since a release or some other older point in + history. Let's look at both of these situations.

+ +

To see what has changed since the last release, you can simply run + git diff [version] (or whatever you tagged the release). + For example, if we want to see what has changed in our project since + the v0.9 release, we can run git diff v0.9. +

+ +
+$ git diff v0.9
+diff --git a/README b/README
+index d053cc8..d4173d5 100644
+--- a/README
++++ b/README
+@@ -1,4 +1,4 @@
+-Hello World Examples
++Many Hello World Lang Examples
+ ======================
+
+ This project has examples of hello world in
+diff --git a/ruby.rb b/ruby.rb
+index bb86f00..192151c 100644
+--- a/ruby.rb
++++ b/ruby.rb
+@@ -1,7 +1,7 @@
+-class HiWorld
++class HelloWorld
+   def self.hello
+     puts "Hello World from Ruby"
+   end
+ end
+
+-HiWorld.hello
++HelloWorld.hello
+
+ +

Just like git log, you can use the --stat + option with it.

+ +
+$ git diff v0.9 --stat
+ README  |    2 +-
+ ruby.rb |    4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+ +

To compare two divergent branches, however, you can run something like + git diff branchA branchB but the problem is that it will do + exactly what you are asking - it will basically give you a patch file that + would turn the snapshot at the tip of branchA into the snapshot at the tip + of branchB. This means if the two branches have diverged - gone in different + directions - it will remove all the work that was introduced into branchA + and then add everything that was introduced into branchB. This is probably + not what you want - you want the changes added to branchB that are not in + branchA, so you really want the difference between where the two branches + diverged and the tip of branchB. So, if our history looks like this:

+ +
+$ git log --graph --oneline --decorate --all
+* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
+| * 1834130 (erlang) added haskell
+| * ab5ab4c added erlang
+|/
+*   8d585ea Merge branch 'fix_readme'
+...
+
+ +

And we want to see what is on the "erlang" branch compared to the "master" + branch, running git diff master erlang will give us the wrong + thing.

+ +
+$ git diff --stat master erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ ruby.rb       |    4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+
+ +

You see that it adds the erlang and haskell files, which is what we did + in that branch, but then the output also reverts the changes to the ruby file + that we did in the master branch. What we really want to see is just the + changes that happened in the "erlang" branch (adding the two files). We can + get the desired result by doing the diff from the common commit they diverged + from:

+ +
+$ git diff --stat 8d585ea erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

That's what we're looking for, but we don't want to have to figure out + what commit the two branches diverged from every time. Luckily, Git has a + shortcut for this. If you run git diff master...erlang (with + three dots in between the branch names), Git will automatically figure out + what the common commit (otherwise known as the "merge base") of the two + commit is and do the diff off of that.

+ +
+$ git diff --stat master erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ ruby.rb       |    4 ++--
+ 3 files changed, 11 insertions(+), 2 deletions(-)
+$ git diff --stat master...erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

Nearly every time you want to compare two branches, you'll want to use + the triple-dot syntax, because it will almost always give you what you want. +

+ +

As a bit of an aside, you can also have Git manually calculate what the + merge-base (first common ancestor commit) of any two commits would be with + the git merge-base command:

+ +
+$ git merge-base master erlang
+8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
+
+ +

You can do the equivalent of git diff master...erlang + by running this:

+ +
+$ git diff --stat $(git merge-base master erlang) erlang
+ erlang_hw.erl |    5 +++++
+ haskell.hs    |    4 ++++
+ 2 files changed, 9 insertions(+), 0 deletions(-)
+
+ +

You may prefer using the easier syntax though.

+ + +

+ In a nutshell you can use git diff to see how a project + has changed since a known point in the past or to see what unique work is + in one branch since it diverged from another. Always use + git diff branchA...branchB to inspect branchB relative to + branchA to make things easier. +

+ +
+
+ +

And that's it! For more information, try reading the +Pro Git book.

diff --git a/vi/remotes/index.html b/vi/remotes/index.html new file mode 100644 index 0000000..7815353 --- /dev/null +++ b/vi/remotes/index.html @@ -0,0 +1,440 @@ +--- +layout: reference +--- + +
+

+ + book + + Sharing and Updating Projects +

+
+

+ Git doesn't have a central server like Subversion. All of the commands + so far have been done locally, just updating a local database. + To collaborate with other developers in Git, you have to put all that + data on a server that the other developers have access to. The way Git + does this is to synchronize your data with another repository. There + is no real difference between a server and a client - a Git repository + is a Git repository and you can synchronize between any two easily. +

+ +

Once you have a Git repository, either one that you set up on your + own server, or one hosted someplace like GitHub, you can tell Git to + either push any data that you have that is not in the remote repository + up, or you can ask Git to fetch differences down from the other repo. +

+ +

You can do this any time you are online, it does not have to correspond + with a commit or anything else. Generally you will do a + number of commits locally, then fetch data from the online shared repository + you cloned the project from to get up to date, merge any new work into the + stuff you did, then push your changes back up.

+ +

+ In a nutshell you can update your project with git fetch + and share your changes with git push. You can manage your + remote repositories with git remote. +

+
+
+ +
+

+ + docs   + book + + git remote + list, add and delete remote repository aliases +

+ +
+ +

Unlike centralized version control systems that have a client that is + very different from a server, Git repositories are all basically equal and + you simply synchronize between them. This makes it easy to have more than + one remote repository - you can have some that you have read-only access to + and others that you can write to as well.

+ +

So that you don't have to use the full URL of a remote repository every + time you want to synchronize with it, Git stores an alias or nickname for + each remote repository URL you are interested in. You use the + git remote command to manage this list of remote repos that + you care about.

+ +

+ git remote + list your remote aliases +

+ +

Without any arguments, Git will simply show you the remote repository + aliases that it has stored. By default, if you cloned the project (as + opposed to creating a new one locally), Git will automatically add the + URL of the repository that you cloned from under the name 'origin'. If + you run the command with the -v option, you can see the + actual URL for each alias.

+ +
+$ git remote
+origin
+$ git remote -v
+origin	git@github.com:github/git-reference.git (fetch)
+origin	git@github.com:github/git-reference.git (push)
+
+ +

You see the URL there twice because Git allows you to have different + push and fetch URLs for each remote in case you want to use different + protocols for reads and writes.

+ +

+ git remote add + add a new remote repository of your project +

+ +

If you want to share a locally created repository, or you want to take + contributions from someone else's repository - if you want to interact in + any way with a new repository, it's generally easiest to add it as a remote. + You do that by running git remote add [alias] [url]. That + adds [url] under a local remote named [alias].

+ +

For example, if we want to share our Hello World program with the world, + we can create a new repository on a server (Using GitHub as an example), + which should give you a URL, in this case "git@github.com:schacon/hw.git". + To add that to our project so we can push to it and fetch updates from it + we would do this:

+ +
+$ git remote
+$ git remote add github git@github.com:schacon/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+
+ +

Like the branch naming, remote alias names are arbitrary - just as 'master' + has no special meaning but is widely used because git init + sets it up by default, 'origin' is often used as a remote name because + git clone sets it up by default as the cloned-from URL. In + this case we'll name the remote 'github', but you could name it just + about anything. +

+ +

+ git remote rm + removing an existing remote alias +

+ +

Git addeth and Git taketh away. If you need to remove a remote - you are + not using it anymore, the project is gone, etc - you can remove it with + git remote rm [alias].

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+$ git remote add origin git://github.com/pjhyett/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/pjhyett/hw.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+$ git remote rm origin
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+
+ +

+ git remote rename [old-alias] [new-alias] + rename remote aliases +

+ +

If you want to rename remote aliases without having to delete them and add them again + you can do that by running git remote rename [old-alias] [new-alias]. This will + allow you to modify the current name of the remote.

+ +
+$ git remote add github git@github.com:schacon/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+$ git remote rename github origin
+$ git remote -v
+origin	git@github.com:schacon/hw.git (fetch)
+origin	git@github.com:schacon/hw.git (push)
+
+ +

+ In a nutshell with git remote you can list our + remote repositories and whatever URL + that repository is using. You can use git remote add to + add new remotes, git remote rm to delete existing ones or git remote rename [old-alias] [new-alias] to rename them. +

+ +

+ git remote set-url + update an existing remote URL +

+ +

Should you ever need to update a remote's URL, you can do so with + the git remote set-url command. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/pjhyett/hw.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+$ git remote set-url origin git://github.com/github/git-reference.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+
+ +

In addition to this, you can set a different push URL when you + include the --push flag. This allows you to fetch from + one repo while pushing to another and yet both use the same remote alias. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git remote set-url --push origin git://github.com/pjhyett/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/pjhyett/hw.git (push)
+
+ +

Internally, the git remote set-url command calls + git config remote, but has the added benefit of reporting + back any errors. git config remote on the other hand, will + silently fail if you mistype an argument or option and not actually set + anything. +

+ +

For example, we'll update the github remote but + instead reference it as guhflub in both invocations. +

+ +
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git config remote.guhflub git://github.com/mojombo/hw.git
+$ git remote -v
+github	git@github.com:schacon/hw.git (fetch)
+github	git@github.com:schacon/hw.git (push)
+origin	git://github.com/github/git-reference.git (fetch)
+origin	git://github.com/github/git-reference.git (push)
+$ git remote set-url guhflub git://github.com/mojombo/hw.git
+fatal: No such remote 'guhflub'
+
+ +

+ In a nutshell, you can update the locations of your remotes + with git remote set-url. You can also set different push + and fetch URLs under the same remote alias. +

+ +
+
+ +
+

+ + docs   + book + + git fetch + download new branches and data from a remote repository +

+ +
+ +

+ + docs   + book + + git pull + fetch from a remote repo and try to merge into the current branch +

+ +
+ +

Git has two commands to update itself from a remote repository. + git fetch will synchronize you with another repo, pulling down any data + that you do not have locally and giving you bookmarks to where each branch on + that remote was when you synchronized. These are called "remote branches" and are + identical to local branches except that Git will not allow you to check them out - + however, you can merge from them, diff them to other branches, run history logs on + them, etc. You do all of that stuff locally after you synchronize. +

+ +

The second command that will fetch down new data from a remote server is + git pull. This command will basically run a git fetch + immediately followed by a git merge of the branch on that remote + that is tracked by whatever branch you are currently in. Running the + fetch and merge commands separately involves less magic + and less problems, but if you like the idea of pull, you can + read about it in more detail in the + official docs. +

+ +

Assuming you have a remote all set up and you want to pull in updates, you + would first run git fetch [alias] to tell Git to fetch down all the + data it has that you do not, then you would run git merge [alias]/[branch] + to merge into your current branch anything new you see on the server + (like if someone else has pushed in the meantime). So, if you were working on a + Hello World project with several other people and wanted to bring in any changes + that had been pushed since we last connected, we would do something like this:

+ +
+$ git fetch github
+remote: Counting objects: 4006, done.
+remote: Compressing objects: 100% (1322/1322), done.
+remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
+Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
+Resolving deltas: 100% (1526/1526), completed with 387 local objects.
+From github.com:schacon/hw
+   8e29b09..c7c5a10  master     -> github/master
+   0709fdc..d4ccf73  c-langs    -> github/c-langs
+   6684f82..ae06d2b  java       -> github/java
+ * [new branch]      ada        -> github/ada
+ * [new branch]      lisp       -> github/lisp
+
+ +

Here we can see that since we last synchronized with this remote, five branches + have been added or updated. The 'ada' and 'lisp' branches are new, where the + 'master', 'c-langs' and 'java' branches have been updated. In our example case, + other developers are pushing proposed updates to remote branches for review before + they're merged into 'master'. +

+ +

You can see the mapping that Git makes. The 'master' branch on the remote + repository becomes a branch named 'github/master' locally. That way you can + merge the 'master' branch on that remote into the local 'master' branch by running + git merge github/master. Or, you can see what new commits are on that + branch by running git log github/master ^master. If your remote + is named 'origin' it would be origin/master instead. Almost any + command you would run using local branches you can use remote branches with too. +

+ +

If you have more than one remote repository, you can either fetch from specific + ones by running git fetch [alias] or you can tell Git to synchronize + with all of your remotes by running git fetch --all. +

+ +

+ In a nutshell you run git fetch [alias] to synchronize your + repository with a remote repository, fetching all the data it has that you do + not into branch references locally for merging and whatnot. +

+ +
+ +
+ +
+

+ + docs   + book + + git push + push your new branches and data to a remote repository +

+ +
+

To share the cool commits you've done with others, you need to push your + changes to the remote repository. To do this, you run + git push [alias] [branch] which will attempt to make your [branch] + the new [branch] on the [alias] remote. Let's try it by initially pushing + our 'master' branch to the new 'github' remote we created earlier.

+ +
+$ git push github master
+Counting objects: 25, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (25/25), done.
+Writing objects: 100% (25/25), 2.43 KiB, done.
+Total 25 (delta 4), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch]      master -> master
+
+ +

Pretty easy. Now if someone clones that repository they will get exactly + what we have committed and all of its history.

+ +

What if you have a topic branch like the 'erlang' branch created earlier + and want to share just that? You can just push that branch instead.

+ +
+$ git push github erlang
+Counting objects: 7, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (6/6), 652 bytes, done.
+Total 6 (delta 1), reused 0 (delta 0)
+To git@github.com:schacon/hw.git
+ * [new branch]      erlang -> erlang
+
+ +

Now when people clone or fetch from that repository, they'll get an 'erlang' + branch they can look at and merge from. You can push any branch to any + remote repository that you have write access to in this way. If your branch + is already on the server, it will try to update it, if it is not, Git will + add it.

+ +

The last major issue you run into with pushing to remote branches is the + case of someone pushing in the meantime. If you and another developer clone + at the same time, you both do commits, then she pushes and then you try to + push, Git will by default not allow you to overwrite her changes. Instead, + it basically runs git log on the branch you're trying to push and + makes sure it can see the current tip of the server's branch in your push's + history. If it can't see what is on the server in your history, it concludes + that you are out of date and will reject your push. You will rightly have to + fetch, merge then push again - which makes sure you take her changes into + account.

+ +

This is what happens when you try to push a branch to a remote branch + that has been updated in the meantime:

+ +
+$ git push github master
+To git@github.com:schacon/hw.git
+ ! [rejected]        master -> master (non-fast-forward)
+error: failed to push some refs to 'git@github.com:schacon/hw.git'
+To prevent you from losing history, non-fast-forward updates were rejected
+Merge the remote changes before pushing again.  See the 'Note about
+fast-forwards' section of 'git push --help' for details.
+
+ +

You can fix this by running git fetch github; git merge github/master + and then pushing again. +

+ +

+ In a nutshell you run git push [alias] [branch] to update a + remote repository with the changes you've made locally. It will take what your + [branch] looks like and push it to be [branch] on the remote, if possible. If + someone else has pushed since you last fetched and merged, the Git server will + deny your push until you are up to date. +

+ +
+
+ +

On to Inspection and Comparison »

From 263f0554383cf09397746f60e6893e4bc74ab19b Mon Sep 17 00:00:00 2001 From: tuantda Date: Fri, 24 Jan 2014 16:15:06 +0700 Subject: [PATCH 2/4] Translate to Vietnamese base on translation of icyfork --- _layouts/vi_reference.html | 57 ++-- vi/README.md | 19 ++ vi/about.html | 13 + vi/basic/index.html | 521 ++++++++++++++++++++++++++++--------- vi/branching/index.html | 498 ++++++++++++++++++++++++++++------- vi/creating/index.html | 93 +++++-- vi/index.html | 98 +++++-- vi/inspect/index.html | 116 +++++++-- vi/remotes/index.html | 267 ++++++++++++++----- 9 files changed, 1312 insertions(+), 370 deletions(-) create mode 100644 vi/README.md create mode 100644 vi/about.html diff --git a/_layouts/vi_reference.html b/_layouts/vi_reference.html index c6916d5..8456233 100644 --- a/_layouts/vi_reference.html +++ b/_layouts/vi_reference.html @@ -23,11 +23,12 @@

  @@ -35,51 +36,51 @@
-

Nhận và Tạo Dự Án

+

Nhận và Tạo Dự Án

-

Lệnh Ảnh Chụp (Snapshot) Cơ Bản

+

Cơ Bản Về Bản Sao

-

Phân Nhánh và Tích Hợp

+

Phân Nhánh và Tích Hợp

-

Chia Sẻ và Cập Nhật Dự Án

+

Chia Sẻ và Cập Nhật Dự Án

-

Kiểm Tra và So Sánh

+

Kiểm Tra và So Sánh

diff --git a/vi/README.md b/vi/README.md new file mode 100644 index 0000000..75b6a22 --- /dev/null +++ b/vi/README.md @@ -0,0 +1,19 @@ +Đây là [bản dịch tiếng Việt][vi] của trang [Git Reference][en] +--- +layout: vi_reference +--- + +[vi]: http://gitref.org/vi "Tham khảo Git" +[en]: http://gitref.org/ "Git Reference" + +## Dictionary + +Một số từ, thuật ngữ trong Git sẽ được __"hiểu"__ trong bản dịch này: + +| English | Tiếng Việt | Ghi chú | +|:-----------|:----------:|--------:| +|reposity |kho lưu trữ | | +|snapshot |bản sao | | +|commit |xác nhận | | +|stage |chỉ mục |ghi nhận | +|staging area|vùng chỉ mục|vùng tạm | diff --git a/vi/about.html b/vi/about.html new file mode 100644 index 0000000..52a1118 --- /dev/null +++ b/vi/about.html @@ -0,0 +1,13 @@ +--- +layout: vi_reference +--- +
+

Ai đã viết tài liệu này?

+
+

Tài liệu tham khảo Git được viết bởi đội ngũ GitHub.

+

+ Bản dịch tiếng Việt bởi icyfork và tuantda +

+
diff --git a/vi/basic/index.html b/vi/basic/index.html index 6c765b5..ecfe124 100644 --- a/vi/basic/index.html +++ b/vi/basic/index.html @@ -1,5 +1,5 @@ --- -layout: reference +layout: vi_reference ---
@@ -7,29 +7,46 @@

book - Basic Snapshotting + Cơ Bản Về Bản Sao

-

+ +

+ Làm việc với Git chủ yếu bao gồm tạo và so sánh các bản sao của dự án. + Phần này trình bày về những lệnh cần thiết để tạo và xác nhận các bản sao.

-

+ +

+ Một khái niệm quan trọng của Git là 'chỉ mục'. Có thể được coi nó là một + vùng tạm thời trước khi tạo bản sao chính, nhờ nó bạn có thể tạo những bản + sao bao gồm một nhóm các thay đổi được tổ chức tốt, thay vì phải xác nhận + thay đổi của tất cả các tập tin cùng một lúc.

- In a nutshell, you will use git add to start tracking new + + Tóm tắt:, quá trình làm việc cơ bản với Git của bạn sẽ như + sau: sử dụng lệnh git add để bắt đầu theo dõi tập tin mới và + cũng để chỉ mục các tập tin cũ đã thay đổi. Sau đó dùng lệnh git + status và git diff để xem lại các thay đổi đã được chỉ +mục, và cuối cùng dùng lệnh git commit để lưu lại bản sao của dự +án.

@@ -42,24 +59,34 @@

book git add - adds file contents to the staging area + thêm nội dung tập tin vào vùng chỉ mục

-

+ +

+ Với git, bạn phải thêm tập tin vào vùng chỉ mục trước khi bạn có thể xác nhận. + Bạn có thể dùng lệnh git add để thêm cả tập tin mới cũng như + những tập tin đã được theo dõi (ví dụ như tập tin từ những lần xác nhận + trước) vào vùng chỉ mục. Dưới đây là một vài ví dụ.

-

Going back to our Hello World example, once we've initiated the project, - we would now start adding our files to it and we would do that with - git add. We can use git status to see what the - state of our project is. -

+ + +

Ở ví dụ Hello World, sau khi khởi tạo dự án, ta sẽ bắt đầu thêm tập tin + vào bằng cách dùng git add. Chúng ta có thể dùng git + status để xem trạng thái hiện tại của dự án. + 

 $ git status -s
@@ -67,14 +94,18 @@ 

 ?? hello.rb
- So right now we have two untracked files. We can now add them. + + Hiện tại có hai tập tin chưa được theo dõi. Chúng ta có thể thêm chúng vào + dự án. 
 $ git add README hello.rb
- Now if we run git status again, we'll see that they've been - added. + + Bây giờ nếu chạy git status một lần nữa, chúng ta sẽ thấy + chúng đã được thêm. 
 $ git status -s
@@ -82,7 +113,7 @@ 

 A  hello.rb
-

+ +

+ Git có thể thêm một cách đệ qui tất cả các tập tin trong một thư mục, do đó + để thêm tất cả các tập tin trong thư mục dự án, ta cũng thường dùng + git add .. Việc dùng git add . cũng có tác + dụng như khi bạn gõ lệnh git add README hello.rb, và nếu như + trong thư mục hiện tại không có thêm thư mục con nào thì tác dụng của lệnh + git add . và git add * có thể nói là như + nhau.

- + +

Nếu bây giờ chúng ta sửa một tập tin và tiếp tục thực hiện lệnh + git status, kết quả sẽ như thế này.

+ 
 $ vim README
 $ git status -s
@@ -102,26 +145,41 @@ 

 A  hello.rb
-

The 'AM' status means that the file has been modified on disk since we + +

Trạng thái 'AM' có nghĩa là tập tin đã được thay đổi sau khi ta thêm tập + tin đó vào (chữ 'A' chỉ 'Add', hay thêm vào, còn chữ 'M' chỉ 'Modified', + hay thay đổi). Nếu bây giờ ta xác nhận, Git sẽ xác nhận tập tin này vào + thời điểm ta gõ lệnh git add trước, không phải phiên bản ta + vừa lưu sửa đổi trên đĩa. Đó là vì Git không mặc định lưu mọi tập tin có + trong thư mục đang làm việc vào bản sao, mà bạn phải chỉ định cụ thể Git + thêm tập tin nào vào thông qua lệnh git add.

- In a nutshell, - you run git add on a file when you want to - include whatever changes you've made to it in your next commit snapshot. - Anything you've changed that is not added will not be included - this means - you can craft your snapshots with a bit more precision than most other SCM - systems.

- -

For a very interesting example of using this flexibility to stage only + + Tóm tắt:, dùng git add để thêm tập tin đã + thay đổi vào phiên bản trước khi tiến hành xác nhận. Chỉ những thay đổi nào + được thêm vào mới được xác nhận vào kho, nhờ vậy mà các phiên bản có thể + bao gồm chính xác những tập tin bạn muốn.

+ + + +

Có một ví dụ rất thú vị về cách áp dụng tính mềm dẻo này để chỉ mục chỉ + một phần của tập tin đã thay đổi ở phần tùy chọn -p của + git add trong sách Pro Git.

@@ -134,17 +192,27 @@

book git status - view the status of your files in the working directory and staging area + xem trạng thái tập tin trong thư mục làm việc và vùng + tạm

-

As you saw in the git add section, in order to see what the - status of your staging area is compared to the code in your working - directory, you can run the git status command. Using the - -s option will give you short output. - Without that flag, the git status command will give you more - context and hints. Here is the same status output with and without the - -s. The short output looks like this: + +

+ Như đã thấy trong mục git add, để xem trạng thái vùng chỉ mục so + với thư mục đang làm việc, ta dùng lệnh git status. Để xem + kết quả ngắn gọn, ta thêm tùy chọn -s. Nếu không có tùy + chọn nào, lệnh git status sẽ cho thấy nhiều thông tin chi + tiết và gợi ý. Dưới đây là kết quả của cùng một trạng thái khi có và + không có -s. Đầu tiên là kết quả ngắn gọn: 

@@ -153,7 +221,8 @@ 

 A  hello.rb
- Where the same status with the long output looks like this: + + Khi không dùng tham số -s, kết quả xuất ra chi tiết hơn: 
 $ git status
@@ -175,13 +244,18 @@ 

 #
-

You can easily see how much more compact the short output is, but the + +

Rất dễ để nhận ra sự khác biệt giữa hai kết quả trên. Dạng đầy đủ có + chứa gợi ý về lệnh mà ta sẽ dùng tiếp theo.

-

Git will also tell you about files that were deleted since your last - commit or files that were modified or staged since your last commit.

+ +

Git cũng sẽ cho thấy những tập tin đã bị xóa và tập tin bị thay đổi hay + đã được chỉ mục kể từ lần xác nhận trước. 

 $ git status -s
@@ -189,11 +263,18 @@ 

  D hello.rb
- You can see there are two columns in the short status output. The first + +

+Dạng ngắn của trạng thái bao gồm hai cột. Cột đầu tiên dành mô tả trạng thái +các tập tin trong chỉ mục tạm, còn cột thứ hai là dành liệt kê các tập tin ở +thư mục hiện hành. Nếu bạn đã sửa tập tin README sau khi chỉ mục nó vào vùng +tạm mà không thực hiện lệnh git add lần nữa, kết quả sẽ như thế +này: +

 $ git status -s
@@ -202,10 +283,14 @@

- In a nutshell, + + Tóm tắt: dùng lệnh git status khi cần xem + những thay đổi và/hoặc đã đưa vào vùng chỉ mục để quyết định xem có nên xác + nhận lưu lại chúng hay không.

@@ -218,25 +303,38 @@

book git diff - shows diff of what is staged and what is modified but unstaged + + hiển thị những thay đổi của tập tin đã chỉ mục và chưa + đưa vào chỉ mục

-

There are two main uses of the git diff command. One use we - will describe here, the other we will describe later in the - "Inspection and Comparison" - section. The way we're going to use it here is to describe the - changes that are staged or modified on disk but unstaged.

+ +

Lệnh git diff có hai công dụng chính. Chúng ta sẽ nói đến + công dụng thể hiện những thay đổi đã được chỉ mục hoặc chưa được chỉ mục. + Công dụng còn lại sẽ được đề cập đến trong trong phần "Kiểm tra và so sánh".

git diff - show diff of unstaged changes + + chỉ ra những thay đổi chưa được chỉ mục

-

Without any extra arguments, a simple git diff will display + +

Mặc định git diff sẽ hiển thị tổng hợp những sự thay đổi + (một bản vá) mà bạn vừa tạo ra so với lần xác nhận trước mà chưa được ghi + nhận cho lần xác nhận kế tiếp. 

@@ -259,24 +357,35 @@ 

  end
-

So where git status will show you what files have changed + +

Trong khi lệnh git status sẽ cho ta biết tập tin nào đã bị + thay đổi hay đã được chỉ mục kể từ lần xác nhận trước, lệnh git + diff sẽ chỉ ra những thay đổi đó chính xác là như thế nào theo từng +dòng. Lệnh này nên được dùng ngay sau git status

git diff --cached - show diff of staged changes + + hiển thị những thay đổi đã được chỉ mục

-

The git diff --cached command will show you what contents + +

Lệnh git diff --cached sẽ cho ta thấy những thay đổi nào + đã được chỉ mục, có nghĩa là những chỉ mục sẽ được đưa vào bản sao tiếp + theo khi xác nhận. Ở ví dụ trên, nếu bạn đã chỉ mục các thay đổi tập tin + hello.rb, khi dùng lệnh git diff sẽ không xuất + ra thông tin gì cho bạn vì lệnh này chỉ xuất thông tin những gì chưa + được chỉ mục.

 $ git status -s
@@ -288,8 +397,10 @@ 

 $
-

If you want to see the staged changes, you can run - git diff --cached instead.

+ +

Để xem những thay đổi đã được chỉ mục, bạn dùng lệnh + git diff --cached

 $ git status -s
@@ -314,16 +425,23 @@ 

 
     

       git diff HEAD
-      show diff of all staged or unstaged changes
+      
+      xem tất cả các thay đổi đã chỉ mục hoặc chưa chỉ mục
     

 
-    
If you want to see both staged and unstaged changes together, you
+    
+    
Để xem tất cả những thay đổi đã chỉ mục và chưa chỉ mục cùng một lúc,
+    bạn có thể dùng lệnh git diff HEAD. Về cơ bản nghĩa là bạn
+    muốn xem những thay đổi so với lần xác nhận trước. Nếu ta thay đổi tập tin
+    hello.rb, chỉ mục vài thay đổi và không chỉ mục vài thay đổi
+    khác. Chúng ta hãy xem kết quả khi dùng ba lệnh diff này:

+
 
 $ vim hello.rb 
 $ git diff
@@ -373,13 +491,18 @@ 

 
     

       git diff --stat
-      show summary of changes instead of a full diff
+      
+      xem tóm tắt những thay đổi
     

 
-    
If we don't want the full diff output, but we want more than the
+    
+    
Lệnh git diff --stat cho kết quả chi tiết hơn so với lệnh
+    git status, nhưng lại tóm lược hơn so với các lệnh diff trên.
+    Đây là ví dụ với tùy chọn --stat.
     

 
 
@@ -396,17 +519,25 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
 

 
-    

+    
+    

+    Bạn cũng có thể thêm đường dẫn đến tập tin vào sau các tùy chọn này để giới
+    hạn kết quả của lệnh diff cho một tập tin hay trong một thư
+    mục con.
     

 
-
     

-    In a nutshell,
+    
+    Tóm tắt: lệnh git diff dùng để xem chi tiết
+    hơn lệnh git status - xem tập tin đã được thay đổi hoặc ghi
+    nhận như thế nào theo từng dòng.
     

 
 
@@ -420,16 +551,22 @@ 

       book
     
     git commit
-    records a snapshot of the staging area
+    
+    ghi lại một bản sao của vùng chỉ mục
   

 
   

 
-    
Now that you have staged the content you want to snapshot with the
+    
+    
Sau khi những thay đổi đã được chỉ mục bằng lệnh git add,
+    bạn dùng lệnh git commit để thực sự ghi những thay đổi đó
+    thành một bản sao. Git ghi lại tên và email của bạn trong mỗi xác nhận bạn
+    tạo, vì vậy, bạn hãy thông tin về bạn cho Git biết.
     

 
 
@@ -437,9 +574,13 @@ 

 $ git config --global user.email you@somedomain.com
 

 
-    
Let's stage and commit all the changes to our
+    
+    
Bây giờ ta sẽ chỉ mục và xác nhận tất cả những thay đổi của tập tin
+    hello.rb. Trong ví dụ này, chúng ta sẽ dùng tùy chọn
+    -m để nhập thông điệp xác nhận từ dòng lệnh.
     

 
 
@@ -451,10 +592,14 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
 

 
-    
Now we have recorded the snapshot.  If we run git status
+    
+    
Bản sao đã được ghi lại. Nếu bây giờ ta thực hiện lệnh git
+        status, kết quả nhận được sẽ là ta có một "thư mục hiện hành
+    trống", có nghĩa là chúng ta chưa thực hiện thay đổi nào kể từ lần xác nhận
+    gần nhất.

 
 
 $ git status
@@ -462,10 +607,14 @@ 

 nothing to commit (working directory clean)
 

 
-    
If you leave off the -m option, Git will try to open a
+    
+    
Nếu không dùng tùy chọn -m, Git sẽ mở một trình soạn thảo
+    văn bản để bạn viết thông điệp xác nhận. Theo mặc định trình soạn thảo văn
+    bản là vim, và giao diện sẽ tương tự như thế này:
     

 
 
@@ -483,16 +632,23 @@ 

 ".git/COMMIT_EDITMSG" 9L, 257C
 

 
-    
At this point you add your actual commit message at the top of the
+    
+    
Lúc này bạn có thể thêm thông điệp xác nhận vào phần đầu văn bản. Những
+    dòng bắt đầu bằng '#' sẽ bị bỏ qua - Git sẽ hiển thị kết quả của lệnh
+    git status ở đây để bạn nhớ bạn đã sửa và chỉ mục những
+    gì.

 
-    
In general, it's very important to write a good commit message.
+    
+    
Thông thường, việc viết một thông điệp xác nhận tốt là rất quan trọng.
+    Đối với các dự án nguồn mở, có một quy tắc chung về việc viết thông điệp
+    xác nhận:

 
-
+
+
+Tóm lược ngắn (50 ký tự hoặc ít hơn) về những thay đổi
+
+Thông tin chi tiết hơn nếu cần thiết. Giới hạn trong 72 ký tự trên một
+dòng. Trong nhiều hoàn cảnh, dòng đầu tiên được coi như chủ đề và phần
+còn lại là nội dung của một email. Dòng trống phân cách giữa tóm tắt và
+phần thân rất quan trọng (trừ khi bỏ qua hoàn toàn phần thân); Một số
+công cụ git có thể bị nhầm lẫn nếu bạn viết liền hai phần này với nhau.
+
+Các đoạn tiếp theo cũng được phân cách bằng những dòng trống.
+
+ - Được phép sử dụng gạch đầu dòng
+
+ - Dấu gạch ('-' - ND) hay dấu sao ('*' - ND) có thể được dùng như gạch
+   đầu dòng, bắt đầu bằng một khoảng trắng. Các gạch đầu dòng có thể
+   cách nhau bởi một dòng trống hoặc không, tùy theo quy định riêng
+
+# Please enter the commit message for your changes. Lines starting
+# with '#' will be ignored, and an empty message aborts the commit.
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD ..." to unstage)
+#
+# modified:   hello.rb
+#
+~
+~
+~
+".git/COMMIT_EDITMSG" 25L, 884C written
 

 
-    

+    
+    

+    Thông điệp xác nhận rất quan trọng vì sức mạnh của Git phần lớn nằm ở
+    khả năng có thể tạo những xác nhận và sau đó chia sẻ chúng. Ba hay bốn xác
+    nhận được phân chia một cách hợp lý sẽ giúp việc theo dõi và xem lại dễ
+    dàng hơn. Bởi vì có sự phân chia giữa xác nhận và đẩy những thay đổi này,
+    dành thời gian viết những thông điệp xác nhận tốt sẽ giúp đồng nghiệp
+    hiểu được bạn đang làm gì và vì sao dễ dàng hơn.

 
     

       git commit -a
-      automatically stage all tracked, modified files before the commit
+      
+      tự động chỉ mục tất cả các tập tin đã thay đổi, theo dõi trước khi
+          xác nhận
     

 
-    
If you think the git add stage of the workflow is too
+    
+    
Nếu bạn cho rằng giai đoạn git add trong chu trình làm việc
+    là quá rườm rà, Git cho phép bỏ qua nó bằng tùy chọn -a.  Với
+    tùy chọn này, Git sẽ thực hiện git add với tất cả những tập
+    tin đang được "tracked" (theo dõi) - tập tin đã được thay đổi từ lần xác
+    nhận trước. Nhờ vậy bạn có thể thực hiện theo một chu trình làm việc theo
+    kiểu Subversion, chỉnh sửa tập tin và sau đó dùng lệnh git commit
+    -a để ghi lại tất cả những thay đổi. Bạn sẽ vẫn phải dùng lệnh
+git add để bắt đầu theo dõi những tập tin mới, tương tự như với
+Subversion.
     

 
 
@@ -569,25 +775,41 @@ 

  1 files changed, 2 insertions(+), 1 deletions(-)
 

 
-    
Notice how if you don't stage any changes and then run
+    
+    
Chú ý rằng nếu bạn chưa chỉ mục thay đổi nào mà thực hiện ngay lệnh
+    git commit, Git sẽ xuất kết quả lệnh git status,
+    nhắc nhở rằng chưa có thay đổi nào được chỉ mục. Những phần quan trọng của
+    thông điệp này được đánh dấu, nêu rằng không có thay đổi nào đã được thêm
+    vào để xác nhận. Nếu thêm tùy chọn -a, tất cả thay đổi sẽ được
+    chỉ mục và xác nhận đồng thời.
     

 
-    
This now lets you complete the entire snapshotting workflow - you
+    
+    
Đến đây ta đã hoàn thành một chu trình làm việc hoàn chỉnh - bạn thay
+    đổi các tập tin, sau đó dùng lệnh git add để chỉ mục các thay
+    đổi, lệnh git status và git diff để bạn xem lại
+    những thay đổi đó, và cuối cùng lệnh git commit để thực sự ghi
+    lại bản sao.

 
     

-    In a nutshell,
+    
+    Tóm tắt: dùng lệnh git commit để ghi lại bản
+    sao gồm những thay đổi đã được chỉ mục. Bản sao này sau đó có thể được so
+    sánh, chia sẻ hay hoàn lại nếu cần thiết.
     

 
   

@@ -600,22 +822,29 @@ 

       book
     
     git reset
-    undo changes and commits
+    
+    hoàn tác thay đổi và xác nhận
   

 
   

-    
git reset is probably the most confusing command written
+    
+    
Lệnh git reset có lẽ là lệnh khó hiểu nhất được viết ra
+    nhưng nó rất hữu dụng một khi bạn bám vào nó. Có ba trường hợp được đưa ra
+    về lệnh này hoàn toàn hữu ích.
     

 
     

       git reset HEAD
-      unstage files from index and reset pointer to HEAD
+      
+      lấy lại thay đổi từ chỉ mục và trở về HEAD
     

 
-    
First, you can use it to unstage something that has been
+    
+    
Trong trường hợp này, ta sẽ dùng nó để lấy lại những thay đổi đã ghi
+    nhận. Giả sử bạn đã thay đổi hai tập tin và muốn lưu lại trong hai lần xác
+    nhận riêng rẽ. Bạn nên chỉ mục và xác nhận lần lượt từng tập tin một. Nếu
+    chẳng may bạn đã chỉ mục cả hai tập tin này, thực hiện lệnh
+    git reset HEAD -- file. -- dùng để thông báo
+    với Git rằng các tùy chọn đã được liệt kê hết, và sau đây sẽ là danh
+    sách đường dẫn, nhưng phân cách giữa các tùy chọn và đường dẫn là một
+    thói quen tốt.
     

 
-    
Let's see what it looks like to unstage something.  Here we have
-    two files that have been modified since our last commit.  We will stage
-    both, then unstage one of them.

+    
+    
Dưới đây ta sẽ chỉ mục thay đổi ở hai tập tin và sau đó lần lượt lấy
+    lại những thay đổi của từng tập tin.

 
 
 $ git status -s
@@ -647,32 +887,52 @@ 

  M hello.rb
 

 
-    
Now you can run a git commit which will just record
+    
+    
Bây giờ nếu bạn thực hiện lệnh git commit thì sẽ chỉ
+    ghi lại thay đổi ở tập tin README, chứ không bao gồm những
+    thay đổi chưa được chỉ mục trong tập tin hello.rb.
     

 
-    

+    
+    

+    Khi bạn thực hiện lệnh này, thực tế là Git đã ghi đè checksum của một tập tin
+    trong chỉ mục bằng checksum của chính tập tin đó trong lần commit trước. Vì
+    git add tính checksum của một tập tin và ghi nó vào chỉ mục,
+    git reset HEAD ghi lại nó bằng giá trị cũ, từ đó có thể bỏ
+    tập tin khỏi phạm vi chỉ mục.
     

 
-    

+    
+    

+    Bạn có thể tạo một lệnh tắt git unstage  bằng cách chaỵ lệnh
+    git config --global alias.unstage "reset HEAD". Từ giờ bạn có
+    thể sử dụng lệnh git unstage [file] để thực hiện thao tác này.
     

 
-    
If you forget the command to unstage something, Git is helpful in
+    
+    
Nếu bạn không nhớ lệnh nào dùng để hủy chỉ mục thay đổi, Git sẽ nhắc
+       cho bạn trong kết quả của lệnh git status. Ví dụ khi bạn
+       dùng lệnh git status mà không dùng tùy chọn -s
+       sẽ được kết quả như sau:

 
 
 $ git status
@@ -685,9 +945,12 @@ 

 #
 

 
-    
When you run git reset without specifying a flag
+    
+    
Git mặc định dùng tùy chọn --mixed khi bạn không thêm tùy
+    chọn nào vào lệnh git reset. Các tùy chọn khác của lệnh này là
+    --soft và --hard.
 
     

       git reset --soft
@@ -760,10 +1023,14 @@ 

     parent reference to reset to that specific point.

 
     

-    In a nutshell,
+    
+    Tóm tắt:,
+    lệnh git reset HEAD dùng để thôi chỉ mục thay đổi ở những
+    tập tin mà trước đấy đã được git add mà bạn chưa muốn xác nhận
+    ngay.
@@ -775,29 +1042,38 @@

book git rm - remove files from the staging area + + loại bỏ tập tin ra khỏi vùng chỉ mục

-

git rm will remove entries from the staging area. + +

Lệnh git rm sẽ loại bỏ tập tin ra khỏi vùng chỉ mục. Điểm khác + biệt so với lệnh git reset HEAD ở chỗ lệnh lệnh này chỉ hoàn trả + vùng chỉ mục lại trạng thái ban đầu, còn lệnh git rm không chỉ + loại tập tin khỏi vùng chỉ mục mà còn xóa nó.

+ + +

Theo mặc định, lệnh git rm file sẽ loại bỏ hoàn toàn tập tin + đó khỏi vùng chỉ mục và đồng thời cũng xóa luôn tập tin trên đĩa cứng (thư mục + hiện hành). Để giữ tập tin trong thư mục hiện hành, bạn dùng lệnh git rm --cached

git mv git rm --cached orig; mv orig new; git add new

-

+ +

Khác với phần lớn các hệ thống quản lý mã nguồn khác, Git không theo dõi + các tập tin bị đổi tên. Thay vào đó nó chỉ theo dõi các bản sao để phát hiện những + tập tin đã bị xóa và thêm vào với nội dung giống nhau, khi đó Git sẽ hiểu đây là + trường hợp đổi tên. Mặc dù có lệnh git mv, nhưng nó là thừa - + lệnh này chỉ đơn thuần git rm, di chuyển tập tin trên đĩa cứng và + sau đó là git add tập tin mới.

+ + +

+ Tôi ít khi dùng lệnh này để xóa tập tin. Thay vào đó chỉ cần xóa tập tin trên đĩa + cứng và sau đó thực hiện lệnh git commit -a cũng sẽ giúp loại + bỏ tập tin khỏi chỉ mục.

- In a nutshell, + + Tóm tắt:, + lệnh git rm dùng để loại một tập tin nào đó khỏi sự theo dõi của + Git và đồng thời cũng xóa tập tin đó khỏi thư mục hiện hành.

@@ -969,5 +1258,5 @@

-

On to Branching and Merging »

+

Phân Nhánh và Tích Hợp »

diff --git a/vi/branching/index.html b/vi/branching/index.html index 27fd588..13ca777 100644 --- a/vi/branching/index.html +++ b/vi/branching/index.html @@ -1,5 +1,5 @@ --- -layout: reference +layout: vi_reference ---
@@ -7,20 +7,36 @@

book - Branching and Merging + Phân Nhánh và Tích Hợp

-

Branching in Git is one of its many great features. If you have used other + +

Rẽ nhánh là một trong các tính năng tôi thích của Git. + Khi làm việc với Git, bạn nên tạm quên đi khái niệm nhánh + mà bạn từng biết trong các hệ thống quản lý phiên bản khác, + vì thực tế, mỗi nhánh trong Git gần giống như một ngữ cảnh + (điều kiện hay hoàn cảnh làm việc). + Việc rẽ vào một nhánh tương tự việc chuyển qua ngữ cảnh làm việc mới, + và sau đó có thể nhanh chóng quay lại ngữ cảnh cũ.

+

+ ND: Việc rẽ nhánh giống như việc đang đi trên đường thì bạn muốn + rẽ sang ngã khác (ngã ba, ngã tư chẳng hạn), để thực hiện một số + việc như thăm người quen, tránh kẹt xe, rồi quay trở lại đường + chính sau. Một nhánh trong Git gần như một đoạn đường hoặc con đường. + Nếu các con đường ở Sài Gòn đã cố định, thì con đường trong Git + dễ chịu hơn mà bạn có thể tạo ra bất kỳ lúc nào :)

+

- In a nutshell you can create a branch with + + Tóm tắt: bạn tạo ra một nhánh mới bằng + git branch tên_nhánh, sau đó rẽ vào nhánh đó bằng + git checkout tên_nhánh; sau lưu lại các thay đổi trong + ngữ cảnh này, bạn có thể rẽ qua nhánh khác một cách dễ dàng. + + Mỗi khi rẽ vào một nhánh, Git sẽ thay thư mục làm việc cho tương ứng + với nhánh đó; vì vậy, bạn không phải xử lý nhiều thư mục khác nhau + cho nhiều nhánh (có nghĩa là, chỉ dùng một thư mục cho nhiều nhánh. Điều + này rất khác với cách tiếp cận của Subversion -- ND). Cuối cùng, để + trộn hai nhánh với nhau, dùng git merge. Có thể dễ dàng + trộn nhiều lần hai nhánh với nhau, hoặc có thể xóa một nhánh sau khi + nó đã được trộn.

@@ -42,7 +71,9 @@

book git branch - list, create and manage working contexts + + liệt kê, tạo, quản lý các nhánh


@@ -53,27 +84,38 @@

book git checkout - switch to a new branch context + + rẽ vào một nhánh

-

The git branch command is a general branch management tool + +

Lệnh git branch là để quản lý các nhánh; nó có thể + làm nhiều việc khác nhau, nên chúng ta chỉ để cập một số việc cơ bản + của lệnh này: liệt kê, tạo hoặc xóa nhánh. Ta cũng đề cập tới lệnh + git checkout + để rẽ vào một nhánh bất kỳ.

git branch - list your available branches + liệt kê các nhánh

-

Without arguments, git branch will list out the local + +

Khi không có tham số, git branch sẽ liệt kê các nhánh + sẵn có, riêng nhánh bạn đang rẽ vào được đánh dấu sao * hoặc + tô màu xanh lá). 

@@ -81,21 +123,27 @@ 

 * master
-

This means that we have a 'master' branch and we are currently on it. + +

Cho biết bạn đang rẽ vào nhánh 'master'. Đó là nhánh được tạo ra + tự động khi bạn khởi tạo kho bằng lệnh git init. Cái tên + 'master' không phải là bắt buộc, nhưng nó được hầu hết dự án dùng do + sự lựa chọn mặc định của Git.

- git branch (branchname) - create a new branch + git branch (tên_nhánh) + tạo một nhánh mới

-

So let's start by creating a new branch and switching to it. You can do + +

Bây gờ, ta thử tạo một nhánh mới rồi rẽ vào nhánh đó. 

 $ git branch testing
@@ -104,13 +152,23 @@ 

   testing
-

Now we can see that we have a new branch. When you create a branch this + +

Như bạn thấy, sau khi tạo ta sẽ thấy thêm nhánh mới khi liệt kê. + Nhánh mới tạo ra sẽ chứa những thay đổi cuối cùng đã xác nhận. Vì thế, + sau thời điểm nhánh 'testing' được tạo ra, bạn xác nhận các thay đổi + mới (sẽ diễn ra ở nhánh 'master'), rồi lại rẽ vào nhánh 'testing', + thì thư mục làm việc sẽ trở lại trạng thái ngay trước khi nhánh đó + đuợc tạo ra (nghĩa là nó sẽ không chứa các thay đổi bạn vừa xác nhận). + Như vậy, nhánh giống như các đánh dấu trên đường đi cho biết bạn đang + ở đâu. Ta hãy xem việc rẽ nhánh sẽ diễn ra thế nào, với lệnh + git checkout tên nhánh 

@@ -132,9 +190,12 @@ 

 README   hello.rb
-

So now we can see that when we switch to the 'testing' branch, our new + +

Bây giờ, ta rẽ vào nhánh 'testing'. Bạn sẽ thấy các tập tin vừa tạo + ra ở trên sẽ bị xóa đi, nhưng chúng sẽ xuất hiện trở lại khi bạn quay + lại nhánh ban đầu 'master'.

 $ ls
@@ -147,11 +208,13 @@ 

 
     

       git branch -v
-      see the last commit on each branch
+      xem xác nhận cuối của mỗi nhánh
     

 
-    
If we want to see last commits on each branch 
-    we can run git branch -v to see them.

+    
+    
Nếu muốn xem xác nhận cuối của mỗi nhánh, bạn dùng lệnh git branch
+        -v

 
 
 $ git branch -v
@@ -161,17 +224,25 @@ 

 

 
     

-      git checkout -b (branchname)
-      create and immediately switch to a branch
+      git checkout -b (tên_nhánh)
+      
+      tạo một nhánh và rẽ ngay vào nhánh đó
     

 
-    

+    
+    

+    Trong nhiều trường hợp bạn muốn rẽ vào một nhánh ngay sau khi nhánh
+    đó được tạo ra. Thay vì phải dùng cặp lệnh
+      git branch tên_nhán; git checkout tên_nhánh,
+    bạn chỉ gõ tắt
+      git checkout -b tên_nhánh.
     

 
 
@@ -198,27 +269,44 @@ 

 README   hello.rb more.txt test.txt
 

 
-    
You can see there how we created a branch, removed some of our files
+    
+    
Như thấy ở trên, ta rẽ vào nhánh 'removals' ngay sau khi tạo ra nhánh
+    đó; trong nhánh này, ta thực hiện xóa bớt một số tập tin, xác nhận việc
+    xóa và rồi quay lại nhánh chính 'master', ở đó các tập tin vừa xóa sẽ
+    xuất hiện trở lại. Như vậy, việc rẽ nhánh hiểu và phân chia thư mục
+    làm việc theo đúng ngữ cảnh được chỉ định; việc chuyển đổi giữa các
+    nhánh không làm mất đi tập tin hoặc không gây ra nhầm lẫn.

+
+    
+    

+    Khi bắt đầu một dự án, bạn nên rẽ vào một nhánh riêng của dự án đó
+    (việc này cũng nhanh và dễ), và sau đó trộn nhánh của bạn với nhánh
+    chính của dự án; sau khi trộn thì có thể xóa nhánh riêng bạn tạo ra.
+    Bằng cách đó, bạn dễ dàng chuyển qua phiên bản (nhánh) ổn định của dự
+    án khi xảy ra vấn đề trên nhánh bạn phát triển; hơn nữa, bạn cũng có thể
+    dễ dàng tạm gác lại công việc của bạn trên nhánh riêng, để quay trở lại
+    các nhánh cũ do yêu cầu bắt buộc của dự án.

 
     

-      git branch -d (branchname)
-      delete a branch
+      git branch -d (tên_nhánh)
+      xóa một nhánh
     

 
-    
If we want to delete a branch (such as the 'testing' branch in the
+    
+    
Để xóa một nhánh, bạn chỉ việc dùng lệnh
+      git branch -d tên_nhánh. Ví dụ, ta sẽ xóa nhánh
+      'testing' đã tạo ra ở ví dụ ở trên.
 
 
 $ git branch
@@ -231,14 +319,18 @@ 

 

 
     

-      git push (remote-name) :(branchname)
-      delete a remote branch
+      git push (tên-kho-đầu-xa) :(tên-nhánh)
+      xóa một nhánh kho đầu xa
     

 
-    
When you're done with a remote branch, whether it's been merged
+    
+    
Khi nhánh đầu xa bạn làm việc đã được tích hợp vào nhánh chính đầu xa
+    master hoặc bạn muốn xóa bỏ để dọn dẹp, bạn kèm theo vào sau lệnh
+    git push một dấu hai chấm và tên nhánh cần xóa như ví dụ
+    sau:
 
 
 
 $ git push origin :tidy-cutlery
@@ -246,25 +338,40 @@ 

  - [deleted]         tidy-cutlery
 

 
-    
In the above example you've deleted the "tidy-cutlery" branch
+    
+    

+    Ở ví dụ trên, chúng ta đã xóa nhánh "tidy-cutlery" khỏi kho đầu xa
+    "origin". Cách dễ nhớ nhất là bạn hãy nhớ lệnh dài ngoằng sau đây git
+    push remote-name local-branch:remote-branch. Ý nghĩa của câu lệnh
+này là bạn muốn đẩy lên nhánh của kho trên máy tính của bạn trùng với kho đầu
+xa. Khi bạn xóa phần local-branch, thì phần nhánh đầu xa cũng sẽ
+được xóa đi để trùng với nhánh trên máy tính.
     

 
-    
Alternatively, you can run
+    
+    
Một cách khác, lệnh git push remote-name --delete
+        branchname với cặp source:destination cũng được
+    dùng xóa nhánh đầu xa.
     

 
     

-    In a nutshell you use git branch to list your
+    
+    Tóm tắt: bạn dùng git branch để liệt kê các nhánh
+    hiện có, rẽ nhánh mới hoặc xóa đi các nhánh đã trộn hoặc không còn cần thiết.
@@ -277,11 +384,11 @@

book git merge - merge a branch context into your current one + tích hợp một nhánh vào nhánh đang làm việc

-

Once you have work isolated in a branch, you will eventually want to + +

Sau khi chia công việc riêng ra từng nhánh, có lúc bạn sẽ cần trộn + các nhánh với nhau, hoặc với nhánh chính. Để trộn, bạn dùng lệnh + git merge. + Xét ví dụ ở trên với nhánh 'removals'. Ta nhớ lại rằng sau khi rẽ vào + nhánh 'removals', ta xóa đi một vài tập tin và xác nhận sự thay đổi. + Việc xóa tập tin này chỉ diễn ra ở nhánh 'removals', còn ở nhánh chính + 'master' không có tập tin nào được xóa. Bây giờ, để xác nhận rằng cả + các tập tin bị xóa trong 'removals' cũng bị xóa trong 'master', ta chỉ + việc trộn nhánh 'removals' với 'master'. 

@@ -310,14 +427,21 @@

- more complex merges + các phương thức tích hợp phức tạp hơn

-

Of course, this doesn't just work for simple file additions and + +

Tất nhiên, quá trình phát triển của mã nguồn không chỉ đơn giản + là thêm và xóa tập tin :). Git còn hỗ trợ thêm việc trộn các thay đổi + (hoặc sự khác biệt) giữa của tập tin ở hai nhánh khác nhau. + Lấy ví dụ, ta sẽ chỉnh nội dung tập tin ở một nhánh, trong khi ở nhánh + kia ta đổi tên tập tin, rồi rồi trộn hai tập tin đó với nhau. Nghe + có vẻ rối đây! Xem Git giải quyết thế nào nhé! 

@@ -333,9 +457,12 @@ 

 HelloWorld.hello
-

So first we're going to create a new branch named 'change_class' and + +

Bây giờ ta đang ở nhánh 'master'. Ta sẽ tạo nhánh 'change_class' + và rẽ ngay vào nhánh đó: trong nhánh mới ta sẽ thực hiện đổi tên lớp + từ 'HelloWorld' dthành 'HiWorld'.

 $ git checkout -b change_class
@@ -348,11 +475,17 @@ 

  1 files changed, 2 insertions(+), 4 deletions(-)
-

So now we've committed the class renaming changes to the 'change_class' + +

Việc đổi tên lớp được xác nhận sau lệnh git commit. + Ta sẽ trở lại nhánh chính 'master' và sẽ thấy rằng trong tên lớp + vẫn là 'HelloWorld' (như cũ!). Ta sẽ đổi xem có sự khác biệt nào + với thay đổi đã thực hiện ở nhánh 'change_class', đồng thời đổi tên + tập tin từ hello.rb thành ruby.rb. 

@@ -380,11 +513,16 @@ 

  rename hello.rb => ruby.rb (65%)
-

Now those changes are recorded in the 'master' branch. Notice that the + +

Như ban thấy, sự thay đổi tên tập tin và nội dung cũng vừa được + xác nhận trong nhánh 'master'. Để ý rằng, tên lớp vẫn là 'HelloWorld'. + Nếu muốn thay đổi cả tên của lớp thành 'HiWorld', ta chỉ việc trộn + nội dung ở nhánh 'change_class' vào nhánh 'master'. Nhưng liệu Git + có trộn được không, vì tên tập tin đã đổi? Hãy xem:

 $ git branch
@@ -406,20 +544,28 @@ 

 HiWorld.hello
-

Well, it will just figure it out. Notice that there are no merge conflicts + +

Tốt quá, mọi chuyện diễn ra đúng như mong đợi. Như vậy trong quá + trình trộn ta đã không gặp xung đột nào, kể cả việc đổi tên tập tin + hoặc đổi tên lớp diễn ra ở nhánh khác

- merge conflicts + tích hợp các xung đột

-

So, Git merges are magical, we never ever have to deal with merge + +

Như vậy, Git thật là khéo léo, nhưng ta chưa hề đụng tới trường hợp + có xung đột. Không sao, khi xảy ra sự khác biệt về mã giữa hai nhánh + mà Git không thể hình dung được, sẽ tới phiên chúng ta giải quyết. + Trong ví dụ sau, ta sẽ thay đổi cùng một dòng của tập tin ở hai nhánh. + 

 $ git branch
@@ -432,9 +578,12 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
-

Now we have committed a change to one line in our README file in a + +

Sau khi rẽ vào nhánh 'fix_readme', ta thực hiện thay đổi một dòng + trong tập tin 'README'. Tiếp theo ta sẽ thay đổi cùng dòng đó, nhưng + ở tập tin của nhánh 'master'.

 $ git checkout master
@@ -445,8 +594,10 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
-

Now is the fun part - we will merge the first branch into our master - branch, causing a merge conflict.

+ +

Hãy xem có điều thú vị gì xảy ra khi trộn hai tập tin có xung đột + với nhau:

 $ git merge fix_readme
@@ -464,12 +615,19 @@ 

 nearly every programming language.
-

You can see that Git inserts standard merge conflict markers, much like + +

Như bạn thấy, Git chèn vào các ký hiệu đánh dấu sự xung đột xảy + ra khi trộn. Git đã 'bó tay' khi dừng lại ở đó, và tới phiên bạn + quyết định. Để ý là, + một số công cụ đồ họa + như kdiff3, emerge, p4merge, ... sẽ giúp việc giải quyết xung đột + dễ dàng hơn. 

@@ -487,11 +645,18 @@ 

   This project has examples of hello world in
-

A cool tip in doing merge conflict resolution in Git is that if you + +

Một mẹo rất hay khi trộn các xung đột trong Git là nếu khi dùng + git diff, + chương trình sẽ cho bạn thấy cả hai phần (cũ, mới) gây nên xung đột, + và cả cách giải quyết xung đột. Sau đó, bạn cần đánh dấu cho tập tin + rằng xung đột trên nó đã giải quyết xong: bạn sử dụng lệnh + git add + và cả git commit để xác nhận.

 $ git status -s
@@ -503,14 +668,19 @@ 

 [master 8d585ea] Merge branch 'fix_readme'
-

And now we've successfully resolved our merge conflict and committed - the result.

+ +

Bây giờ thì xung đột được giải quyết trọn vẹn.

- In a nutshell you use git merge to combine another + + Tóm tắt: bạn dùng git merge để trộn một nhánh với + nhánh bạn đang rẽ vào. Git sẽ tự động xác định phép trộn tốt nhất để + có được sản phẩm chung lai giữa hai nhánh.

@@ -523,19 +693,26 @@

book git log - show commit history of a branch + + xem ghi chú về các lần xác nhận

-

So far we have been committing snapshots of your project and switching + +

Ta đã biết cách xác nhận các thay đổi, cách chuyển qua lại giữa + các nhánh. Nhưng chuyện gì xảy ra một khi ta quên mất ta đang ở nhánh + nào, ở vị trí nào trong một nhánh, hoặc lý do ta rẽ nhánh? Hoặc ta quên + mất sự khác biệt giữa các nhánh? Lường trước cách trả lời cho câu hỏi này, + Git cung cấp lệnh git log để giúp bạn xem lại mô tả hoặc + lý do của tất cả các lần xác nhận.

+ + +

Truớc khi hiểu về lệnh log, bạn cần biết Git lưu những + gì mỗi khi bạn xác nhận sự thay đổi bằng lệnh git commit. + Bên cạnh thông tin về các tập tin, người thay đổi, thông điệp, Git còn + lưu thông tin về xác nhận có liên quan trực tiếp tới xác nhận đang thực + hiện. Để hình dung, ta lấy ví dụ: khi bạn nhân bản một dự án, bạn cần + biết là thay đổi của bạn cho nhân bản đó dựa trên trạng thái nào của dự + án đã có. Thông tin về trạng thái cũ rất có ích, giúp bạn xác nhận ngữ + cảnh (nhánh) của bạn và giúp hình dung quá trình phát triển của toàn bộ + dự án. Bằng cách đặt tên 'cha' (parent) có ngữ cảnh gốc, Git tự động + biết được bạn làm gì cho ngữ cảnh của bạn (con).

-

To see a chronological list of the parents of any branch, you can run + +

Để xem danh sách các xác nhận 'cha' theo thời gian, bạn dùng lệnh + git log khi đang ở một nhánh bất kỳ. Ví dụ, kết quả của lệnh + git log trong dự án HelloWorld ở trên như sau đây.

 $ git log
@@ -586,8 +777,10 @@ 

 ...
-

To see a more compact version of the same history, we can use the - --oneline option.

+ +

Để xem lược sử ngắn gọn trong một dòng, ta dùng tùy chọn + --oneline.

 $ git log --oneline
@@ -600,14 +793,23 @@ 

 17f4acf first commit
-

What this is telling us is that this is the history of the development + +

Qua thông tin thu được, ta hình dung được toàn bộ quá trình phát triển + của nhánh hiện tại (và của dự án). Nếu trong mỗi lần xác nhận, thông điệp + ta muốn Git lưu lại càng chi tiết thì ta dễ dàng nhớ lại, hình dùng + tốt về các thay đổi đã thực hiện cũng như ảnh hưởng của nó lên nhánh + hiện tại..

+ +

Ngoài ra, tùy chọn --graph rất thú vị, khi nó vẽ ra + một cây phản ánh cấu trúc nhánh của dự án: Kết quả của tùy chọn này + giải thích tại sao ta dùng từ 'nhánh' để mô tả dự án

 $ git log --oneline --graph
@@ -624,7 +826,7 @@ 

 * 17f4acf first commit
-

Now we can more clearly see when effort diverged and then was merged + +

Minh họa có vẻ đơn sơ trên thực tế giúp bạn hình dung rõ hơn về + dự án, lý do tạo nhánh và trộn các nhánh, và cũng giúp ích cho việc + quản lý các nhánh. Sau đây, ta sẽ thử tạo nhánh mới, rẽ vào đó để thực + hiện vài thay đổi rồi qua lại nhánh chính. Ta sẽ dùng lệnh log + để hình dung chung về tất cả các nhánh.

+ +

Trước hết, ta tạo và rẽ vào nhánh 'erlang' để có phiên bản của + chương trình HelloWorld trong ngôn ngữ Erlang. Rõ ràng, ta không nên + tạo ngay một phiên bản Erlang trong nhánh chính, nếu không thì sau một + hồi mọi thứ sẽ trở nên lộn xộn, thậm chí là không làm việc được.

 $ git checkout -b erlang
@@ -648,9 +860,11 @@ 

  create mode 100644 erlang_hw.erl
-

Since we're having fun playing in functional programming languages we + +

Trong nhánh 'erlang', ta cũng sẽ tạo ra một bản HelloWorl cũng bằng + ngôn ngữ hàm Haskell.

 $ vim haskell.hs
@@ -661,10 +875,13 @@ 

  create mode 100644 haskell.hs
-

Finally, we decide that we want to change the class name of our Ruby + +

Các thay đổi được xác nhận. Bây giờ, ta quyết định quay ngược lại + phiên bản Ruby để thay đổi tên lớp. Phiên bản Ruby nằm trong nhánh chính, + vì thế ta cần rẽ vào nhánh đó trước.

 $ git checkout master
@@ -677,13 +894,22 @@ 

  1 files changed, 2 insertions(+), 2 deletions(-)
-

So, now say we don't work on the project for a while, we have other + +

Gỉa sử rằng mọi việc đã xong, bạn quay lại với các công việc khác + hơn là dự án HelloWorld buồn tẻ. Rồi một ngày khác, quay lại dự án này + ở nhánh 'master', bạn muốn biết những gì đã diễn ra trên nhánh 'erlang' + và vị trí trên nhánh chính 'master' mà bạn bắt đầu rẽ vào 'erlang'. + Nếu chỉ rẽ vào nhánh rồi xem nội dung các tập tin trong nhánh + đó, hiển nhiên là bạn sẽ không hình dung tại sao lại có phiên bản Haskell + trong nhánh 'erlang'. Bạn cần phải dùng git log để tìm + hiểu các lý do; ngoài ra, việc chỉ định tên nhánh sẽ cho biết thông tin + về điểm rẽ nhánh.

 $ git log --oneline erlang
@@ -698,7 +924,7 @@ 

 17f4acf first commit
-

This way, it's pretty easy to see that we have Haskell code included in + +

Từ kết quả trên, dễ thấy là phiên bản Haskell chỉ bắt đầu xuất hiện trong nhánh + 'erlang' (được tô màu ở trên). Nhưng git log còn ghi ra + nhiều thông tin ở trước thời điểm nhánh 'erlang' được tạo ra. + Quá nhiều! Điều tuyệt vời là Git đã tính tới phàn nàn này: bạn có thể + chỉ định Git đưa các thông tin chỉ có ở nhánh này mà không xuất hiện + ở nhánh khác. Điều này rất có ích, chẳng hạn khi bạn muốn trộn nhánh + 'erlang' vào nhánh 'master', nhưng trước khi trộn, bạn cần biết + những gì sẽ diễn ra khi trộn. +

+ +

+ Để không liệt kê các thông tin không cần thiết của một nhánh, bạn + dùng dấu mũ ^ trước tên nhánh. Ví dụ, nếu chỉ muốn xem + các thay đổi trong nhánh 'erlang', bỏ đi các thay đổi trong nhánh + 'master', chỉ việc dùng erlang ^master: 

@@ -725,16 +967,26 @@ 

 594f90b reverted to old class name
-

This gives us a nice, simple branch management tool. It allows us to + +

Sử dụng dấu mũ là một cách đơn giản, hiểu quả khi quản lý các nhánh, + cho phép bạn thấy được những cái chỉ có ở nhánh này mà không có ở + nhánh khác. Nhờ đó, bạn kiểm soát các thiếu sót hoặc hình dung + được những thay đổi khi trộn các nhánh.

- In a nutshell you use git log to list out the commit + + Tóm tắt: bạn dùng git log để liệt kê thông tin về + các lần xác nhận sự thay đổi mã nguồn hoặc các lý do của việc rẽ nhánh, + nhờ đó giúp bạn hình dung quá trình phát triển và trạng thái hiện tại + của dự án.

@@ -747,37 +999,57 @@

book git tag - tag a point in history as important + + đánh dấu thời điểm quan trọng trong quá trình phát triển

-

+ +

+ Có một số thời điểm quan trọng trong quá trình phát triển dự án mà + bạn muốn ghi nhớ một cách dễ dàng và dài lâu. Chúng được đánh dấu + bằng lệnh git tag: lệnh này đánh dấu ở một điểm trên nhánh + để bạn có thể dễ dàng so sánh với các xác nhận khác trong tương lai. + Thường thì bạn sẽ dùng 'tag' (thẻ) khi đưa ra một phiên bản của dự án.

-

Let's say we want to release our Hello World project as version "1.0". + +

Ví dụ, ta muốn công bố phiên bản "1.0" của chương trình HelloWorld. + Ta có đánh dấu sự thay đổi cuối cùng (HEAD) là "v1.0" bằng + lệnh git tag -a v1.0. Tùy chọn -a cho phép + bạn thêm chú thích cho thẻ "v1.0". Mặc dù việc không dùng tùy chọn đó + cũng có tác dụng đánh dấu, nhưng kết quả là thông tin về thời điểm đánh + dấu, tác giả, các ghi chú bổ sung sẽ không được lưu lại. Vì vậy, + bạn luôn nên dùng tùy chọn -a.

 $ git tag -a v1.0
-

When you run the git tag -a command, Git will open your editor + +

Sau lệnh git tag -a như trên, Git sẽ mở ra trình sọan thảo + để bạn bắt đầu ghi thông tin chi tiết về thẻ.

+ +

Sau đó, sử dụng lệnh git log --decorate, ngoài các thông + tin về những lần xác nhận, bạn còn thấy thêm thông tin về các thẻ.

 $ git log --oneline --decorate --graph
@@ -795,7 +1067,7 @@ 

 * 17f4acf first commit
-

If we do more commits, the tag will stay right at that commit, so we have + +

Nếu sau khi đánh dấu, bạn xác nhận thêm các thay đổi, thẻ vẫn giữ + nguyên vị trí ở lần nó tạo ra lần đầu tiên. Như vậy, thẻ được đánh dấu + sẽ cố định và có thể dùng để so sánh với các trạng thái mới của dự án + trong tương lai.

+ +

Việc đánh dấu cho các thay đổi hiển nhiên không phải là điều bắt buộc. + Có thể xảy ra việc bạn đã công bố một phiên bản của dự án mà không (quên) + đánh dấu. Khi đó, nếu muốn bổ sung đánh dấu, bạn cũng dùng lệnh git tag, + nhưng đi kèm với chỉ số của xác nhận. Ví dụ, ta sẽ đánh dấu cho xác + nhận mang chỉ số 558151a như sau đây:

 $ git tag -a v0.9 558151a
@@ -822,12 +1104,17 @@ 

 * 17f4acf first commit
-

Tags pointing to objects tracked from branch heads will be + +

Các nhãn trỏ đến các đối tượng đã được theo dõi bởi phân nhánh sẽ được + tự động tải về khi bạn fetch từ kho lưu trữ đàu xa. Tuy nhiên, + các nhãn không truy cập được bởi phân nhánh sẽ được bỏ qua. Bạn dùng tùy + chọn --tags để chắc rằng tất cả các nhãn được kèm + theo khi tải về.

 $ git fetch origin --tags
@@ -841,24 +1128,33 @@ 

  * [new tag]         v1.1       -> v1.1
-

If you just want a single tag, use + +

Nếu bạn muốn dùng một nhãn đơn, dùng lệnh git fetch <remote> + tag <tag-name>.

-

By default, tags are not included when you push to + +

Mặc định, các nhãn không được kèm theo khi push đến kho lưu + trữ đầu xa. Nếu bạn muốn kèm theo, bạn phải thêm vào tùy chọn + --tags vào lệnh git push.

- In a nutshell you use git tag to mark a + + Tóm tắt: bạn dùng lệnh git tag để đánh dấu một xác nhận + hoặc điểm quan trọng trong kho lưu trữ. Việc đánh nhãn giúp bạn dễ nhớ các + xác nhận hơn mã SHA.

-

On to Sharing and Updating Projects »

+

Chia Sẻ và Cập Nhật Dự Án »

diff --git a/vi/creating/index.html b/vi/creating/index.html index 449859a..d22b5ff 100644 --- a/vi/creating/index.html +++ b/vi/creating/index.html @@ -1,21 +1,31 @@ --- -layout: reference +layout: vi_reference ---
-

Getting and Creating Projects

+

Nhận và Tạo Dự Án

-

+ +

Để làm việc với Git, bạn phải có kho lưu trữ để Git cất giữ các bản sao + bạn lưu lại.

-

+ +

+ Có hai cách để có một kho: đơn giản nhất là bắt đầu từ một thư mục trên máy + tính của bạn, khi bạn muốn bắt đầu một dự án mới hoặc đã có với Git. Cách + thư hai là nhân bản từ một kho lưu trữ đã có; cách này + thường áp dụng khi bạn làm việc với một vài người khác trong dự án, và việc + nhân bản kho lưu trữ Git là để bắt đầu phần việc của riêng bạn cho dự án + đó.

@@ -28,14 +38,17 @@

book git init - initializes a directory as a Git repository + tạo kho lưu trữ từ thư mục sẵn có

-

To create a repository from an existing directory of files, you can + +

Bắt đầu từ một thư mục làm việc bất kỳ, bạn dùng lệnh git + init để tạo mới một kho lưu trữ Git cho thư mục đó. Ví dụ, ta có + thư mục 'konichiwa' với vài tập tin trong đó:

 $ cd konnichiwa
@@ -43,35 +56,47 @@ 

 README   hello.rb
-

This is a project where we are writing examples of the "Hello World" + +

Trong dự án này, ta viết chương trình "Hello World" trong các ngôn + ngữ khác nhau, và ta bắt đầu với ngôn ngữ Ruby. Ta sẽ tạo mới một + kho lưu trữ Git cho thư mục 'konichiwa', cũng là cho dự án với lệnh + git init:

 $ git init
 Initialized empty Git repository in /opt/konnichiwa/.git/
-

Now you can see that there is a .git subdirectory in your + +

Bạn sẽ thấy xuất hiện thư mục .git bên trong thư mục + 'konichiwa'. Thư mục này là kho lưu trữ Git, nơi mà Git lưu mọi thông + tin cần thiết để quản lý các phiên bản của dự án.

 $ ls -a
 .        ..       .git     README   hello.rb
-

Congratulations, you now have a skeleton Git repository and can start + +

Bây giờ bạn đã có thể bắt đầu ghi các bản sao dự án với khung kho lưu + trữ Git vừa tạo của bạn.

- In a nutshell, you use git init to make an + + Tóm tắt:, bạn dùng git init để tạo kho + lưu trữ Git cho một thư mục đã có. Việc tạo kho này có thể áp dụng + cho bất kỳ thư mục nào trên máy tính của bạn.

@@ -83,14 +108,19 @@

book git clone - copy a git repository so you can add to it + nhân bản một kho lưu trữ

-

+ +

+ Khi làm việc với người khác, hoặc khi muốn có một bản sao để làm vài việc + riêng, bạn sẽ nhân bản kho Git của dự án. Lệnh sẽ dùng là git clone + [url], trong đó, [url] là địa chỉ của kho. 

@@ -106,12 +136,20 @@ 

 README   Rakefile lib
-

+ +

+ Việc nhân bản một kho sẽ sao chép toàn bộ thông tin lược sử quá trình phát + triển dự án về thư mục (ở trên là 'simplegit') trên máy tính của bạn. + Trạng thái ban đầu của thư mục đó tương ứng với nhánh phát triển chính + (hay nhánh mặc định). Trong thư mục cũng có thư mục con .git + là kho lưu trữ Git địa phương (trong khi kho gốc được chỉ ra ở địa chỉ kho + trong lệnh nhân bản ở trên). 

@@ -124,19 +162,28 @@ 

 config      index       objects
-

+ +

+ Khi nhân bản, Git mặc định tạo một thư mục cùng tên với kho Git trong phần địa + chỉ được cho khi nhân bản (phần tên này nằm sau dấu gạch / cuối cùng). + Tuy nhiên, nếu bạn muốn kết quả nhân bản nằm trong thư mục khác, bạn có thể + chỉ ra ở sau địa chỉ kho (cách với địa chỉ kho ít nhất một khoảng trắng.)

- In a nutshell, you use git clone to get a + + Tóm tắt: bạn dùng git clone để có một + bản sao của kho Git trên máy tính, để bạn có thể thực hiện các đóng + góp riêng cho dự án.

-

On to Basic Snapshotting »

+

Cơ Bản Về Bản Sao »

diff --git a/vi/index.html b/vi/index.html index df003d8..f805f35 100644 --- a/vi/index.html +++ b/vi/index.html @@ -1,8 +1,8 @@ --- -layout: vi-reference +layout: vi_reference ---
-

Giới thiệu về Tham Khảo Git

+

Giới thiệu

- Trang này là tài liệu tham khảo nhanh cho việc học và nhớ những điều quan trọng và những lệnh thường dùng trong Git. các lệnh được tổ chức theo từng phần loại tác vụ, và sẽ trình bày các tùy chọn và các lệnh thông thường cần thiết để hoàn thành tác vụ đó. + Trang web này để tham khảo về Git: một trang để tham khảo nhanh khi bạn học + hoặc sử dụng Git, chỉ chứa những lệnh quan trọng và hay dùng nhất của Git. + Các lệnh được nhóm lại thành từng mục theo tác vụ, và sẽ được trình bày với + những tùy chọn phổ biến nhất để hoàn thành tác vụ đó.

+

- Mỗi phần sẽ liên kết đến phần kế tiếp vì thế có thể được dùng như một hướng dẫn. Mỗi trang cũng sẽ liên kết đến các tài liệu Git sâu hơn như các trang hướng dẫn chính thức của Git và các phần liên quan trong Sách Pro Git để bạn có thể học sâu hơn về bất kỳ lệnh nào. Đầu tiên, chúng ta sẽ bắt đầu suy nghĩ về quản lý mã nguồn như Git. + Mỗi mục liên kết tới mục khác; mỗi trang cũng có tham khảo tới tài liệu + chuyên sâu hơn (ví dụ liên kết tới trang tài liệu chính thức hoặc các phần + trong tài liệu Sách Pro Git), để giúp các + bạn muốn nắm chắc hơn về Git. +

+

Trước tiên ta sẽ tìm hiểu về nguyên lý cơ bản của Git.

+
-

Làm Thế Nào Suy Nghĩ Như Git

+

Ý tưởng của Git

- Điều quan trong đầu tiên để hiểu Git là suy nghĩ về điều khiển phiên bản - rất khó khăn hơn Subversion hay Perforce hoặc bất kỳ SCM nào bạn đã dùng. -

+ Điều đầu tiên hết sức quan trọng mà bạn phải biết, là Git rất khác + biệt so với Subversion, Perforce hoặc bất kỳ cách quản lý mã nguồn + nào bạn từng biết. Vì thế, để học Git được mau chóng, tốt nhất là + bạn hãy quên mọi thứ bạn biết về Subversion, CVS, ... để bắt đầu + suy nghĩ theo cách hoàn toàn khác với Git. +

+ + +

+ Hãy bắt dầu từ số không. Giả sử bạn đang thiết kế một hệ thống để + quản lý mã nguồn mới. Câu hỏi đặt ra là: phương án đơn giản nhất trước + khi phải cần các công cụ mạnh như Subversion, Perforce,.. là gì? + Câu trả lời có thể là bạn chỉ việc chép thư mục qua một nơi mới, + nhưng cách hay làm để sao lưu dữ liệu. 

 $ cp -R project project.bak
-

+ +

+ Theo cách này, bạn dễ dàng phục hồi lại các tập tin bị thay đổi không + như ý, hoặc bạn có thể so sánh hai thư mục để có được tìm xem có + có sự thay đổi nào đã thực hiện.

-

+ +

+ Nếu việc sao chép như trên diễn ra thường xuyên hơn, bạn có thể dùng + thêm các tên thư mục chứa thông tin về ngày tháng: 

 $ cp -R project project.2010-06-01.bak
-

+ +

+ Điều này dẫn tới kết quả là bạn sẽ có rất nhiều bản sao khác nhau của + dự án. Những bản sao này có thể dùng để chia sẻ với người khác, bằng + cách nén một trong các bản sao và đặt chúng lên một máy phục vụ web: + các lập trình viên khác có thể tải về bản sao, xem xét và thực hiện + các miếng vá thích hợp: 

@@ -82,38 +120,66 @@ 
Làm Thế Nào Suy Nghĩ Như Git

  $ diff project-my-copy project.2010-06-01 > change.patch
  $ (email change.patch)
-

+ +

+ Khi nhận được miếng vá, lập trình viên chính của dự án sẽ xem xét và thực + hiện vá vào một bản sao nào đó của dự án. Thực tế, quá trình tạo bản sao, + chia sẻ và vá như trên là nguyên lý làm việc của nhiều hệ thống quản lý mã + nguồn, đặc biệt là của những dự án mã nguồn mở.

-

+ +

+ Bây giờ, cũng theo nguyên lý khá hiệu quả đó, ta sẽ xây dựng một + công cụ nhanh hơn và đơn giản hơn: thay vì quản lý phiên bản của từng + tập tin trong dự án (như cách làm của Subversion), ta xây dựng công + cụ để tạo và quản lý các bản sao của toàn bộ dự án, mà ta không phải + tạo ra các bản sao mới của toàn bộ các tập tin (như cách sao chép + đã mô tả ở trên.)

-

+ +

+ Ý tưởng vừa nói mô tả bản chất hoạt động của Git. Bạn sẽ nhờ Git + để tạo bản sao của toàn bộ dự án, bằng lệnh git commit + (xác nhận), nhưng Git đủ thông minh để tạo ra một danh sách chỉ gồm + các tập tin có thay đổi vào lúc xác nhận và thực hiện tạo bản sao + chỉ với danh sách đó. Hầu hết các lệnh còn lại của Git sẽ làm việc + với các danh sách mà lệnh git commit tạo ra (so sánh, + liệt kê), thay vì với toàn bộ các tập tin có trong thư mục.

-

+ +

+ Đơn giản hơn, bạn có thể nghĩ Git như một công cụ để so sánh và + trộn các bản sao của một dự án. Đừng nghĩ Git như công cụ để quản + lý phiên bản của từng tập tin như Subversion.

-

On to Getting and Creating Projects »

+

Nhận và Tạo Dự Án »

diff --git a/vi/inspect/index.html b/vi/inspect/index.html index cbf46f4..4414d19 100644 --- a/vi/inspect/index.html +++ b/vi/inspect/index.html @@ -1,5 +1,5 @@ --- -layout: reference +layout: vi_reference ---
@@ -7,22 +7,31 @@

book - Inspection and Comparison + Kiểm Tra và So Sánh

-

+ +

+ Bạn đã có vài nhánh tách theo từng chủ đề, chức năng riêng biệt trong toàn + dự án. Vậy làm sao bạn theo dõi chúng? Git có nhiều công cụ giúp bạn kiểm + tra phần nào được chỉnh sửa, sự khác biệt giữa các nhánh,...

- In a nutshell you can use git log to find specific + + Tóm tắt: bạn dùng lệnh git log để xác định các xác nhận + trong lược sử dự án theo tác giả, ngày tháng, nội dung hoặc lược sử. Và lệnh + git diff để so sánh các điểm khác nhau như là xem sự khác biệt + giữa hai nhánh hoặc một phiên bản nào đó khác phiên bản khác thế nào.

@@ -34,25 +43,33 @@

book git log - filter your commit history + lọc lược sử các xác nhận

-

We've already seen how to use git log to compare branches, + +

+ Chúng ta đã dùng lệnh git log để so sánh các nhánh theo cách + xem các xác nhận của một nhánh với một nhánh khác. (Gợi ý nếu bạn quên, đó + là lệnh: git log branchA ^branchB). Tuy nhiên, lệnh git + log có rất nhiều tùy chọn để chúng ta tìm kiếm các xác nhận. Bạn có + thể xem toàn bộ các tùy chọn này trong tài liệu chính thức vì ở đây, chúng + ta chỉ khám phá các tùy chọn thường dùng nhất trong quá trình quản lý kho + lưu trữ Git của bạn.

git log --author - look for only commits from a specific author + xem các xác nhận theo tác giả

-

+ +

+ Tùy chọn --author sẽ lọc lược sử xác nhận theo tác giả cho bạn. + Để tìm các xác nhận được viết bởi Linus trong bộ mã nguồn Git, chúng ta dùng + git log --author=Linus. Git phân biệt chữ hoa thường và cũng sẽ + tìm trong địa chỉ email. Chúng ta dùng -[số] để giới hạn kết + quả theo [số] xác nhận cuối trong ví dụ sau: 

 $ git log --author=Linus --oneline -5
@@ -73,17 +96,24 @@ 

 
     

       git log --since --before
-      filter commits by date committed
+      xem xác nhận theo ngày tháng
     

 
-    

+    
+    

+    Các tùy chọn --since và --before hoặc
+    --until và --after sẽ lọc lược sử xác nhận theo
+    ngày tháng. Trong mã nguồn Git, chúng ta sẽ xem được các xác nhận cách đây
+    ba tuần nhưng chỉ sau ngày 18 tháng Tư với ví dụ sau (dùng tùy chọn
+    --no-merges để loại bỏ các xác nhận được tích hợp trong quá
+    trình tìm kiếm):
 
 
 $ git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges
@@ -100,15 +130,21 @@ 

 
     

       git log --grep
-      filter commits by commit message
+      lọc xác nhận theo thông điệp
     

 
-    

+    
+    

+    Bạn có thể tìm một cụm từ nhất định trong thông điệp xác nhận với tùy chọn
+    --grep. Chúng ta sẽ tìm trong mã nguồn Git một xác nhận có
+    chứa biến môi trường P4EDITOR để xem đã thay đổi những gì với tùy chọn
+    --grep.
     

 
 
@@ -127,18 +163,27 @@ 

     Signed-off-by: Simon Hausmann <simon@lst.de>
 

 
-    

+    
+    

+    Git sẽ tìm kiếm theo dạng OR (hay/hoặc) các đối số --grep và
+    --author. Nếu bạn muốn dùng dạng thức AND (và) giữa
+    --grep và --author để xem các xác nhận của tác
+    giả nào đó AND (và) có nội dung thông điệp cụ thể, bạn phải thêm tùy chọn
+    --all-match. Trong các ví dụ sau, chúng ta sẽ dùng tùy chọn
+    --format để xem tác giả của mỗi xác nhận.
     

-
-    
If we look for the commit messages with 'p4 depo' in them, we get these
-    three commits:

-
+    
+    
+    
Chúng ta có ba xác nhận với thông điệp có chứa cụm từ 'p4 depo':

+    
 
 $ git log --grep="p4 depo" --format="%h %an %s"
 ee4fd1a Junio C Hamano Merge branch 'master' of git://repo.or.cz/git/fastimport
@@ -146,9 +191,13 @@ 

 1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d
 

 
-    
If we add a --author=Hausmann argument, instead of further
+    
+    
Nếu theo ví dụ trên, chúng ta thêm vào đối số
+    --author=Hausmann để lọc ra một xác nhận của Simon, nhưng lúc
+    này, Git sẽ hiểu rằng chúng ta đang tìm các xác nhận của Simon OR
+    (hay/hoặc) các xác nhận có thông điệp "p4 depo":

 
 
 $ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
@@ -167,8 +216,11 @@ 

 ...
 

 
-    
However, adding --all-match will get the results you're
-    looking for:

+    
+    

+    Bạn muốn tìm một thông điệp xác nhận thực sự khó hiểu, hoặc bạn muốn tìm
+    một chức năng được giới thiệu khi nào hay các biến này được đưa vào từ đoạn
+    mã nào? Git sẽ giúp bạn tìm chuỗi kí tự bạn cần thông qua các thay đổi của
+    mỗi xác nhận. Ví dụ, chúng ta cần tìm các xác nhận có tên chức năng
+    'userformat_find_requirements' trong các thay đổi: (chú ý là không có '='
+    giữa '-S' và chuỗi cần tìm)
     

 
 
@@ -212,7 +272,7 @@ 

 
     

       git log -p
-      show patch introduced at each commit
+      xem bản vá của mỗi xác nhận
     

 
     

diff --git a/vi/remotes/index.html b/vi/remotes/index.html
index 7815353..1ddb1c8 100644
--- a/vi/remotes/index.html
+++ b/vi/remotes/index.html
@@ -1,5 +1,5 @@
 ---
-layout: reference
+layout: vi_reference
 ---
 
 

@@ -7,10 +7,10 @@ 

     
       book
     
-    Sharing and Updating Projects
+    Chia Sẻ và Cập Nhật Dự Án
   

   

-    

+    
+    

+    Git không tập trung dữ liệu mở một máy phục vụ như Subversion. Mà tất
+    cả thao tác sẽ cập nhật dữ liệu ngay trên máy tính của bạn. Để cộng tác
+    với người khác, bạn phải đẩy dữ liệu lên một máy phục vụ chung mà họ
+    có quyền truy cập, và nhờ đó đồng bộ kho lưu trên máy bạn với kho lưu
+    trên máy phục vụ. Không có sự khác biệt giữa máy khách và máy phục vụ
+    dành cho Git, bởi vì kho lưu trữ ở máy khách đã đồng bộ với kho lưu trữ
+    trên máy phục vụ.
+    

+
+    

+    Môt khi đã có kho lưu trữ Git, hoặc là bạn sẽ thiết lập máy của bạn thành
+    một máy phục vụ sử dụng kho đó để chia sẻ, hoặc bạn sẽ tiến hành đồng
+    bộ hoặc khảo sát sự khác biệt giữa kho của bạn với kho Git khác bằng
+    hai thao tác đẩy và kéo.
+    

+
+    

+    Thao tác đẩy và kéo được tiến hành bất kỳ khi nào bạn có kết nối mạng
+    với kho Git khác, trong khi đó thao tác xác nhận (commit)
+    được tiến hành hoàn tòan ở địa phương.

 
     

-    In a nutshell you can update your project with git fetch
+    
+    Tóm tắt: bạn lấy các thông tin mới từ kho Git khác về máy của
+    bạn bằng lệnh git fetch (thao tác kéo), và chia sẻ những thay đổi do
+    bạn thực hiện bằng lệnh git push (thao tác đẩy)).
+    Địa chỉ các kho Git của dự án được quản lý nhờ git remote.
     

   

 

@@ -47,12 +72,12 @@ 

       book
     
     git remote
-    list, add and delete remote repository aliases
+    quản lý địa chỉ các kho git
   

 
   

 
-    
Unlike centralized version control systems that have a client that is
+    
+    
Vì Git không dùng một máy phục vụ chung để lưu dữ liệu như Subversion,
+    các kho lưu trữ Git bình đẳng nhau, nằm trên các máy khác nhau và nhiệm
+    vụ của bạn là đồng bộ những kho này với nhau. Từ đó, nảy sinh ra ý phải
+    quản lý các kho cùng với kết nối tới chúng, kể cả phân quyền (đọc với
+    kho này, được ghi vào kho kia,...). 

+
+    
Các kho ở máy phục vụ khác nhau không chỉ được phân biệt bằng địa chỉ URL đầy đủ, mà còn có thể bằng một tên ngắn gọn mà bạn gán cho địa chỉ đó. Như vậy,
+    việc sử dụng các kho sẽ dễ nhớ, đơn giản hơn rất nhiều. Bạn sử dụng lệnh
+    git remote để quản lý danh sách các kho.

 
     

       git remote
-      list your remote aliases
+      liệt kê tên các kho đầu xa
     

 
-    
Without any arguments, Git will simply show you the remote repository
+    
+    
Khi dùng không có tham số, lệnh git remote liệt kê
+    các tên của các địa chỉ kho xa đã biết. Mặc định, địa chỉ kho đầu tiên
+    khi bạn vừa thực hiện lệnh nhân bản một kho sẽ có tên 'origin' (gốc).
+    Khi có thêm tham số -v, ngoài tên của kho thì địa chỉ
+    của kho cũng được in ra.

 
 
 $ git remote
@@ -84,16 +123,18 @@ 

 origin	git@github.com:github/git-reference.git (push)
 

 
-    
You see the URL there twice because Git allows you to have different
+    
+    
Ở ví dụ trên, địa chỉ kho được liệt kê hai lần, bởi vì Git phân biệt
+    địa chỉ kho để kéo và đẩy.

 
     

       git remote add
-      add a new remote repository of your project
+      thêm một kho đầu xa vào dự án
     

 
-    
If you want to share a locally created repository, or you want to take
+    
+    
Ta có thể thêm nhiều địa chỉ kho khác nhau cho dự án, bằng lệnh
+    git remote add [tên] [địa chỉ]. Ở đây, '[tên]' là do bạn
+    chọn để gợi nhớ, đại diện cho địa chỉ của kho (thường dài dòng khó nhớ).

+
+    
Lấy ví dụ, bạn muốn chia sẻ chương trình Hello World với mọi người
+    bằng cách đẩy nó lên GitHub (dịch vụ khác cũng tương tự), trước hết
+    bạn tạo dự án ở GitHub, có tên là hw. Địa chỉ kho mà dịch vụ
+    GitHub cung cấp cho dự án là "git@github.com:schacon/hw.git" (trong đó,
+    @schacon@ được thay bởi tên của bạn ở GitHub). Ta sẽ thêm địa chỉ kho
+    này cho dự án, với tên kho là 'github':

 
 
 $ git remote
@@ -113,22 +164,29 @@ 

 github	git@github.com:schacon/hw.git (push)
 

 
-    
Like the branch naming, remote alias names are arbitrary - just as 'master'
+    
+    
Ở tên tên của kho được chọn là 'github', có lẽ là một tên gợi nhớ;
+    thực tế thì cũng như các nhánh, bạn có thể chọn tên bất kỳ nào cho
+    địa chỉ của kho.
     

 
     

       git remote rm
-      removing an existing remote alias
+      xóa một địa chỉ kho đầu xa
     

 
-    
Git addeth and Git taketh away.  If you need to remove a remote - you are
+    
+    
Lệnh git remote rm [tên kho] sẽ bỏ đi một kho không
+    còn phù hợp với dự án (nếu bạn muốn giữ nguyên địa chỉ kho và đổi tên
+    kho thì hãy dùng git remote rename

 
 
 $ git remote -v
@@ -147,13 +205,15 @@ 

 

 
 	

-      git remote rename [old-alias] [new-alias]
-      rename remote aliases
+      git remote rename [tên-cũ] [tên-mới]
+      đổi tên kho đầu xa
     

 
-    
If you want to rename remote aliases without having to delete them and add them again 
+    
+    
Nếu bạn muốn đổi tên hiện tại của một kho đầu xa mà không phải xóa và thêm vào lần
+    nữa, bạn dùng lệnh  git remote rename [old-alias] [new-alias]

 
 
 $ git remote add github git@github.com:schacon/hw.git
@@ -167,15 +227,20 @@ 

 

 
     

-    In a nutshell with git remote you can list our
+    
+    Tóm tắt: với git remote bạn xem được danh sách
+    tên các kho xa cùng địa của kho. Lệnh git remote add
+    dùng để thêm kho mới, còn git remote rm dùng để xóa đi.
     

 
     

       git remote set-url
-      update an existing remote URL
+      cập nhật địa chỉ URL kho đầu xa
     

 
     
Should you ever need to update a remote's URL, you can do so with
@@ -258,7 +323,7 @@ 

       book
     
     git fetch
-    download new branches and data from a remote repository
+    tải về nhánh và dữ liệu mới từ kho đầu xa
   

 
   

@@ -269,21 +334,33 @@ 

       book
     
     git pull
-    fetch from a remote repo and try to merge into the current branch
+    kéo về dữ liệu từ kho đầu xa và tích hợp vào nhánh hiện
+    tại
   

 
   

 
-    
Git has two commands to update itself from a remote repository.
+    
+    
Sau khi thêm kho xa, thì tự nhiên dẫn tới nhu cầu cập nhật dữ
+    liệu ở nhánh xa về máy tính của bạn. Git có hai lệnh cho nhu cầu này:
+    Lệnh git fetch sẽ giúp thông tin trên máy của bạn cập nhật
+    so với nhánh xa, bằng cách tải thông tin từ kho xa về (chỉ tải những
+    thông tin chưa có trên máy bạn) và đánh dấu để bạn biết bạn đã đồng
+    bộ dữ liệu với nhánh nào trên kho xa. Cách này còn gọi là "nhánh xa",
+    bởi vì sau khi cập nhật về, Git để nguyên đó mà không lấy ra và thay thế
+    các nội dung đang có trong thư mục làm việc. Việc dùng git fetch
+    giúp bạn kiểm tra các thay đổi, so sánh và thậm chí trộn các thay đổi
+    xa với thư mục làm việc của bạn.
     

 
-    
The second command that will fetch down new data from a remote server is
+    
+    
Lệnh thứ hai để đồng bộ là git pull. Thực ra, lệnh này
+    là một cách gộp: đầu tiên, Git thi hành git fetch để
+    cập nhật thông tin từ xa xuống máy, rồi ngay sau đó tiến hành trộn
+    nhờ lệnh git merge (việc trộn này chỉ diễn ra với nhánh
+    mà bạn đang làm việc). Một cách cá nhân, tác giả không thích lệnh này,
+    bởi nó không thật sự an toàn, bởi tốt nhất là chỉ nên trộn sau khi đã
+    kiểm tra, so sánh kỹ. Tuy nhiên, việc dùng git pull
+    cũng có cái hay mà bạn có thể tìm hiểu thêm ở
+    tài liệu chính thức.
     

 
-    
Assuming you have a remote all set up and you want to pull in updates, you
+    
+    
Bây giờ, đi vào chi tiết. Giả sử các kho xa đã được thiết lập và
+    bạn muốn kéo thông tin từ xa về máy: bạn sẽ dùng lệnh git fetch [tên kho].
+    Sau đó, bạn có thể trộn bằng git merge [tên kho]/[tên nhánh].
+    Chẳng hạn, khi đang thực hiện dự án Hello World, thấy có ai đó đã sửa
+    đổi cho dự án này, và bạn muốn kéo các thay đổi của họ về máy, thì
+    các lệnh sẽ dùng như sau:

 
 
 $ git fetch github
@@ -316,31 +410,55 @@ 

  * [new branch]      lisp       -> github/lisp
 

 
-    
Here we can see that since we last synchronized with this remote, five branches
+    
+    
Thông tin ở trên cho biết, kể từ lần đồng bộ cuối cùng, đã có
+    5 nhánh được thêm hoặc cập nhật vào kho xa: hai nhánh 'ada' v 'lisp'
+    là hoàn tòan mới, các nhánh còn lại 'master', 'c-langs' và 'java' được cập nhật.
     

 
-    
You can see the mapping that Git makes.  The 'master' branch on the remote
+    
+    
Trong kết quả ở trên bạn thấy cách Git ánh xạ các nhánh với nhau.
+    Ví dụ, nhánh xa 'remote' tương ứng với nhánh 'github/master' trên máy
+    của bạn. Nhờ thế, để trộn nhánh xa 'master' với thư mục hiện tại,
+    bạn chỉ việc dùng lệnh git merge github/master.
+    Bạn cũng có thể xem những thay đổi diễn ra ở nhánh xa nhưng chưa
+    được trộn vào nhánh 'master' của bạn bằng lệnh
+      git log github/master ^master.
+    Để ý là, nếu bạn dùng tên 'origin' cho nhánh xa thì thay vì 'github/master'
+    như trong các ví dụ vừa rồi, bạn phải dùng origin/master instead.
+    Ngoài ra, hầu hết các lệnh các tác dụng với nhánh địa phương cũng
+    có thể dùng với nhánh xa.
     

 
-    
If you have more than one remote repository, you can either fetch from specific
+    
+    
Trường hợp có nhiều nhánh xa, ngoài việc chỉ định lấy thông tin
+    từ một nhánh cụ thể bằng lệnh git fetch [tên kho]
+    bạn có thể chỉ định Git cập nhật từ tất cả các nhánh bằng lệnh
+        git fetch --all.
 
     

-    In a nutshell you run git fetch [alias] to synchronize your
+    
+    Tóm tắt: Dùng git fetch [tên kho] để đồng bộ
+    dữ liệu từ kho ở xa đến kho của bạn, để lấy về những dữ liệu có ở xa
+    mà chưa có trong thư mục làm việc, và sau đó bạn có thể so sánh,
+    khảo sát và trộn các kết quả khi cần thiết.
     

 
   

@@ -354,15 +472,21 @@ 

       book
     
     git push
-    push your new branches and data to a remote repository
+    đẩy dữ liệu mới lên kho đầu xa
   

 
   

-    
To share the cool commits you've done with others, you need to push your
+    
+    
Sau khi thực hiện một số thay đổi cho dự án, xác nhận thay đổi
+    bằng lệnh git commit, bạn có thể chia sẻ thay đổi này
+    với mọi người bằng cách đẩy cách kết quả lênh nhánh ở xa. Thao tác này
+    ngược với việc kéo đã mô tả ở trên. Lệnh để thực hiện đẩy là
+    git push [tên kho] [tên nhánh], sẽ chép nội dung nhánh
+    hiện tại thành nhánh ở kho xa. Ví dụ, ta sẽ đẩy nhánh 'master' lên kho xa:

 
 
 $ git push github master
@@ -375,11 +499,16 @@ 

  * [new branch]      master -> master
 

 
-    
Pretty easy. Now if someone clones that repository they will get exactly
+    
+    
Thật dễ dàng :) Sau khi đẩy như trên, một lập trình viên khác dễ
+    dàng kéo mọi thay đổi mà bạn thực hiện về máy tính của họ.

+
+    
Trong ví dụ tiếp sau, ta tiếp tục đẩy nhánh 'erlang', thay vì
+    'master' như trên.
 
 
 $ git push github erlang
@@ -392,13 +521,18 @@ 

  * [new branch]      erlang -> erlang
 

 
-    
Now when people clone or fetch from that repository, they'll get an 'erlang'
+    
+    
Sau lệnh trên, khi người khác nhân bản kho ở Github, hoặc kéo
+    thông tin từ kho đó, họ sẽ thấy nhánh 'erlang' để khảo sát hoặc trộn.
+    Ví dụ cho thấy, bạn có thể tạo ra nhánh bất kỳ và đẩy lên kho xa
+    mà bạn có quyền ghi. Nếu  nhánh chưa có trên kho, nhánh mới sẽ được
+    tạo ra, còn không thì nhánh cũ sẽ được cập nhật.

+
+    
+    
Vấn đề lớn nhất mà bạn có thể gặp khi đẩy dữ liệu lên kho xa,
+    là việc bạn và một người khác 'đồng thời' đẩy lên một nhánh của cùng một kho.
+    Nếu bạn là người thực hiện sau một chút, thì Git không cho phép bạn ghi
+    đè lên kết quả của người kia. Git sẽ dùng lệnh git log
+    ở phía máy phục vụ để kiểm tra xem kho địa phương của bạn có quá hạn
+    chưa; nếu đúng là quá hạn, Git từ chối và bạn phải kéo cập nhật từ
+    kho xa về, trộn trước khi đẩy lên kho.
+    Dưới đây là minh họa cho ý này:

+
+    
 
 
 $ git push github master
@@ -422,19 +564,28 @@ 

 fast-forwards' section of 'git push --help' for details.
 

 
-    
You can fix this by running git fetch github; git merge github/master
+    
+    
Vì Git từ chối thay đổi mà bạn đẩy lên, bạn phải dùng
+      git fetch github; git merge github/master
+    rồi mới đẩy lên lần nữa.
 
     

-    In a nutshell you run git push [alias] [branch] to update a
+    
+    Tóm tắt: Dùng git push [tên kho] [tên nhánh] để
+    đẩy các thay đổi mà bạn thực hiện ở máy lên kho xa. Git sẽ xem xét trạng
+    thái của nhánh ở kho xa và thực hiện chuyển dữ liệu nếu có thể.
+    Trường hợp nhánh của bạn đã quá hạn (hay quá cũ) so với thông tin
+    được xác nhận trên kho xa, Git từ chối và bạn phải thực hiện kéo
+    các thông tin từ trên kho về máy để tiếp tục.
     

 
   

 

 
-
On to Inspection and Comparison »

+
Kiểm Tra và So Sánh »


From 1bc1b6ecad213eb87d164f98b416df6bc9e13fef Mon Sep 17 00:00:00 2001
From: Tran Dinh Anh Tuan 
Date: Wed, 5 Feb 2014 20:49:59 +0700
Subject: [PATCH 3/4] =?UTF-8?q?D=E1=BB=8Bch=20v=C3=A0i=20th=E1=BB=A9:=20-?=
 =?UTF-8?q?=20Th=C3=AAm=20README=20b=E1=BB=95=20sung=20t=E1=BB=AB=20=C4=91?=
 =?UTF-8?q?i=E1=BB=83n=20c=C3=A1c=20thu=E1=BA=ADt=20ng=E1=BB=AF=20Git=20-?=
 =?UTF-8?q?=20Ki=E1=BB=83m=20tra=20b=E1=BA=A3n=20d=E1=BB=8Bch?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 vi/README.md            |  52 +++++++++---
 vi/basic/index.html     | 182 ++++++++++++++++++++++++----------------
 vi/branching/index.html |  91 ++++++++++----------
 vi/creating/index.html  |  14 ++--
 vi/remotes/index.html   |  84 +++++++++++--------
 5 files changed, 247 insertions(+), 176 deletions(-)

diff --git a/vi/README.md b/vi/README.md
index 75b6a22..32588ab 100644
--- a/vi/README.md
+++ b/vi/README.md
@@ -1,19 +1,45 @@
-Đây là [bản dịch tiếng Việt][vi] của trang [Git Reference][en]
----
-layout: vi_reference
----
+Đây là [bản dịch tiếng Việt][vi] của trang [Git Reference][en], một bản
+hướng dẫn tham khảo nhanh các lệnh cơ bản của Git kèm theo ví dụ
+về các trường hợp hay sử dụng.
 
 [vi]: http://gitref.org/vi "Tham khảo Git"
 [en]: http://gitref.org/ "Git Reference"
 
-## Dictionary
+## Từ Điển Thuật Ngữ (Dictionary)
 
-Một số từ, thuật ngữ trong Git sẽ được __"hiểu"__ trong bản dịch này:
+Một số từ, thuật ngữ của Git sẽ được __"hiểu"__ trong bản dịch này:
 
-| English    | Tiếng Việt | Ghi chú |
-|:-----------|:----------:|--------:|
-|reposity    |kho lưu trữ |         |
-|snapshot    |bản sao     |         |
-|commit      |xác nhận    |         |
-|stage       |chỉ mục     |ghi nhận |
-|staging area|vùng chỉ mục|vùng tạm |
+1. Khái niệm và Định nghĩa:
+
+| English         | Tiếng Việt     |Ghi chú |
+|:----------------|:--------------:|-------:|
+|local            |trên máy tính   |        |
+|remote           |đầu xa          |        |
+|reposity         |kho lưu trữ     |        |
+|working directory|thư mục làm việc|        |
+|stage            |chỉ mục         |ghi nhận|
+|staging area     |vùng chỉ mục    |vùng tạm|
+|snapshot         |bản sao         |        |
+|:=========================================:|
+| Khái niệm và định nghĩa                   |
+
+2. Git commands:
+
+| English         | Tiếng Việt     |Ghi chú |
+|:----------------|:--------------:|-------:|
+|init             |khởi tạo        |        |
+|clone            |nhân bản        |        |
+|add              |thêm vào        |        |
+|status           |trạng thái      |        |
+|diff             |                |        |
+|commit           |xác nhận        |        |
+|reset            |đặt lại         |        |
+|stash            |cất giấu        |        |
+|branch           |phân nhánh      |        |
+|checkout         |                |        |
+|merge            |tích hợp        |        |
+|log              |bản ghi         |        |
+|tag              |nhãn, đánh nhãn |        |
+|fetch            |tải về          |        |
+|pull             |kéo             |        |
+|push             |đẩy             |        |
diff --git a/vi/basic/index.html b/vi/basic/index.html
index ecfe124..605fd5d 100644
--- a/vi/basic/index.html
+++ b/vi/basic/index.html
@@ -29,8 +29,8 @@ 

     

     Một khái niệm quan trọng của Git là 'chỉ mục'. Có thể được coi nó là một
     vùng tạm thời trước khi tạo bản sao chính, nhờ nó bạn có thể tạo những bản
-    sao bao gồm một nhóm các thay đổi được tổ chức tốt, thay vì phải xác nhận
-    thay đổi của tất cả các tập tin cùng một lúc.
+    sao bao gồm một nhóm các chỉnh sửa được tổ chức tốt, thay vì phải xác nhận
+    chỉnh sửa của tất cả các tập tin cùng một lúc.
     

 
     

@@ -43,8 +43,8 @@ 

     
-->
     Tóm tắt:, quá trình làm việc cơ bản với Git của bạn sẽ như
     sau: sử dụng lệnh git add để bắt đầu theo dõi tập tin mới và
-    cũng để chỉ mục các tập tin cũ đã thay đổi. Sau đó dùng lệnh git
-    status và git diff để xem lại các thay đổi đã được chỉ
+    cũng để chỉ mục các tập tin cũ đã chỉnh sửa. Sau đó dùng lệnh git
+    status và git diff để xem lại các chỉnh sửa đã được chỉ
 mục, và cuối cùng dùng lệnh git commit để lưu lại bản sao của dự
 án.
     

@@ -152,9 +152,9 @@ 

     looks like on disk is necessarily what you want to snapshot - you have to
     tell Git with the git add command.
     
-->
-    
Trạng thái 'AM' có nghĩa là tập tin đã được thay đổi sau khi ta thêm tập
+    
Trạng thái 'AM' có nghĩa là tập tin đã được chỉnh sửa sau khi ta thêm tập
     tin đó vào (chữ 'A' chỉ 'Add', hay thêm vào, còn chữ 'M' chỉ 'Modified',
-    hay thay đổi).  Nếu bây giờ ta xác nhận, Git sẽ xác nhận tập tin này vào
+    hay chỉnh sửa).  Nếu bây giờ ta xác nhận, Git sẽ xác nhận tập tin này vào
     thời điểm ta gõ lệnh git add trước, không phải phiên bản ta
     vừa lưu sửa đổi trên đĩa. Đó là vì Git không mặc định lưu mọi tập tin có
     trong thư mục đang làm việc vào bản sao, mà bạn phải chỉ định cụ thể Git
@@ -169,7 +169,7 @@ 

     your snapshots with a bit more precision than most other SCM
     systems.
-->
     Tóm tắt:, dùng git add để thêm tập tin đã
-    thay đổi vào phiên bản trước khi tiến hành xác nhận. Chỉ những thay đổi nào
+    chỉnh sửa vào phiên bản trước khi tiến hành xác nhận. Chỉ những chỉnh sửa nào
     được thêm vào mới được xác nhận vào kho, nhờ vậy mà các phiên bản có thể
     bao gồm chính xác những tập tin bạn muốn.

 
@@ -178,7 +178,7 @@ 

     git add in the Pro Git book.
-->
     
     
Có một ví dụ rất thú vị về cách áp dụng tính mềm dẻo này để chỉ mục chỉ
-    một phần của tập tin đã thay đổi ở phần tùy chọn -p của
+    một phần của tập tin đã chỉnh sửa ở phần tùy chọn -p của
     git add trong sách Pro Git.
@@ -254,7 +254,7 @@

-

Git cũng sẽ cho thấy những tập tin đã bị xóa và tập tin bị thay đổi hay +

Git cũng sẽ cho thấy những tập tin đã bị xóa và tập tin bị chỉnh sửa hay đã được chỉ mục kể từ lần xác nhận trước. 

@@ -289,7 +289,7 @@ 

     commit a new snapshot and what will be recorded in it.
     
-->
     Tóm tắt: dùng lệnh git status khi cần xem
-    những thay đổi và/hoặc đã đưa vào vùng chỉ mục để quyết định xem có nên xác
+    những chỉnh sửa và/hoặc đã đưa vào vùng chỉ mục để quyết định xem có nên xác
     nhận lưu lại chúng hay không.
     

 
@@ -305,7 +305,7 @@ 

     git diff
     
-    hiển thị những thay đổi của tập tin đã chỉ mục và chưa
+    hiển thị những chỉnh sửa của tập tin đã chỉ mục và chưa
         đưa vào chỉ mục
   

 
@@ -317,14 +317,14 @@ 

     going to use it here is to describe the changes that are staged or modified
     on disk but unstaged.
-->
     
Lệnh git diff có hai công dụng chính. Chúng ta sẽ nói đến
-    công dụng thể hiện những thay đổi đã được chỉ mục hoặc chưa được chỉ mục.
+    công dụng thể hiện những chỉnh sửa đã được chỉ mục hoặc chưa được chỉ mục.
     Công dụng còn lại sẽ được đề cập đến trong trong phần "Kiểm tra và so sánh".

 
     

       git diff
       
-      chỉ ra những thay đổi chưa được chỉ mục
+      chỉ ra những chỉnh sửa chưa được chỉ mục
     

 
     
-    
Mặc định git diff sẽ hiển thị tổng hợp những sự thay đổi
+    
Mặc định git diff sẽ hiển thị tổng hợp những sự chỉnh sửa
     (một bản vá) mà bạn vừa tạo ra so với lần xác nhận trước mà chưa được ghi
     nhận cho lần xác nhận kế tiếp.
     

@@ -363,14 +363,14 @@ 

     a good follow-up command to git status
     
-->
     
Trong khi lệnh git status sẽ cho ta biết tập tin nào đã bị
-    thay đổi hay đã được chỉ mục kể từ lần xác nhận trước, lệnh git
-    diff sẽ chỉ ra những thay đổi đó chính xác là như thế nào theo từng
+    chỉnh sửa hay đã được chỉ mục kể từ lần xác nhận trước, lệnh git
+    diff sẽ chỉ ra những chỉnh sửa đó chính xác là như thế nào theo từng
 dòng. Lệnh này nên được dùng ngay sau git status 

 
     

       git diff --cached
       
-      hiển thị những thay đổi đã được chỉ mục
+      hiển thị những chỉnh sửa đã được chỉ mục
     

 
     
-    
Lệnh git diff --cached sẽ cho ta thấy những thay đổi nào
+    
Lệnh git diff --cached sẽ cho ta thấy những chỉnh sửa nào
     đã được chỉ mục, có nghĩa là những chỉ mục sẽ được đưa vào bản sao tiếp
-    theo khi xác nhận. Ở ví dụ trên, nếu bạn đã chỉ mục các thay đổi tập tin
+    theo khi xác nhận. Ở ví dụ trên, nếu bạn đã chỉ mục các chỉnh sửa tập tin
     hello.rb, khi dùng lệnh git diff sẽ không xuất
     ra thông tin gì cho bạn vì lệnh này chỉ xuất thông tin những gì chưa
     được chỉ mục.

@@ -399,7 +399,7 @@ 

 
     
-    
Để xem những thay đổi đã được chỉ mục, bạn dùng lệnh
+    
Để xem những chỉnh sửa đã được chỉ mục, bạn dùng lệnh
     git diff --cached

 
 
@@ -426,7 +426,7 @@ 

     

       git diff HEAD
       
-      xem tất cả các thay đổi đã chỉ mục hoặc chưa chỉ mục
+      xem tất cả các chỉnh sửa đã chỉ mục hoặc chưa chỉ mục
     

 
     
-    
Để xem tất cả những thay đổi đã chỉ mục và chưa chỉ mục cùng một lúc,
+    
Để xem tất cả những chỉnh sửa đã chỉ mục và chưa chỉ mục cùng một lúc,
     bạn có thể dùng lệnh git diff HEAD. Về cơ bản nghĩa là bạn
-    muốn xem những thay đổi so với lần xác nhận trước. Nếu ta thay đổi tập tin
-    hello.rb, chỉ mục vài thay đổi và không chỉ mục vài thay đổi
+    muốn xem những chỉnh sửa so với lần xác nhận trước. Nếu ta chỉnh sửa tập tin
+    hello.rb, chỉ mục vài chỉnh sửa và không chỉ mục vài chỉnh sửa
     khác. Chúng ta hãy xem kết quả khi dùng ba lệnh diff này:

 
 
@@ -492,7 +492,7 @@ 

     

       git diff --stat
       
-      xem tóm tắt những thay đổi
+      xem tóm tắt những chỉnh sửa
     

 
     
     Tóm tắt: lệnh git diff dùng để xem chi tiết
-    hơn lệnh git status - xem tập tin đã được thay đổi hoặc ghi
+    hơn lệnh git status - xem tập tin đã được chỉnh sửa hoặc ghi
     nhận như thế nào theo từng dòng.
     

 
@@ -563,8 +563,8 @@ 

     Git records your name and email address with every commit you make,
     so the first step is to tell Git what these are.
     
-->
-    
Sau khi những thay đổi đã được chỉ mục bằng lệnh git add,
-    bạn dùng lệnh git commit để thực sự ghi những thay đổi đó
+    
Sau khi những chỉnh sửa đã được chỉ mục bằng lệnh git add,
+    bạn dùng lệnh git commit để thực sự ghi những chỉnh sửa đó
     thành một bản sao. Git ghi lại tên và email của bạn trong mỗi xác nhận bạn
     tạo, vì vậy, bạn hãy thông tin về bạn cho Git biết.
     

@@ -578,7 +578,7 @@ 

     hello.rb file.  In this first example, we'll use the
     -m option to provide the commit message on the command line.
     
-->
-    
Bây giờ ta sẽ chỉ mục và xác nhận tất cả những thay đổi của tập tin
+    
Bây giờ ta sẽ chỉ mục và xác nhận tất cả những chỉnh sửa của tập tin
     hello.rb. Trong ví dụ này, chúng ta sẽ dùng tùy chọn
     -m để nhập thông điệp xác nhận từ dòng lệnh.
     

@@ -598,7 +598,7 @@ 

     un-snapshotted work in our checkout.
-->
     
Bản sao đã được ghi lại. Nếu bây giờ ta thực hiện lệnh git
         status, kết quả nhận được sẽ là ta có một "thư mục hiện hành
-    trống", có nghĩa là chúng ta chưa thực hiện thay đổi nào kể từ lần xác nhận
+    trống", có nghĩa là chúng ta chưa thực hiện chỉnh sửa nào kể từ lần xác nhận
     gần nhất.

 
 
@@ -680,7 +680,7 @@ 

 ".git/COMMIT_EDITMSG" 25L, 884C written
 
-->
 
-Tóm lược ngắn (50 ký tự hoặc ít hơn) về những thay đổi
+Tóm lược ngắn (50 ký tự hoặc ít hơn) về những chỉnh sửa
 
 Thông tin chi tiết hơn nếu cần thiết. Giới hạn trong 72 ký tự trên một
 dòng. Trong nhiều hoàn cảnh, dòng đầu tiên được coi như chủ đề và phần
@@ -724,7 +724,7 @@ 

     Thông điệp xác nhận rất quan trọng vì sức mạnh của Git phần lớn nằm ở
     khả năng có thể tạo những xác nhận và sau đó chia sẻ chúng. Ba hay bốn xác
     nhận được phân chia một cách hợp lý sẽ giúp việc theo dõi và xem lại dễ
-    dàng hơn. Bởi vì có sự phân chia giữa xác nhận và đẩy những thay đổi này,
+    dàng hơn. Bởi vì có sự phân chia giữa xác nhận và đẩy những chỉnh sửa này,
     dành thời gian viết những thông điệp xác nhận tốt sẽ giúp đồng nghiệp
     hiểu được bạn đang làm gì và vì sao dễ dàng hơn.

 
@@ -732,7 +732,7 @@ 

       git commit -a
       
-      tự động chỉ mục tất cả các tập tin đã thay đổi, theo dõi trước khi
+      tự động chỉ mục tất cả các tập tin đã chỉnh sửa, theo dõi trước khi
           xác nhận
     

 
@@ -749,10 +749,10 @@ 

     
Nếu bạn cho rằng giai đoạn git add trong chu trình làm việc
     là quá rườm rà, Git cho phép bỏ qua nó bằng tùy chọn -a.  Với
     tùy chọn này, Git sẽ thực hiện git add với tất cả những tập
-    tin đang được "tracked" (theo dõi) - tập tin đã được thay đổi từ lần xác
+    tin đang được "tracked" (theo dõi) - tập tin đã được chỉnh sửa từ lần xác
     nhận trước. Nhờ vậy bạn có thể thực hiện theo một chu trình làm việc theo
     kiểu Subversion, chỉnh sửa tập tin và sau đó dùng lệnh git commit
-    -a để ghi lại tất cả những thay đổi. Bạn sẽ vẫn phải dùng lệnh
+    -a để ghi lại tất cả những chỉnh sửa. Bạn sẽ vẫn phải dùng lệnh
 git add để bắt đầu theo dõi những tập tin mới, tương tự như với
 Subversion.
     

@@ -782,11 +782,11 @@ 

     is added to be committed.   If you use -a, it will add and
     commit everything at once.
     
-->
-    
Chú ý rằng nếu bạn chưa chỉ mục thay đổi nào mà thực hiện ngay lệnh
+    
Chú ý rằng nếu bạn chưa chỉ mục chỉnh sửa nào mà thực hiện ngay lệnh
     git commit, Git sẽ xuất kết quả lệnh git status,
-    nhắc nhở rằng chưa có thay đổi nào được chỉ mục. Những phần quan trọng của
-    thông điệp này được đánh dấu, nêu rằng không có thay đổi nào đã được thêm
-    vào để xác nhận. Nếu thêm tùy chọn -a, tất cả thay đổi sẽ được
+    nhắc nhở rằng chưa có chỉnh sửa nào được chỉ mục. Những phần quan trọng của
+    thông điệp này được đánh dấu, nêu rằng không có chỉnh sửa nào đã được thêm
+    vào để xác nhận. Nếu thêm tùy chọn -a, tất cả chỉnh sửa sẽ được
     chỉ mục và xác nhận đồng thời.
     

 
@@ -798,7 +798,7 @@ 

     
Đến đây ta đã hoàn thành một chu trình làm việc hoàn chỉnh - bạn thay
     đổi các tập tin, sau đó dùng lệnh git add để chỉ mục các thay
     đổi, lệnh git status và git diff để bạn xem lại
-    những thay đổi đó, và cuối cùng lệnh git commit để thực sự ghi
+    những chỉnh sửa đó, và cuối cùng lệnh git commit để thực sự ghi
     lại bản sao.

 
     

@@ -808,7 +808,7 @@ 

     if you need to.
     
-->
     Tóm tắt: dùng lệnh git commit để ghi lại bản
-    sao gồm những thay đổi đã được chỉ mục. Bản sao này sau đó có thể được so
+    sao gồm những chỉnh sửa đã được chỉ mục. Bản sao này sau đó có thể được so
     sánh, chia sẻ hay hoàn lại nếu cần thiết.
     

 
@@ -823,7 +823,7 @@ 

     
     git reset
     
-    hoàn tác thay đổi và xác nhận
+    hoàn tác chỉnh sửa và xác nhận
   

 
   

@@ -839,9 +839,8 @@ 

 
     

       git reset HEAD
-      
-      lấy lại thay đổi từ chỉ mục và trở về HEAD
+      
+      huỷ chỉ mục tập tin và đặt lại về HEAD
     

 
     
-    
Trong trường hợp này, ta sẽ dùng nó để lấy lại những thay đổi đã ghi
-    nhận. Giả sử bạn đã thay đổi hai tập tin và muốn lưu lại trong hai lần xác
+    
Trong trường hợp này, ta sẽ dùng nó để lấy lại những chỉnh sửa đã ghi
+    nhận. Giả sử bạn đã chỉnh sửa hai tập tin và muốn lưu lại trong hai lần xác
     nhận riêng rẽ. Bạn nên chỉ mục và xác nhận lần lượt từng tập tin một. Nếu
     chẳng may bạn đã chỉ mục cả hai tập tin này, thực hiện lệnh
     git reset HEAD -- file. -- dùng để thông báo
@@ -868,8 +867,8 @@ 

     
-    
Dưới đây ta sẽ chỉ mục thay đổi ở hai tập tin và sau đó lần lượt lấy
-    lại những thay đổi của từng tập tin.

+    
Dưới đây ta sẽ chỉ mục chỉnh sửa ở hai tập tin và sau đó lần lượt lấy
+    lại những chỉnh sửa của từng tập tin.

 
 
 $ git status -s
@@ -892,8 +891,8 @@ 

     hello.rb.
     
-->
     
Bây giờ nếu bạn thực hiện lệnh git commit thì sẽ chỉ
-    ghi lại thay đổi ở tập tin README, chứ không bao gồm những
-    thay đổi chưa được chỉ mục trong tập tin hello.rb.
+    ghi lại chỉnh sửa ở tập tin README, chứ không bao gồm những
+    chỉnh sửa chưa được chỉ mục trong tập tin hello.rb.
     

 
     
     

     Khi bạn thực hiện lệnh này, thực tế là Git đã ghi đè checksum của một tập tin
-    trong chỉ mục bằng checksum của chính tập tin đó trong lần commit trước. Vì
+    trong chỉ mục bằng checksum của chính tập tin đó trong lần xác nhận trước. Vì
     git add tính checksum của một tập tin và ghi nó vào chỉ mục,
     git reset HEAD ghi lại nó bằng giá trị cũ, từ đó có thể bỏ
     tập tin khỏi phạm vi chỉ mục.
@@ -929,7 +928,7 @@ 

        command.  For example, if you run git status without
        the -s when you have staged files, it will tell you
        how to unstage them:
-->
-    
Nếu bạn không nhớ lệnh nào dùng để hủy chỉ mục thay đổi, Git sẽ nhắc
+    
Nếu bạn không nhớ lệnh nào dùng để hủy chỉ mục chỉnh sửa, Git sẽ nhắc
        cho bạn trong kết quả của lệnh git status. Ví dụ khi bạn
        dùng lệnh git status mà không dùng tùy chọn -s
        sẽ được kết quả như sau:

@@ -957,12 +956,19 @@ 

       moves HEAD to specified commit reference, index and staging are untouched
     

 
-    
The first thing git reset does is undo the last
+    
+    

+    Việc đầu tiên git reset làm là hoàn tác xác nhận cuối
+    và đưa các tập tin trở về vùng chỉ mục. Nếu bạn thêm tuỳ chọn
+    --soft. Ví dụ, nếu bạn chạy lệnh git reset --soft
+        HEAD~ (cha của HEAD), xác nhận cuối sẽ được hoàn tác và
+    các tập tin sẽ được đưa trở lại vùng chỉ mục.
+    

 
 
 $ git status -s
@@ -978,20 +984,27 @@ 

 M  hello.rb
 

 
-    
This is basically doing the same thing as
+
+
Lệnh này về cơ bản giống lệnh git commit --amend, cho
+phép bạn thêm các chỉnh sửa vào xác nhận trước đó.

 
     

       git reset --hard
       unstage files AND undo any changes in the working directory since last commit
     

 
-    
The third option is to go --hard and make your working
+
+
Tuỳ chọn thứ ba là dùng --hard để huỷ chỉ mục, hoàn tác
+mọi chỉnh sửa bạn thêm vào từ lần xác nhận cuối. Đây là tuỳ chọn nguy
+hiểm nhất không an toàn cho thư mục làm việc của bạn. Bất kỳ chỉnh sửa
+chưa xác nhận sẽ mất.

 
 
 $ git status
@@ -1014,13 +1027,18 @@ 

 nothing to commit (working directory clean)
 

 
-    
In the above example, while we had both changes ready to commit and
+
+
Ở ví dụ trên, ta có chỉnh sửa dự kiến xác nhận và chỉnh sửa chưa chỉ
+mục của tập tin README. Lệnh git reset --hard đã xoá bỏ
+chúng và đặt lại toàn bộ về trạng thái giống lần xác nhận cuối.

 
-    
You can replace HEAD with a commit SHA-1 or another
-    parent reference to reset to that specific point.

+    
+    
Bạn có thể thay HEAD với mã SHA-1 của lần xác nhận
+    bất ký để đặt lại về lần xác nhận đó.

 
     

     
     Tóm tắt:,
-    lệnh git reset HEAD dùng để thôi chỉ mục thay đổi ở những
-    tập tin mà trước đấy đã được git add mà bạn chưa muốn xác nhận
-    ngay.  

+    lệnh git reset HEAD dùng để hoàn tác lần xác nhận cuối,
+    huỷ chỉ mục các tập tin bạn không muốn đưa vào lần xác nhận bản sao
+    kế sau khi bạn đã dùng lệnh git add thêm vào. (ND: bạn
+    có thể xem bài viết Reset
+        Demystified để hiểu rõ hơn về lệnh reset của
+    Git)

 
   

 
@@ -1125,26 +1147,39 @@ 

 
   

 
-    
You're in the middle of some changes but something comes up that you
+
+
Bạn đang chỉnh sửa dang dở thì một vấn đề phát sinh cần được thêm vào
+ngay, chẳng hạn một bản vá khẩn cấp, nhưng bạn lại không muốn xác nhận
+hoặc mất các chỉnh sửa hiện tại của bạn. Lệnh git stash sẽ
+giải quyết vấn đề đó giúp bạn.

 
     

       git stash
       add current changes to the stack
     

 
-    
Stashing takes the current state of the working directory and index,
+    
+    
Cất giấu (stash) là đưa thư mục làm việc và vùng chỉ mục hiện tại
+    vào một ngăn xếp và đưa bạn trở về trạng thái của lần xác nhận
+    cuối.

 
-    
If you have untracked files, git stash will not include
+    
+    
Lệnh git stash sẽ không kèm theo các tập tin chưa
+    theo dõi. Cũng như các bạn tạo xác nhận, bạn phải dùng lệnh
+    git add để chỉ mục tập tin trước khi cất giấu hoặc với
+    các các phiên bản Git từ 1.7.7 về sau, bạn có thể dùng lệnh
+    git stash -u để cất giấu các tập tin chưa đánh phiên
+    bản.

 
 
 $ git status -s
@@ -1159,7 +1194,8 @@ 

 
     

       git stash list
-      view stashes currently on the stack
+      
+    liệt kê ngăn xếp
     

 
     
It's helpful to know what you've got stowed on the stash and this is where
diff --git a/vi/branching/index.html b/vi/branching/index.html
index 13ca777..5d303d5 100644
--- a/vi/branching/index.html
+++ b/vi/branching/index.html
@@ -56,9 +56,9 @@ 

     với nhánh đó; vì vậy, bạn không phải xử lý nhiều thư mục khác nhau
     cho nhiều nhánh (có nghĩa là, chỉ dùng một thư mục cho nhiều nhánh. Điều
     này rất khác với cách tiếp cận của Subversion -- ND). Cuối cùng, để
-    trộn hai nhánh với nhau, dùng git merge. Có thể dễ dàng
-    trộn nhiều lần hai nhánh với nhau, hoặc có thể xóa một nhánh sau khi
-    nó đã được trộn.
+    tích hợp hai nhánh với nhau, dùng git merge. Có thể dễ dàng
+    tích hợp nhiều lần hai nhánh với nhau, hoặc có thể xóa một nhánh sau khi
+    nó đã được tích hợp.
     

 
   

@@ -129,9 +129,9 @@ 

     you don't actually have to have a 'master' branch but since it's the default
     that is created, most projects do.
     
-->
-    
Cho biết bạn đang rẽ vào nhánh 'master'. Đó là nhánh được tạo ra
+    
Cho biết bạn đang rẽ vào nhánh 'master'. Đó là nhánh được tạo ra
     tự động khi bạn khởi tạo kho bằng lệnh git init. Cái tên
-    'master' không phải là bắt buộc, nhưng nó được hầu hết dự án dùng do
+    'master' không phải là bắt buộc, nhưng nó được hầu hết dự án dùng do
     sự lựa chọn mặc định của Git.
     

 
@@ -163,12 +163,12 @@ 

     
Như bạn thấy, sau khi tạo ta sẽ thấy thêm nhánh mới khi liệt kê.
     Nhánh mới tạo ra sẽ chứa những thay đổi cuối cùng đã xác nhận. Vì thế,
     sau thời điểm nhánh 'testing' được tạo ra, bạn xác nhận các thay đổi
-    mới (sẽ diễn ra ở nhánh 'master'), rồi lại rẽ vào nhánh 'testing',
+    mới (sẽ diễn ra ở nhánh 'master'), rồi lại rẽ vào nhánh 'testing',
     thì thư mục làm việc sẽ trở lại trạng thái ngay trước khi nhánh đó
     đuợc tạo ra (nghĩa là nó sẽ không chứa các thay đổi bạn vừa xác nhận).
     Như vậy, nhánh giống như các đánh dấu trên đường đi cho biết bạn đang
     ở đâu. Ta hãy xem việc rẽ nhánh sẽ diễn ra thế nào, với lệnh
-        git checkout tên nhánh
+        git checkout tên_nhánh
     

 
 
@@ -195,7 +195,7 @@ 

     them re-appear.
-->
     
Bây giờ, ta rẽ vào nhánh 'testing'. Bạn sẽ thấy các tập tin vừa tạo
     ra ở trên sẽ bị xóa đi, nhưng chúng sẽ xuất hiện trở lại khi bạn quay
-    lại nhánh ban đầu 'master'.

+    lại nhánh ban đầu 'master'.

 
 
 $ ls
@@ -275,7 +275,7 @@ 

     contexts we can switch between.
-->
     
Như thấy ở trên, ta rẽ vào nhánh 'removals' ngay sau khi tạo ra nhánh
     đó; trong nhánh này, ta thực hiện xóa bớt một số tập tin, xác nhận việc
-    xóa và rồi quay lại nhánh chính 'master', ở đó các tập tin vừa xóa sẽ
+    xóa và rồi quay lại nhánh chính 'master', ở đó các tập tin vừa xóa sẽ
     xuất hiện trở lại. Như vậy, việc rẽ nhánh hiểu và phân chia thư mục
     làm việc theo đúng ngữ cảnh được chỉ định; việc chuyển đổi giữa các
     nhánh không làm mất đi tập tin hoặc không gây ra nhầm lẫn.

@@ -289,8 +289,8 @@ 

     aside and then come back to.
-->
     

     Khi bắt đầu một dự án, bạn nên rẽ vào một nhánh riêng của dự án đó
-    (việc này cũng nhanh và dễ), và sau đó trộn nhánh của bạn với nhánh
-    chính của dự án; sau khi trộn thì có thể xóa nhánh riêng bạn tạo ra.
+    (việc này cũng nhanh và dễ), và sau đó tích hợp nhánh của bạn với nhánh
+    chính của dự án; sau khi tích hợp thì có thể xóa nhánh riêng bạn tạo ra.
     Bằng cách đó, bạn dễ dàng chuyển qua phiên bản (nhánh) ổn định của dự
     án khi xảy ra vấn đề trên nhánh bạn phát triển; hơn nữa, bạn cũng có thể
     dễ dàng tạm gác lại công việc của bạn trên nhánh riêng, để quay trở lại
@@ -371,7 +371,7 @@ 

     already merged branches.
     
-->
     Tóm tắt: bạn dùng git branch để liệt kê các nhánh
-    hiện có, rẽ nhánh mới hoặc xóa đi các nhánh đã trộn hoặc không còn cần thiết.
+    hiện có, rẽ nhánh mới hoặc xóa đi các nhánh đã tích hợp hoặc không còn cần thiết.
     

 
   
@@ -397,15 +397,15 @@ 

     deletions in your 'master' branch, you can just merge in the 'removals'
     branch.
     
-->
-    
Sau khi chia công việc riêng ra từng nhánh, có lúc bạn sẽ cần trộn
-    các nhánh với nhau, hoặc với nhánh chính. Để trộn, bạn dùng lệnh
+    
Sau khi chia công việc riêng ra từng nhánh, có lúc bạn sẽ cần tích hợp
+    các nhánh với nhau, hoặc với nhánh chính. Để tích hợp, bạn dùng lệnh
       git merge.
     Xét ví dụ ở trên với nhánh 'removals'. Ta nhớ lại rằng sau khi rẽ vào
     nhánh 'removals', ta xóa đi một vài tập tin và xác nhận sự thay đổi.
     Việc xóa tập tin này chỉ diễn ra ở nhánh 'removals', còn ở nhánh chính
-    'master' không có tập tin nào được xóa. Bây giờ, để xác nhận rằng cả
-    các tập tin bị xóa trong 'removals' cũng bị xóa trong 'master', ta chỉ
-    việc trộn nhánh 'removals' với 'master'.
+    'master' không có tập tin nào được xóa. Bây giờ, để xác nhận rằng cả
+    các tập tin bị xóa trong 'removals' cũng bị xóa trong 'master', ta chỉ
+    việc tích hợp nhánh 'removals' với 'master'.
     

 
 
@@ -437,10 +437,10 @@ 

     merge these branches together.  Chaos, you say?  Let's see.
     
-->
     
Tất nhiên, quá trình phát triển của mã nguồn không chỉ đơn giản
-    là thêm và xóa tập tin :). Git còn hỗ trợ thêm việc trộn các thay đổi
+    là thêm và xóa tập tin. Git còn hỗ trợ thêm việc tích hợp các thay đổi
     (hoặc sự khác biệt) giữa của tập tin ở hai nhánh khác nhau.
     Lấy ví dụ, ta sẽ chỉnh nội dung tập tin ở một nhánh, trong khi ở nhánh
-    kia ta đổi tên tập tin, rồi rồi trộn hai tập tin đó với nhau. Nghe
+    kia ta đổi tên tập tin, rồi rồi tích hợp hai tập tin đó với nhau. Nghe
     có vẻ rối đây! Xem Git giải quyết thế nào nhé!
     

 
@@ -460,7 +460,7 @@ 

     
-    
Bây giờ ta đang ở nhánh 'master'. Ta sẽ tạo nhánh 'change_class'
+    
Bây giờ ta đang ở nhánh 'master'. Ta sẽ tạo nhánh 'change_class'
     và rẽ ngay vào nhánh đó: trong nhánh mới ta sẽ thực hiện đổi tên lớp
     từ 'HelloWorld' dthành 'HiWorld'.

 
@@ -482,7 +482,7 @@ 

       time rename the file from hello.rb to ruby.rb.
       
-->
     
Việc đổi tên lớp được xác nhận sau lệnh git commit.
-      Ta sẽ trở lại nhánh chính 'master' và sẽ thấy rằng trong tên lớp
+      Ta sẽ trở lại nhánh chính 'master' và sẽ thấy rằng trong tên lớp
       vẫn là 'HelloWorld' (như cũ!). Ta sẽ đổi xem có sự khác biệt nào
       với thay đổi đã thực hiện ở nhánh 'change_class', đồng thời đổi tên
       tập tin từ hello.rb thành ruby.rb.
@@ -519,10 +519,10 @@ 

       branch.  However, the name of the file has changed since we branched,
       what will Git do?
-->
     
Như ban thấy, sự thay đổi tên tập tin và nội dung cũng vừa được
-      xác nhận trong nhánh 'master'. Để ý rằng, tên lớp vẫn là 'HelloWorld'.
-      Nếu muốn thay đổi cả tên của lớp thành 'HiWorld', ta chỉ việc trộn
-      nội dung ở nhánh 'change_class' vào nhánh 'master'. Nhưng liệu Git
-      có trộn được không, vì tên tập tin đã đổi? Hãy xem:

+      xác nhận trong nhánh 'master'. Để ý rằng, tên lớp vẫn là 'HelloWorld'.
+      Nếu muốn thay đổi cả tên của lớp thành 'HiWorld', ta chỉ việc tích hợp
+      nội dung ở nhánh 'change_class' vào nhánh 'master'. Nhưng liệu Git
+      có tích hợp được không, vì tên tập tin đã đổi? Hãy xem:

 
 
 $ git branch
@@ -548,7 +548,7 @@ 

     and the file that had been renamed now has the 'HiWorld' class name change
     that was done in the other branch. Pretty cool.
-->
     
Tốt quá, mọi chuyện diễn ra đúng như mong đợi. Như vậy trong quá
-    trình trộn ta đã không gặp xung đột nào, kể cả việc đổi tên tập tin
+    trình tích hợp ta đã không gặp xung đột nào, kể cả việc đổi tên tập tin
     hoặc đổi tên lớp diễn ra ở nhánh khác

 
     

@@ -580,10 +580,10 @@ 

 
     
+      our 'master' branch.
-->
     
Sau khi rẽ vào nhánh 'fix_readme', ta thực hiện thay đổi một dòng
       trong tập tin 'README'. Tiếp theo ta sẽ thay đổi cùng dòng đó, nhưng
-      ở tập tin của nhánh 'master'.

+      ở tập tin của nhánh 'master'.

 
 
 $ git checkout master
@@ -596,7 +596,7 @@ 

 
     
-    
Hãy xem có điều thú vị gì xảy ra khi trộn hai tập tin có xung đột
+    
Hãy xem có điều thú vị gì xảy ra khi tích hợp hai tập tin có xung đột
     với nhau:

 
 
@@ -623,7 +623,7 @@ 

       (like kdiff3, emerge, p4merge, etc) instead.
     
-->
     
Như bạn thấy, Git chèn vào các ký hiệu đánh dấu sự xung đột xảy
-      ra khi trộn. Git đã 'bó tay' khi dừng lại ở đó, và tới phiên bạn
+      ra khi tích hợp. Git đã 'bó tay' khi dừng lại ở đó, và tới phiên bạn
       quyết định. Để ý là,
       một số công cụ đồ họa
       như kdiff3, emerge, p4merge, ... sẽ giúp việc giải quyết xung đột
@@ -650,7 +650,7 @@ 

     and how you've resolved it as shown here. Now it's time to mark
     the file as resolved.  In Git we do that with git add -
     to tell Git the file has been resolved you have to stage it.
-->
-    
Một mẹo rất hay khi trộn các xung đột trong Git là nếu khi dùng
+    
Một mẹo rất hay khi tích hợp các xung đột trong Git là nếu khi dùng
         git diff,
     chương trình sẽ cho bạn thấy cả hai phần (cũ, mới) gây nên xung đột,
     và cả cách giải quyết xung đột. Sau đó, bạn cần đánh dấu cho tập tin
@@ -678,8 +678,8 @@ 

     how to best combine the different snapshots into a new snapshot with the
     unique work of both.
     
-->
-    Tóm tắt: bạn dùng git merge để trộn một nhánh với
-    nhánh bạn đang rẽ vào. Git sẽ tự động xác định phép trộn tốt nhất để
+    Tóm tắt: bạn dùng git merge để tích hợp một nhánh với
+    nhánh bạn đang rẽ vào. Git sẽ tự động xác định phép tích hợp tốt nhất để
     có được sản phẩm chung lai giữa hai nhánh.
     

 
@@ -796,17 +796,16 @@ 

     
+    state of the snapshot and thus what is in it.
-->
     
Qua thông tin thu được, ta hình dung được toàn bộ quá trình phát triển
     của nhánh hiện tại (và của dự án). Nếu trong mỗi lần xác nhận, thông điệp
     ta muốn Git lưu lại càng chi tiết thì ta dễ dàng nhớ lại, hình dùng
     tốt về các thay đổi đã thực hiện cũng như ảnh hưởng của nó lên nhánh
     hiện tại..

 
+    
     
Ngoài ra, tùy chọn --graph rất thú vị, khi nó vẽ ra
     một cây phản ánh cấu trúc nhánh của dự án: Kết quả của tùy chọn này
     giải thích tại sao ta dùng từ 'nhánh' để mô tả dự án

@@ -839,7 +838,7 @@ 

     muddy up our stable branch with code that may not work for a while so we
     can cleanly switch in and out of it.
-->
     
Minh họa có vẻ đơn sơ trên thực tế giúp bạn hình dung rõ hơn về
-    dự án, lý do tạo nhánh và trộn các nhánh, và cũng giúp ích cho việc
+    dự án, lý do tạo nhánh và tích hợp các nhánh, và cũng giúp ích cho việc
     quản lý các nhánh. Sau đây, ta sẽ thử tạo nhánh mới, rẽ vào đó để thực
     hiện vài thay đổi rồi qua lại nhánh chính. Ta sẽ dùng lệnh log
     để hình dung chung về tất cả các nhánh.

@@ -903,8 +902,8 @@ 

     that branch, that is the commits that influenced the final snapshot.
-->
     
Gỉa sử rằng mọi việc đã xong, bạn quay lại với các công việc khác
     hơn là dự án HelloWorld buồn tẻ. Rồi một ngày khác, quay lại dự án này
-    ở nhánh 'master', bạn muốn biết những gì đã diễn ra trên nhánh 'erlang'
-    và vị trí trên nhánh chính 'master' mà bạn bắt đầu rẽ vào 'erlang'.
+    ở nhánh 'master', bạn muốn biết những gì đã diễn ra trên nhánh 'erlang'
+    và vị trí trên nhánh chính 'master' mà bạn bắt đầu rẽ vào 'erlang'.
     Nếu chỉ rẽ vào nhánh rồi xem nội dung các tập tin trong nhánh
     đó, hiển nhiên là bạn sẽ không hình dung tại sao lại có phiên bản Haskell
     trong nhánh 'erlang'. Bạn cần phải dùng git log để tìm
@@ -947,16 +946,16 @@ 

       nhiều thông tin ở trước thời điểm nhánh 'erlang' được tạo ra.
       Quá nhiều! Điều tuyệt vời là Git đã tính tới phàn nàn này: bạn có thể
       chỉ định Git đưa các thông tin chỉ có ở nhánh này mà không xuất hiện
-      ở nhánh khác. Điều này rất có ích, chẳng hạn khi bạn muốn trộn nhánh
-      'erlang' vào nhánh 'master', nhưng trước khi trộn, bạn cần biết
-      những gì sẽ diễn ra khi trộn.
+      ở nhánh khác. Điều này rất có ích, chẳng hạn khi bạn muốn tích hợp nhánh
+      'erlang' vào nhánh 'master', nhưng trước khi tích hợp, bạn cần biết
+      những gì sẽ diễn ra khi tích hợp.
     

 
     

       Để không liệt kê các thông tin không cần thiết của một nhánh, bạn
       dùng dấu mũ ^ trước tên nhánh. Ví dụ, nếu chỉ muốn xem
       các thay đổi trong nhánh 'erlang', bỏ đi các thay đổi trong nhánh
-      'master', chỉ việc dùng erlang ^master:
+      'master', chỉ việc dùng erlang ^master:
     

 
 
@@ -974,7 +973,7 @@ 

     
Sử dụng dấu mũ là một cách đơn giản, hiểu quả khi quản lý các nhánh,
       cho phép bạn thấy được những cái chỉ có ở nhánh này mà không có ở
       nhánh khác. Nhờ đó, bạn kiểm soát các thiếu sót hoặc hình dung
-      được những thay đổi khi trộn các nhánh.
+      được những thay đổi khi tích hợp các nhánh.
     

 
     

diff --git a/vi/creating/index.html b/vi/creating/index.html
index d22b5ff..345ba85 100644
--- a/vi/creating/index.html
+++ b/vi/creating/index.html
@@ -3,7 +3,7 @@
 ---
 
 

-  
Nhận và Tạo Dự Án

+  
Khai Thác và Tạo Dự Án

   

     
-    
Trong dự án này, ta viết chương trình "Hello World" trong các ngôn
-    ngữ khác nhau, và ta bắt đầu với ngôn ngữ Ruby. Ta sẽ tạo mới một
-    kho lưu trữ Git cho thư mục 'konichiwa', cũng là cho dự án với lệnh
-    git init:

+    
Trong dự án này, chương trình "Hello World" được viết bằng các ngôn
+    ngữ khác nhau, và Ruby là ngôn ngữ đầu tiên. Để bắt đầu quản lý
+    phiên bản với Git, đơn giản ta chạy lệnh git init để
+    tạo kho lưu trữ:

 
 
 $ git init
@@ -170,7 +170,7 @@ 

     
-->
     

     Khi nhân bản, Git mặc định tạo một thư mục cùng tên với kho Git trong phần địa
-    chỉ được cho khi nhân bản (phần tên này nằm sau dấu gạch / cuối cùng).
+    chỉ được cho khi nhân bản (phần tên này nằm sau dấu gạch chéo cuối cùng).
     Tuy nhiên, nếu bạn muốn kết quả nhân bản nằm trong thư mục khác, bạn có thể
     chỉ ra ở sau địa chỉ kho (cách với địa chỉ kho ít nhất một khoảng trắng.)
     

diff --git a/vi/remotes/index.html b/vi/remotes/index.html
index 1ddb1c8..19315e8 100644
--- a/vi/remotes/index.html
+++ b/vi/remotes/index.html
@@ -18,19 +18,7 @@ 

     does this is to synchronize your data with another repository.  There
     is no real difference between a server and a client - a Git repository
     is a Git repository and you can synchronize between any two easily.
-    

-
-    
Once you have a Git repository, either one that you set up on your
-    own server, or one hosted someplace like GitHub, you can tell Git to
-    either push any data that you have that is not in the remote repository
-    up, or you can ask Git to fetch differences down from the other repo.
-    

-
-    
You can do this any time you are online, it does not have to correspond
-    with a commit or anything else.  Generally you will do a
-    number of commits locally, then fetch data from the online shared repository
-    you cloned the project from to get up to date, merge any new work into the
-    stuff you did, then push your changes back up.
-->
+    
-->
     

     Git không tập trung dữ liệu mở một máy phục vụ như Subversion. Mà tất
     cả thao tác sẽ cập nhật dữ liệu ngay trên máy tính của bạn. Để cộng tác
@@ -41,6 +29,11 @@ 

     trên máy phục vụ.
     

 
+    
     

     Môt khi đã có kho lưu trữ Git, hoặc là bạn sẽ thiết lập máy của bạn thành
     một máy phục vụ sử dụng kho đó để chia sẻ, hoặc bạn sẽ tiến hành đồng
@@ -48,6 +41,11 @@ 

     hai thao tác đẩy và kéo.
     

 
+    
     

     Thao tác đẩy và kéo được tiến hành bất kỳ khi nào bạn có kết nối mạng
     với kho Git khác, trong khi đó thao tác xác nhận (commit)
@@ -81,19 +79,18 @@ 

     very different from a server, Git repositories are all basically equal and
     you simply synchronize between them. This makes it easy to have more than
     one remote repository - you can have some that you have read-only access to
-    and others that you can write to as well.

-
-    
So that you don't have to use the full URL of a remote repository every
-    time you want to synchronize with it, Git stores an alias or nickname for
-    each remote repository URL you are interested in. You use the
-    git remote command to manage this list of remote repos that
-    you care about.
-->
+    and others that you can write to as well.
-->
     
Vì Git không dùng một máy phục vụ chung để lưu dữ liệu như Subversion,
     các kho lưu trữ Git bình đẳng nhau, nằm trên các máy khác nhau và nhiệm
     vụ của bạn là đồng bộ những kho này với nhau. Từ đó, nảy sinh ra ý phải
     quản lý các kho cùng với kết nối tới chúng, kể cả phân quyền (đọc với
     kho này, được ghi vào kho kia,...). 

 
+    
     
Các kho ở máy phục vụ khác nhau không chỉ được phân biệt bằng địa chỉ URL đầy đủ, mà còn có thể bằng một tên ngắn gọn mà bạn gán cho địa chỉ đó. Như vậy,
     việc sử dụng các kho sẽ dễ nhớ, đơn giản hơn rất nhiều. Bạn sử dụng lệnh
     git remote để quản lý danh sách các kho.

@@ -138,17 +135,17 @@ 

     contributions from someone else's repository - if you want to interact in
     any way with a new repository, it's generally easiest to add it as a remote.
     You do that by running git remote add [alias] [url].  That
-    adds [url] under a local remote named [alias].

+    adds [url] under a local remote named
+    [alias].
-->
+    
Ta có thể thêm nhiều địa chỉ kho khác nhau cho dự án, bằng lệnh
+    git remote add [tên] [địa chỉ]. Ở đây, '[tên]' là do bạn
+    chọn để gợi nhớ, đại diện cho địa chỉ của kho (thường dài dòng khó nhớ).

 
-    
For example, if we want to share our Hello World program with the world,
+    
-    
Ta có thể thêm nhiều địa chỉ kho khác nhau cho dự án, bằng lệnh
-    git remote add [tên] [địa chỉ]. Ở đây, '[tên]' là do bạn
-    chọn để gợi nhớ, đại diện cho địa chỉ của kho (thường dài dòng khó nhớ).

-
     
Lấy ví dụ, bạn muốn chia sẻ chương trình Hello World với mọi người
     bằng cách đẩy nó lên GitHub (dịch vụ khác cũng tương tự), trước hết
     bạn tạo dự án ở GitHub, có tên là hw. Địa chỉ kho mà dịch vụ
@@ -213,7 +210,7 @@ 

     you can do that by running git remote rename [old-alias] [new-alias]. This will
     allow you to modify the current name of the remote.
-->
     
Nếu bạn muốn đổi tên hiện tại của một kho đầu xa mà không phải xóa và thêm vào lần
-    nữa, bạn dùng lệnh  git remote rename [old-alias] [new-alias]

+    nữa, bạn dùng lệnh  git remote rename [tên-cũ] [tên-mới]

 
 
 $ git remote add github git@github.com:schacon/hw.git
@@ -243,9 +240,11 @@ 

       cập nhật địa chỉ URL kho đầu xa
     

 
-    
Should you ever need to update a remote's URL, you can do so with
+    
+    
Lệnh git remote set-url dùng để cập nhật địa chỉ đầu
+    xa

 
 
 $ git remote -v
@@ -261,10 +260,12 @@ 

 origin	git://github.com/github/git-reference.git (push)
 

 
-    
In addition to this, you can set a different push URL when you
+    
+    
Với trường hợp dưới đây, bạn có thể thêm địa chỉ đẩy khác khi kèm
+    theo cờ --push để tách biệt hai kho đẩy và tải về.

 
 
 $ git remote -v
@@ -280,16 +281,22 @@ 

 origin	git://github.com/pjhyett/hw.git (push)
 

 
-    
Internally, the git remote set-url command calls
+    
+    
Thực chất, lệnh git remote set-url thực thi lệnh
+    git config remote nhưng trả về kết quả nếu xảy ra lỗi
+    còn lệnh git config remote không trả về kết quả nếu bạn
+    gõ nhầm hoặc lệnh không thực hiện.

 
-    
For example, we'll update the github remote but
+    
+    
Chúng ta sẽ cập nhật kho đầu xa github nhưng ta dùng
+    guhflub trong cả hai trường hợp.

 
 
 $ git remote -v
@@ -308,9 +315,12 @@ 

 

 
     

-    In a nutshell, you can update the locations of your remotes
+    
+    Tóm tắt: bạn có thể cập nhật đường dẫn kho đầu xa với lệnh
+    git remote set-url. Bạn cũng có thể tách riêng biệt địa
+    chỉ tải về và địa chỉ đẩy.
     

 
   


From 0e810929f50f954e30bc472a66ec7b189effc2f8 Mon Sep 17 00:00:00 2001
From: Tran Dinh Anh Tuan 
Date: Mon, 31 Mar 2014 16:33:43 +0700
Subject: [PATCH 4/4] Hoan tat ban dich sang tieng Viet

---
 vi/basic/index.html   |  60 ++++++++++++++++-----
 vi/inspect/index.html | 119 ++++++++++++++++++++++++++++++------------
 2 files changed, 134 insertions(+), 45 deletions(-)

diff --git a/vi/basic/index.html b/vi/basic/index.html
index 605fd5d..f0e24ff 100644
--- a/vi/basic/index.html
+++ b/vi/basic/index.html
@@ -1198,9 +1198,13 @@ 

     liệt kê ngăn xếp
     

 
-    
It's helpful to know what you've got stowed on the stash and this is where
+    
+    
Đôi khi, bạn cần biết bạn đã xếp gọn những gì vào ngăn cất giấu, lệnh
+    git stash list sẽ hiển thị một hàng danh sách của các mục cất
+    giấu của bạn.
     

 
 
@@ -1208,8 +1212,11 @@ 

 stash@{0}: WIP on master: 5857ac1 hello with a flower
 

 
-    
The last item added onto the stash will be referenced by
+    
+    
Mục cuối cùng thêm vào ngăn cất giấu được tham chiếu đến
+    stash@{0} và tăng dần theo một.
     

 
 
@@ -1228,12 +1235,18 @@ 

 
     

       git stash apply
-      grab the item from the stash list and apply to current working directory
+      
+      đưa mục từ kho cất giấu vào thư mục làm việc
     

 
-    
When you're ready to continue from where you left off, run the
+    
+    
Khi bạn đã sẵn sàng tiếp tục công việc từ khi bạn đã cất giấu, lệnh
+    git stash apply sẽ đem các thay đổi đã cất giấu trở lại thư
+    mục làm việc.
     

 
 
@@ -1248,31 +1261,47 @@ 

 no changes added to commit (use "git add" and/or "git commit -a")
 

 
-    
By default it will reapply the last added stash item to the working
+    
+    
Mặc định, lệnh trên sẽ tái ghép mục cuối cùng, tham chiếu đến
+    stash@{0}, vào thư mục làm việc. Bạn có thể tái ghép mục cất giấu
+    khác bằng cách thêm vào tham chiếu trong danh sách đối số. Ví dụ, git
+        stash apply stash@{1} sẽ tái ghép mục tham chiếu
+    stash@{1}.
     

 
-    
If you also want to remove the item from the stack at the same time,
+    
+    
Nếu bạn muốn xóa mục khỏi ngăn cất giấu sau khi tái ghép, dùng lệnh
+    git stash pop thay thế.
     

 
     

       git stash drop
-      remove an item from the stash list
+      
+      xóa một mục khỏi danh sách cất giấu
     

 
-    
When you're done with the stashed item and/or want to remove it from the
+    
+    
Lệnh git stash drop sẽ xóa mục đã cất giấu. Mặc định, lệnh
+    sẽ xóa mục cuối cùng nếu bạn không kèm theo đối số để xóa một mục xác định.
     

 
-    
In this example, our stash list has at least two items, but we want
+    
+    
Trong ví dụ sau, chúng ta có hai mục trong danh sách cất giấu nhưng
+    chúng ta muốn xóa mục đầu tiên được tham chiếu đến stash@{1}.
     

 
 
@@ -1280,15 +1309,22 @@ 

 Dropped stash@{1} (0b1478540189f30fef9804684673907c65865d8f)
 

 
-    
If you want to remove of all the stored items, just run
+    
+    
Khi đã chắc chắn hoàn tất các công việc với danh sách cất giấu, bạn có
+    thể dùng lệnh git stash clear để xóa tất cả các mục đã cất
+    giấu.
     

 
     

-    In a nutshell, run git stash to quickly save
+    
+    Tóm tắt: lệnh git stash lưu tạm vài thay đổi
+    bạn chưa dự định xác nhận, và sẽ được tiếp tục khi bạn đã xong công việc
+    khác.
     

 
   

diff --git a/vi/inspect/index.html b/vi/inspect/index.html
index 4414d19..32b049a 100644
--- a/vi/inspect/index.html
+++ b/vi/inspect/index.html
@@ -285,6 +285,8 @@ 

     It is a great way to summarize what has happened on a branch or between
     commits.
     

+    
 
 
 $ git log -p --no-merges -2
@@ -327,17 +329,23 @@ 

  This project has examples of hello world in
 

 
-    
This is a really nice way of summarizing changes or reviewing a series
-    of commits before merging them or releasing something.

+    
+    
Đây là một cách tuyệt vời để tổng hợp các thay đổi hoặc xem lại một nhóm
+    các xác nhận trước khi tích hợp vào nhánh chính hay phát hành bản vá.

 
     

       git log --stat
-      show diffstat of changes introduced at each commit
+      
+      hiển thị thống kê thay đổi theo từng xác nhận
     

 
-    
If the -p option is too verbose for you, you can summarize
+    
+    
Nếu tùy chọn -p quá dài dòng, bạn có thể tóm tắt các thay
+    đổi với --stat. Đây là kết quả của --stat thay
+    cho -p ở ví dụ trên.

 
 
 $ git log --stat --no-merges -2
@@ -360,8 +368,10 @@ 

  1 files changed, 1 insertions(+), 1 deletions(-)
 

 
-    
Same basic information, but a little more compact - it still lets you
-    see relative changes and which files were modified.

+    
+    
Cùng thông tin cơ bản nhưng gọn gàng, cô đọng hơn - bạn vẫn xem được các
+    thay đổi liên quan và các tập tin nào đã được chỉnh sửa.

 
   
 
@@ -418,8 +428,10 @@ 

 +HelloWorld.hello
 

 
-    
Just like git log, you can use the --stat
-      option with it.

+    
+    
Bạn có thể thêm tùy chọn --stat giống như đã dùng với lệnh
+    git log.

 
 
 $ git diff v0.9 --stat
@@ -428,7 +440,7 @@ 

  2 files changed, 3 insertions(+), 3 deletions(-)
 

 
-    
To compare two divergent branches, however, you can run something like
+    
+    
Để so sánh hai nhánh khác nhau, tuy nhiên, bạn có thể chạy một cái gì đó
+    như git diff branchA branchB nhưng vấn đề là nó sẽ làm chính
+    xác những gì bạn đang yêu cầu - về cơ bản nó sẽ cung cấp cho bạn một tập
+    tin vá lỗi mà có thể biến ảnh chụp ở mũi của branchA vào ảnh chụp ở mũi của
+    branchB. Điều này có nghĩa nếu hai ngành đã tách ra - đi theo các hướng
+    khác nhau - nó sẽ loại bỏ tất cả các công việc đã được giới thiệu vào
+    branchA và sau đó thêm tất cả mọi thứ đã được giới thiệu vào branchB. Điều
+    này có lẽ không phải những gì bạn muốn - bạn muốn thay đổi thêm vào branchB
+    mà không phải là trong branchA, vì vậy bạn thực sự muốn sự khác biệt giữa
+    nơi hai nhánh tách ra và chóp branchB. Vì vậy, nếu lịch sử của chúng tôi
+    trông như thế này:

 
 
 $ git log --graph --oneline --decorate --all
@@ -449,9 +472,12 @@ 

 ...
 

 
-    
And we want to see what is on the "erlang" branch compared to the "master"
-    branch, running git diff master erlang will give us the wrong
-    thing.

+    
+    
Và chúng ta muốn xem những gì trên nhánh "erlang" so với nhánh "master",
+    chạy git diff master erlang sẽ cung cấp cho chúng ta điều sai
+    trái.

 
 
 $ git diff --stat master erlang
@@ -461,12 +487,18 @@ 

  3 files changed, 11 insertions(+), 2 deletions(-)
 

 
-    
You see that it adds the erlang and haskell files, which is what we did
-    in that branch, but then the output also reverts the changes to the ruby file
-    that we did in the master branch.  What we really want to see is just the
-    changes that happened in the "erlang" branch (adding the two files).  We can
-    get the desired result by doing the diff from the common commit they diverged
-    from:

+    
+    
Bạn thấy rằng nó thêm các tập tin của erlang và haskell, đó là những gì
+    chúng tôi đã làm trong chi nhánh đó, nhưng sau đó sản lượng cũng trở lại
+    trạng các thay đổi đối với ruby tập tin mà chúng tôi đã làm trong ngành
+    chủ. Những gì chúng ta thực sự muốn nhìn thấy chỉ là những thay đổi đã xảy
+    ra trong "Erlang" chi nhánh (thêm hai tập tin).  Chúng ta có thể có được
+    kết quả mong muốn bằng cách làm khác từ phổ biến cam kết họ tách ra từ:

 
 
 $ git diff --stat 8d585ea erlang
@@ -475,12 +507,18 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
 

 
-    
That's what we're looking for, but we don't want to have to figure out
+    
+    
Đó là những gì chúng tôi đang tìm kiếm, nhưng chúng tôi không muốn phải
+    tìm ra những gì cam kết hai nhánh tách ra từ mỗi lần. May mắn thay, có một
+    Git phím tắt này. Nếu bạn chạy git diff master...erlang (với
+    ba dấu chấm ở giữa tên chi nhánh), Git sẽ tự động tìm ra những gì phổ biến
+    cam kết (hay còn gọi là "hợp nhất cơ sở") của hai cam kết được và làm khác
+    ra điều đó.

 
 
 $ git diff --stat master erlang
@@ -494,21 +532,29 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
 

 
-    
Nearly every time you want to compare two branches, you'll want to use
+    
+    
Gần như tất cả thời gian bạn muốn so sánh hai nhánh, bạn sẽ muốn sử dụng
+    cú pháp ba dấu chấm, bởi vì nó sẽ hầu như luôn luôn cung cấp cho bạn những
+    gì bạn muốn.

 
-    
As a bit of an aside, you can also have Git manually calculate what the
+    
+    
Như một chút của một sang một bên, bạn cũng có thể có Git tay tính toán
+    những gì hợp nhất cơ sở (tổ tiên đầu tiên phổ biến cam kết) của hai cam kết
+    sẽ với các git merge-base lệnh:

 
 
 $ git merge-base master erlang
 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
 

 
-    
You can do the equivalent of git diff master...erlang
-    by running this:

+    
+    
Lệnh git diff master...erlang có thể được thực hiện bằng
+    lệnh tương đương sau:

 
 
 $ git diff --stat $(git merge-base master erlang) erlang
@@ -517,19 +563,26 @@ 

  2 files changed, 9 insertions(+), 0 deletions(-)
 

 
-    
You may prefer using the easier syntax though.

+
+
Bạn có thể tùy ý dùng câu lệnh dễ nhớ.

 
 
     

-    In a nutshell you can use git diff to see how a project
+    
+    Tóm tắt: lệnh git diff cho bạn biết dự án thay đổi thế
+    nào từ lần cuối bạn xem hoặc các công việc độc đáo của một nhánh từ lúc
+    tách ra. Luôn dùng lệnh git diff branchA...branchB để kiểm tra
+    nhánhB liên quan nhánhB thế nào.
     

 
   
 
 
-
And that's it!  For more information, try reading the
-Pro Git book.

+
+
Bạn hãy đọc Pro Git book để hiểu hơn
+về Git.