Skip to content

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also compare across forks.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also compare across forks.
...
  • 11 commits
  • 28 files changed
  • 0 commit comments
  • 5 contributors
Showing with 292 additions and 271 deletions.
  1. +20 −3 en/clone.txt
  2. +5 −5 fr/preface.txt
  3. +1 −1 ru/basic.txt
  4. +4 −4 ru/branch.txt
  5. +7 −7 ru/clone.txt
  6. +5 −5 ru/drawbacks.txt
  7. +2 −2 ru/history.txt
  8. +2 −2 ru/intro.txt
  9. +4 −5 ru/multiplayer.txt
  10. +5 −5 ru/preface.txt
  11. +2 −2 ru/secrets.txt
  12. +2 −2 ru/translate.txt
  13. +4 −4 vi/README
  14. +29 −29 vi/basic.txt
  15. +19 −19 vi/branch.txt
  16. +18 −18 vi/clone.txt
  17. +16 −16 vi/drawbacks.txt
  18. +9 −9 vi/grandmaster.txt
  19. +10 −10 vi/history.txt
  20. +16 −16 vi/intro.txt
  21. +9 −9 vi/multiplayer.txt
  22. +19 −18 vi/preface.txt
  23. +10 −10 vi/secrets.txt
  24. +14 −10 vi/translate.txt
  25. +19 −5 zh_cn/clone.txt
  26. +11 −25 zh_cn/preface.txt
  27. +19 −5 zh_tw/clone.txt
  28. +11 −25 zh_tw/preface.txt
View
23 en/clone.txt
@@ -32,7 +32,7 @@ On the central server, initialize a 'bare repository' in some directory:
$ mkdir proj.git
$ cd proj.git
$ git init --bare
- $ # one-line variant: GIT_DIR=proj.git git init
+ $ touch proj.git/git-daemon-export-ok
Start the Git daemon if necessary:
@@ -43,11 +43,11 @@ empty Git repository. Typically one fills in a form on a webpage.
'Push' your project to the central server with:
- $ git push git://central.server/path/to/proj.git HEAD
+ $ git push central.server/path/to/proj.git HEAD
To check out the source, a developer types:
- $ git clone git://central.server/path/to/proj.git
+ $ git clone central.server/path/to/proj.git
After making changes, the developer saves changes locally:
@@ -68,6 +68,23 @@ To check in local changes into the central repository:
If the main server has new changes due to activity by other developers, the
push fails, and the developer should pull the latest version, resolve any merge conflicts, then try again.
+Developers must have SSH access for the above pull and push commands.
+However, anyone can see the source by typing:
+
+ $ git clone git://central.server/path/to/proj.git
+
+The native git protocol is like HTTP: there is no authentication, so anyone can
+retrieve the project. Accordingly, by default, pushing is forbidden via the git
+protocol.
+
+=== Secret Source ===
+
+For a closed-source project, omit the touch command, and ensure you never
+create a file named `git-daemon-export-ok`. The repository can no longer be
+retrieved via the git protocol; only those with SSH access can see it. If all
+your repos are closed, running the git daemon is unnecessary because all
+communication occurs via SSH.
+
=== Bare repositories ===
A bare repository is so named because it has no working directory; it only contains files that are normally hidden away in the `.git` subdirectory. In other words, it maintains the history of a project, and never holds a snapshot of any given version.
View
10 fr/preface.txt
@@ -30,21 +30,21 @@ recettes pour répondre à vos besoins.
Gaborit et Nicolas Deram. Hébergé aussi chez
http://tutoriels.itaapy.com/[itaapy].
- - link:/~blynn/gitmagic/intl/de/[Allemand] : par Benjamin Bellee et Armin
+ - link:/~blynn/gitmagic/intl/de/[Allemande] : par Benjamin Bellee et Armin
Stebich. Hébergé aussi sur http://gitmagic.lordofbikes.de/[le site web
d'Armin].
- - http://www.slideshare.net/slide_user/magia-git[Portugais] : par
+ - http://www.slideshare.net/slide_user/magia-git[Portugaise] : par
Leonardo Siqueira Rodrigues
[http://www.slideshare.net/slide_user/magia-git-verso-odt[version ODT]].
- - link:/~blynn/gitmagic/intl/ru/[Russian]: par Tikhon Tarnavsky, Mikhail
+ - link:/~blynn/gitmagic/intl/ru/[Russe]: par Tikhon Tarnavsky, Mikhail
Dymskov et d'autres.
- - link:/~blynn/gitmagic/intl/es/[Espagnol] : par Rodrigo Toledo et Ariset
+ - link:/~blynn/gitmagic/intl/es/[Espagnole] : par Rodrigo Toledo et Ariset
Llerena Tapia.
- - link:/~blynn/gitmagic/intl/vi/[Vietnamien]: par Trần Ngọc Quân. Hébergé
+ - link:/~blynn/gitmagic/intl/vi/[Vietnamienne]: par Trần Ngọc Quân. Hébergé
aussi sur http://vnwildman.users.sourceforge.net/gitmagic.html[son site
Web].
View
2 ru/basic.txt
@@ -79,7 +79,7 @@ Date: Thu Jan 1 00:00:00 1970 +0000
- *git reset --hard*: загружает ранее сохраненную игру и удаляет все версии, сохраненные после только что загруженной.
-- *git checkout*: загружает старую игру, но если вы продолжаете играть, состояние игры будет отличаться от более новых сохранений, которые вы сделали в первый раз. Любая игра, которую вы теперь сохраняете, попадает в отдельную ветвь, представляющую альтенативную реальность, в которую вы попали. <<branch,Мы обсудим это позже>>.
+- *git checkout*: загружает старую игру, но если вы продолжаете играть, состояние игры будет отличаться от более новых сохранений, которые вы сделали в первый раз. Любая игра, которую вы теперь сохраняете, попадает в отдельную ветку, представляющую альтенативную реальность, в которую вы попали. <<branch,Мы обсудим это позже>>.
Можно также восстановить только определенные файлы и подкаталоги, перечислив их имена после команды:
View
8 ru/branch.txt
@@ -1,8 +1,8 @@
== Чудеса ветвления ==
-Возможности мгновенного ветвления и слияния — самые потрясающие особенности Git.
+Возможности мгновенного ветвления и слияния — самые замечательный особенности Git.
-*Задача*: внешние факторы неизбежно влекут переключение внимания. Серьезная ошибка обнаруживается в уже выпущенной версии без предупреждения. Срок сдачи конкретного функционала приближается. Разработчик, помощь которого нужна вам в работе над ключевой частью проекта, собирается в отпуск. Одним словом, вам нужно срочно бросить все, над чем вы трудитесь в настоящий момент, и переключиться на совершенно другие задачи.
+*Задача*: внешние факторы неизбежно влекут переключение внимания. Серьезная ошибка в уже выпущенной версии обнаруживается без предупреждения. Срок сдачи конкретного функционала приближается. Разработчик, помощь которого нужна вам в работе над ключевой частью проекта, собирается в отпуск. Одним словом, вам нужно срочно бросить все, над чем вы трудитесь в настоящий момент, и переключиться на совершенно другие задачи.
Прерывание хода ваших мыслей может серьезно снизить эффективность работы, и чем сложнее переключение между процессами, тем больше будет потеря. При централизованном управлении версиями мы вынуждены скачивать свежую рабочую копию с центрального сервера. Распределенная система лучше: мы можем клонировать нужную версию локально.
@@ -26,7 +26,7 @@
Мы создали хранилище Git, содержащее один текстовый файл с определенным сообщением. Теперь выполните
$ git checkout -b boss # вероятно, это последнее изменение
- $ echo "Мой босс меня умнее" > myfile.txt
+ $ echo "Мой босс умнее меня" > myfile.txt
$ git commit -a -m "Другой коммит"
Это выглядит так, будто мы только что перезаписали файл и сделали коммит. Но это иллюзия. Наберите
@@ -79,7 +79,7 @@
и вернитесь к работе над вашими исходными задачами.
-Вы можете даже «влить» только что сделанное исправление ошибки:
+Вы можете даже «влить» только что сделанное исправление ошибки в основную ветку:
$ git merge fixes
View
14 ru/clone.txt
@@ -70,7 +70,7 @@
Голое (bare) хранилище называются так потому, что у него нет рабочего каталога. Оно содержит только файлы, которые обычно скрыты в подкаталоге .git. Другими словами, голое хранилище содержит историю изменений, но не содержит снимка какой-либо определенной версии.
-Голое хранилище играет роль, похожую на роль основного сервера в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют с него проект и закачивают в него свежие официальные изменения. Как правило, он располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога.
+Голое хранилище играет роль, похожую на роль основного сервера в централизованной системе управления версиями: это дом вашего проекта. Разработчики клонируют из него проект и закачивают в него свежие официальные изменения. Как правило, оно располагается на сервере, который не делает почти ничего кроме раздачи данных. Разработка идет в клонах, поэтому домашнее хранилище может обойтись и без рабочего каталога.
Многие команды Git не работают в голых хранилищах, если переменная среды GIT_DIR не содержит путь до хранилища и не указан параметр --bare.
@@ -86,7 +86,7 @@
Не нравится путь развития проекта? Думаете, можете сделать лучше? Тогда на вашем сервере выполните
- $ git clone git://main.server/path/to/files
+ $ git clone git://основной.сервер/путь/к/файлам
Теперь расскажите всем о форке (ответвлении, прим. пер.) проекта на вашем сервере.
@@ -96,7 +96,7 @@
=== Максимальные бэкапы ===
-Хотите иметь множество защищенных, географически разнесенных избыточных архивов? Если в вашем проекте много разработчиков, ничего делать не нужно! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хешированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
+Хотите иметь множество защищенных, географически разнесенных запасных архивов? Если в вашем проекте много разработчиков, ничего делать не нужно! Каждый клон — это и есть резервная копия; не только текущего состояния, но и всей истории изменений проекта. Благодаря криптографическому хешированию, повреждение какого-либо из клонов будет обнаружено при первой же попытке взаимодействия с другими клонами.
Если ваш проект не такой популярный, найдите как можно больше серверов для размещения клонов.
@@ -169,16 +169,16 @@ Mercurial — похожая система управления версиям
Упомянем вкратце Bazaar, так как это самая популярная свободная распределенная система управления версиями после Git и Mercurial.
-Bazaar относительно молода, поэтому у нее есть преимущество идущего следом. Его проектировщики могут учиться на ошибках предшественников и избавиться от исторически сложившихся неровностей. Кроме того, его разработчики заботятся о переносимости и взаимодействии с другими системами управления версиями.
+Bazaar относительно молод, поэтому у него есть преимущество идущего следом. Его проектировщики могут учиться на ошибках предшественников и избавиться от исторически сложившихся неровностей. Кроме того, его разработчики заботятся о переносимости и взаимодействии с другими системами управления версиями.
-Расширение bzr-git позволяет пользователям Bazaar до некоторой степени работать с репозиториями Git. Программа tailor конвертирует хранилища Bazaar в Git и может делать это инкрементно, тогда как bzr-fast-export хорошо приспособлена для разовых преобразований.
+Расширение bzr-git позволяет (в какой-то степени) пользователям Bazaar работать с хранилищами Git. Программа tailor конвертирует хранилища Bazaar в Git и может делать это с накоплением, тогда как bzr-fast-export хорошо приспособлена для разовых преобразований.
=== Почему я использую Git ===
-Изначально я выбрал Git потому, что слышал, что он в состоянии справиться с невообразимо неуправляемыми исходными текстами ядра Linux. Я никогда не ощущал потребности сменить его на что-то другое. Git работает замечательно и мне еще только предстоит напороться на его недостатки. Так как я в основном использую Linux, проблемы на других системах меня не касаются.
+Изначально я выбрал Git потому, что слышал, что он в состоянии справиться с совершенно неуправляемыми исходными текстами ядра Linux. Я никогда не ощущал потребности сменить его на что-то другое. Git работает замечательно и мне еще только предстоит напороться на его недостатки. Так как я в основном использую Linux, проблемы на других системах меня не касаются.
Я также предпочитаю программы на C и сценарии на bash исполняемым файлам вроде сценариев на Python-е: у них меньше зависимостей, и я привык к быстрому выполнению.
-Я думал о том, как можно улучшить Git, вплоть до того, чтобы написать собственный инструмент, похожий на Git, но только как академическое упражнение. Завершив проект, я бы все равно продолжил пользоваться Git, потому что выигрыш слишком мал, чтобы оправдать использование самодельной системы.
+Я думал о том, как можно улучшить Git, вплоть до того, чтобы написать собственный инструмент, похожий на Git; но только как академическое упражнение. Завершив проект, я бы все равно продолжил пользоваться Git, потому что выигрыш слишком мал, чтобы оправдать использование самодельной системы.
Естественно, ваши потребности и пожелания вероятно отличаются от моих и вы, возможно, лучше уживетесь с другой системой. И всё же вы не слишком ошибетесь, используя Git.
View
10 ru/drawbacks.txt
@@ -4,7 +4,7 @@
=== Слабости SHA1 ===
-Со временем криптографы обнаруживают всё больше и больше слабостей в SHA1. Уже сейчас обнаружение коллизий хешей осуществимо для хорошо финансируемой организации. Спустя годы, возможно, даже типичный ПК будет иметь достаточную вычислительную мощность, чтобы незаметно испортить Git хранилище.
+Со временем криптографы обнаруживают всё больше и больше слабостей в SHA1. Уже сейчас обнаружение коллизий хешей осуществимо для хорошо финансируемой организации. Спустя годы, возможно, даже типичный ПК будет иметь достаточную вычислительную мощность, чтобы незаметно испортить хранилище Git.
Надеюсь, Git перейдет на лучшую хеш-функцию прежде чем дальнейшие исследования уничтожат SHA1.
@@ -14,11 +14,11 @@ Git на Microsoft Windows может быть громоздким:
- http://cygwin.com/[Cygwin], Linux-подобная среда для Windows, содержащая http://cygwin.com/packages/git/[порт Git на Windows].
-- http://code.google.com/p/msysgit/[Git на MSys] вариант, требующий минимальной рантайм поддержки, хотя некоторые комманды нуждаются в доработке.
+- http://code.google.com/p/msysgit/[Git на MSys], вариант, требующий минимальной рантайм поддержки, хотя некоторые комманды нуждаются в доработке.
=== Несвязанные файлы ===
-Если ваш проект очень велик и содержит много не связанных файлов, которые постоянно изменяются, Git может оказаться в невыгодном положении по сравнению с другими системами, поскольку отдельные файлы не отслеживаются. Git отслеживает изменения всего проекта, что обычно бывает выгодным.
+Если ваш проект очень велик и содержит много несвязанных файлов, которые постоянно изменяются, Git может оказаться в невыгодном положении по сравнению с другими системами, поскольку отдельные файлы не отслеживаются. Git отслеживает изменения всего проекта, что обычно бывает выгодным.
Решение — разбить проект на части, каждая из которых состоит из взаимосвязанных файлов. Используйте *git submodule* если вы все же хотите держать все в одном хранилище.
@@ -46,7 +46,7 @@ Git на Microsoft Windows может быть громоздким:
=== Изменчивые Проекты ===
-Git была написан, чтобы быть быстрым при относительно небольших изменениях. Люди вносят незначительные правки от версии к версии. Однострочные исправление ошибки здесь, новая функция там, исправленные комментарии и тому подобное. Но если ваши файлы радикально различаются в соседних ревизиях, то с каждым коммитом ваша история неизбежно увеличится на размер всего проекта.
+Git был написан, чтобы быть быстрым при относительно небольших изменениях. Люди вносят незначительные правки от версии к версии. Однострочное исправление ошибки здесь, новая функция там, исправленные комментарии и тому подобное. Но если ваши файлы радикально различаются в соседних ревизиях, то с каждым коммитом ваша история неизбежно увеличится на размер всего проекта.
Никакая система управления версиями ничего не может с этим сделать, но пользователи Git страдают больше, поскольку обычно истории клонируются.
@@ -66,7 +66,7 @@ Git была написан, чтобы быть быстрым при отно
Но некоторым людям нравятся эти целые числа повсюду. К счастью, легко написать такой скрипт, чтобы при каждом обновлении центральное хранилище Git увеличивало целое число, возможно, в теге, и связывало его с хешем последнего коммита.
-Каждай клон может поддерживать такой счетчик, но это, видимо, будет бесполезным, поскольку только центральное хранилище и его счетчик имеет значение для всех.
+Каждый клон может поддерживать такой счетчик, но это, видимо, будет бесполезным, поскольку только центральное хранилище и его счетчик имеет значение для всех.
=== Пустые подкаталоги ===
View
4 ru/history.txt
@@ -61,7 +61,7 @@ Git учитывает оба мнения. Переписывание исто
=== Переписывая историю ===
-Время от времени вам может понадобиться в системе управления версиями аналог «замазывания» людей на официальных фотографиях, как бы стирая их из истории в духе сталинизма. Например, предположим, что мы уже собираемся выпустить релиз проекта, но он содержит файл, который не должен стать достоянием общественности по каким-то причинам. Возможно, я сохранил номер своей кредитки в текстовый файл и случайно добавил его в проект. Удалить файл недостаточно: он может быть доступен из старых коммитов. Нам надо удалить файл из всех ревизий:
+Время от времени вам может понадобиться в системе управления версиями аналог «замазывания» людей на официальных фотографиях, как бы стирающего их из истории в духе сталинизма. Например, предположим, что мы уже собираемся выпустить релиз проекта, но он содержит файл, который не должен стать достоянием общественности по каким-то причинам. Возможно, я сохранил номер своей кредитки в текстовый файл и случайно добавил его в проект. Удалить файл недостаточно: он может быть доступен из старых коммитов. Нам надо удалить файл из всех ревизий:
$ git filter-branch --tree-filter 'rm совершенно/секретный/файл' HEAD
@@ -171,4 +171,4 @@ Git извлечет состояние ровно посередине. Про
Когда мне было нужно запустить медленную команду, нарушение хода моих мыслей оказывало несоизмеримый ущерб разработке. Ожидая окончания связи с сервером, я вынужден был заниматься чем-то другим, чтобы скоротать время; например, проверкой почты или написанием документации. К тому времени, как я возвращался к первоначальной задаче, выполнение команды было давно закончено, но мне приходилось тратить уйму времени, чтоб вспомнить, что именно я делал. Люди не очень приспособлены для переключения между задачами.
-Кроме того, есть интересный эффект «трагедии общественных ресурсов»: предвидя будущую перегруженность сети, некоторые люди в попытке предотвратить будущие задержки начинают использовать более широкие каналы, чем им реально требуется для текущих задач. Суммарная активность увеличивает загрузку сети, поощряя людей задействовать всё более высокоскоростные каналы для предотвращения еще больших задержек.
+Кроме того, есть интересный эффект «трагедии общественных ресурсов»: предвидя будущую перегруженность сети, некоторые люди в попытке предотвратить грядущие задержки начинают использовать более широкие каналы, чем им реально требуется для текущих задач. Суммарная активность увеличивает загрузку сети, поощряя людей задействовать всё более высокоскоростные каналы для предотвращения еще больших задержек.
View
4 ru/intro.txt
@@ -12,7 +12,7 @@
=== Управление версиями ===
-Во время редактирования вы можете «Сохранить как…» в другой файл, или скопировать файл куда-нибудь перед сохранением, чтобы уберечь более старые версии. Может быть, заархивировав их для экономии места на диске. Это самый примитивный вид управления версиями, к тому же требующий интенсивной ручной работы. Компьютерные игры прошли этот этап давным-давно, в большинстве из них есть множество слотов для сохранения с автоматическими временными метками.
+Во время редактирования вы можете «Сохранить как…» в другой файл, или скопировать файл куда-нибудь перед сохранением, чтобы уберечь более старые версии. Может быть, заархивировав их для экономии места на диске. Это самый примитивный вид управления версиями, к тому же требующий интенсивной ручной работы. Компьютерные игры прошли этот этап давным-давно, в большинстве из них есть множество слотов для сохранения с автоматическими временны́ми метками.
Давайте немного усложним условия. Пусть у вас есть несколько файлов, используемых вместе, например, исходный код проекта или файлы для вебсайта. Теперь, чтобы сохранить старую версию, вы должны скопировать весь каталог. Поддержка множества таких версий вручную неудобна и быстро становится дорогим удовольствием.
@@ -40,7 +40,7 @@
Широко распространенное заблуждение состоит в том, что распределенные системы непригодны для проектов, требующих официального централизованного хранилища. Ничто не может быть более далеким от истины. Получение фотоснимка не приводит к тому, что мы крадем чью-то душу. Точно так же клонирование главного хранилища не уменьшает его важность.
-В первом приближении можно сказать, что все, что делает централизованная система управления версиями, хорошо сконструированная распределенная система может сделать лучше. Сетевые ресурсы просто дороже локальных. Хотя дальше мы увидим, что в распределенном подходе есть свои недостатки, вы вряд ли ошибетесь при сравнении, руководствуясь этим приближенным правилом.
+В первом приближении можно сказать, что все, что делает централизованная система управления версиями, хорошо сконструированная распределенная система может сделать лучше. Сетевые ресурсы просто дороже локальных. Хотя дальше мы увидим, что в распределенном подходе есть свои недостатки, вы вряд ли ошибетесь в выборе, руководствуясь этим приближенным правилом.
Небольшому проекту может понадобиться лишь частица функционала, предлагаемого такой системой. Но использование плохо масштабируемой системы для маленьких проектов подобно использованию римских цифр в расчетах с небольшими числами.
View
9 ru/multiplayer.txt
@@ -64,10 +64,9 @@ hooks/post-update
$ git tag -f последний-пакет HEAD
-и создавайте обновления пакеты с помощью
+и создавайте обновленные пакеты с помощью
- $ git bundle create новый-пакет HEAD
-^последний-пакет
+ $ git bundle create новый-пакет HEAD ^последний-пакет
=== Патчи: общее применение ===
@@ -91,7 +90,7 @@ hooks/post-update
$ git format-patch 1b6d..HEAD^^
-На принимающей стороне сохраните email в файл и введите:
+На принимающей стороне сохраните письмо в файл и введите:
$ git am < email.txt
@@ -170,7 +169,7 @@ other/некая_ветка~5
=== Мои Настройки ===
-Я предпочитаю, чтобы люди, присоединяющиеся к моим проектам, создавали хранилища, из которых я смогу получать изменения с помощью pull. Некоторые Git хостинги позволяют создавать собственные форки проекта в одно касание.
+Я предпочитаю, чтобы люди, присоединяющиеся к моим проектам, создавали хранилища, из которых я смогу получать изменения с помощью pull. Некоторые хостинги Git позволяют создавать собственные форки проекта в одно касание.
После получения дерева из удаленного хранилища я запускаю команды Git для навигации и изучения изменений, в идеале хорошо организованных и описанных. Я делаю слияние со своими изменения и возможно вношу дальнейшие правки. Когда я доволен результатом, я заливаю изменения в главное хранилище.
View
10 ru/preface.txt
@@ -14,9 +14,9 @@ Ben Lynn
http://git.or.cz/[Git] это швейцарский нож управления версиями — надежный универсальный многоцелевой инструмент, чья черезвычайная гибкость делает его сложным в изучении даже для многих профессионалов.
-Как говорил Артур Кларк, любая достаточно развитая технология неотличима от волшебства. Это отличный подход к Git: новички могут игнорировать принципы его внутренней работы и рассматривать Git как нечто, которое может восхищать друзей и приводить в бешенство врагов своими чудесными способностями.
+Как говорил Артур Кларк, любая достаточно развитая технология неотличима от волшебства. Это отличный подход к Git: новички могут игнорировать принципы его внутренней работы и рассматривать Git как нечто восхищающее друзей и приводящее в бешенство врагов своими чудесными способностями.
-Вместо того, чтобы вдаваться в подробности, мы предоставляем приблизительные инструкции для получения конкретных результатов. При частом использовании вы постепенно поймете, как работает каждый трюк и как приспосабливать рецепты под ваши нужды.
+Вместо того, чтобы вдаваться в подробности, мы предоставим приблизительные инструкции для получения конкретных результатов. При частом использовании вы постепенно поймете, как работает каждый трюк и как приспосабливать рецепты под ваши нужды.
.Переводы
@@ -29,8 +29,8 @@ http://git.or.cz/[Git] это швейцарский нож управления
.Другие варианты
- - link:book.html[HTML одной страницей]: чистый HTML без CSS.
- - link:book.pdf[PDF файл]: для печати.
+ - link:book-ru.html[HTML одной страницей]: чистый HTML без CSS.
+ - link:book-ru.pdf[PDF файл]: для печати.
- http://packages.debian.org/gitmagic[Пакет Debian], http://packages.ubuntu.com/gitmagic[пакет Ubuntu]: получите локальную копию этого сайта. Придется кстати, http://csdcf.stanford.edu/status/[если этот сервер будет недоступен].
=== Благодарности ===
@@ -57,7 +57,7 @@ François Marier сопровождает пакет Debian, изначальн
Это руководство выпущено под http://www.gnu.org/licenses/gpl-3.0.html[GNU General Public License 3-й версии]. Естественно, исходный текст находится в хранилище Git и может быть получен командой:
- $ git clone git://repo.or.cz/gitmagic.git # Создает каталог "gitmagic".
+ $ git clone git://repo.or.cz/gitmagic.git # Создаст каталог "gitmagic".
или с одного из зеркал:
View
4 ru/secrets.txt
@@ -18,7 +18,7 @@ SHA1 хеш можно рассматривать как уникальный 16
Так как SHA1 хеш сам является последовательностью байтов, мы можем получить хеш строки байтов, содержащей другие хеши. Это простое наблюдение на удивление полезно: ищите «hash chains» (цепочки хешей). Позднее мы увидим, как Git использует их для эффективного обеспечения целостности данных.
-Говоря кратко, Git хранит ваши данные в подкаталоге ".git/objects", где вместо нормальных имен файлов вы найдете только идентификаторы. Благодаря использованию идентификаторов в качестве имен файлов, а также некоторым хитростям с файлами блокировок и временными метками, Git преобразует любую скромную файловую систему в эффективную и надежную базу данных.
+Говоря кратко, Git хранит ваши данные в подкаталоге ".git/objects", где вместо нормальных имен файлов вы найдете только идентификаторы. Благодаря использованию идентификаторов в качестве имен файлов, а также некоторым хитростям с файлами блокировок и временны́ми метками, Git преобразует любую скромную файловую систему в эффективную и надежную базу данных.
=== Интеллект ===
@@ -145,7 +145,7 @@ SHA1 хеш его содержимого:
=== Неотличимо от волшебства ===
-Секреты Git выглядят слишком простыми. Похоже, что вы могли бы объединить несколько shell-скриптов и добавить немного кода на C, чтобы сделать всё это в считанные часы: смесь базовых операций с файлами и SHA1-хеширование, приправленная блокировочными файлами и fsync для надеждности. По сути, это точное описание ранних версий Git. Тем не менее, помимо гениальных трюков с упаковкой для экономии места и с индексацией для экономии времени, мы теперь знаем, как ловко Git преображает файловую систему в базу данных, идеально подходящую для управления версиями.
+Секреты Git выглядят слишком простыми. Похоже, что вы могли бы объединить несколько shell-скриптов и добавить немного кода на C, чтобы сделать всё это в считанные часы: смесь базовых операций с файлами и SHA1-хеширования, приправленная блокировочными файлами и fsync для надеждности. По сути, это точное описание ранних версий Git. Тем не менее, помимо гениальных трюков с упаковкой для экономии места и с индексацией для экономии времени, мы теперь знаем, как ловко Git преображает файловую систему в базу данных, идеально подходящую для управления версиями.
Например, если какой-либо файл в базе данных объектов поврежден из-за ошибки диска, то его хеш теперь не совпадет, что привлечет наше внимание к проблеме. С помощью хеширования хешей других объектов, мы поддерживаем целостность на всех уровнях. Коммиты атомарны, так что в них никогда нельзя записать лишь часть изменений: мы можем вычислить хеш коммита и сохранить его в базу данных только сохранив все соответствующие деревья, блобы и родительские коммиты. База данных объектов нечувствительна к непредвиденным прерываниям работы, таких как перебои с питанием.
View
4 ru/translate.txt
@@ -3,7 +3,7 @@
Я советую следующий способ для перевода этого руководства, чтобы мои скрипты могли быстро создавать HTML и PDF версии, а все переводы находились в одном хранилище.
Клонируйте исходные тексты, затем создайте каталог, отвечающий тегу IETF целевого языка: смотрите
-http://www.w3.org/International/articles/language-tags/Overview.en.php[статью W3C по интернационализации]. К примеру, английский язык это «en», а японский — «ja». Скопируйте в каталог файлы +txt+ из "en" каталога и переведите их.
+http://www.w3.org/International/articles/language-tags/Overview.en.php[статью W3C по интернационализации]. К примеру, английский язык это «en», а японский — «ja». Скопируйте в каталог файлы +txt+ из каталога «en» и переведите их.
К примеру, для перевода руководства на http://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B8%D0%BD%D0%B3%D0%BE%D0%BD%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA[клингонский язык], вы можете набрать:
@@ -18,7 +18,7 @@ http://www.w3.org/International/articles/language-tags/Overview.en.php[стат
Отредактируйте Makefile и добавьте код языка в переменную TRANSLATIONS. Теперь вы сможете просматривать вашу работу по ходу дела:
- $ make LANG=tlh
+ $ make tlh
$ firefox book.html
Почаще делайте коммиты, а когда ваш перевод будет готов, сообщите мне об этом. На GitHub есть веб-интерфейс, облегчающий описанные действия: сделайте форк проекта «gitmagic», залейте ваши изменения и попросите меня сделать слияние.
View
8 vi/README
@@ -1,9 +1,9 @@
-This project translate GitMagic ebook into Vietnamese.
+This project translate GitMagic ebook into Vietnamese.
License: GPL-3
-Copyleft: 2010-2011 GitMagic-vi team.
+Copyleft: 2010-2011 GitMagic team.
First transalted by: Trần Ngọc Quân.
-Personal website: vnwildman.sourceforge.net
-Project's SCM address: git://github.com/vnwildman/gitmagic-vi.git
+Personal website: vnwildman.users.sourceforge.net
+Project's SCM address: https://github.com/vnwildman/gitmagic.git
Special thanks:
-Clytie Siddall.
View
58 vi/basic.txt
@@ -4,41 +4,41 @@ Thay vì lao vào cả một biển lệnh với Git, bạn hãy sử dụng cá
Mặc dù chúng rất đơn giản, nhưng tất cả chúng đều rất hữu dụng.
Quả thực là vậy, trong tháng đầu tiên sử dụng Git tôi chưa bao giờ vượt qua những gì nói trong chương này.
-=== Ghi lại State ===
+=== Ghi lại Trạng thái ===
-Bạn muốn thử một số lệnh gì đó với Git? Trước khi làm điều đó, thực hiện các lệnh sau
+Bạn muốn thử thực hiện một số lệnh gì đó với Git? Trước khi làm điều đó, thực hiện các lệnh sau
trong thư mục hiện hành chứa các mã nguồn hay văn bản mà bạn muốn quản lý:
$ git init
$ git add .
$ git commit -m "Bản sao lưu đầu tiên"
-Bây giờ nếu như các sửa đổi của bạn không như mong đợi, hãy phục hồi lại bản cũ (bản cuối cùng bạn commit):
+Bây giờ nếu như các sửa đổi vừa xong của bạn không như mong đợi, hãy phục hồi lại bản cũ:
- $ git reset --hard
+ $ git reset --hard # Đặt lại trạng thái và dữ liệu như lần commit cuối
-Lưu lại state lần nữa:
+Sau đó sửa nội dung cho đúng ý bạn rồi ghi lại thành một trạng thái mới:
$ git commit -a -m "Bản sao lưu khác"
-=== Thêm, Xóa, Đổi tên ===
+=== Thêm, Xóa, Đổi Tên ===
-Lệnh ở trên chỉ giữ dấu vết các tệp tin hiện diện tại thời điểm bạn chạy lệnh *git add*. Nếu bạn thêm các tệp tin hay thư mục, thì bạn sẽ phải thông báo với Git:
+Lệnh ở trên chỉ giữ dấu vết các tệp tin hiện diện tại thời điểm bạn chạy lệnh *git add*. Nếu bạn thêm các tệp tin hay thư mục, thì bạn sẽ phải thông báo với Git:
$ git add readme.txt Documentation
Tương tự như vậy, nếu bạn muốn Git bỏ đi các tệp tin nào đó:
$ git rm kludge.h obsolete.c
- $ git rm -r incriminating/evidence/
+ $ git rm -r incriminating/evidence/ #gỡ bỏ một cách đệ qui
Git xóa bỏ những tệp tin nếu như bạn chưa làm.
-Đổi tên tệp tin thì cũng giống như là việc bạn gỡ bỏ tên cũ và đặt vào nó cái tên mới. Sử dụng lệnh *git mv* có cú pháp rất giống lệnh *mv*. Ví dụ:
+Đổi tên tệp tin thì cũng giống như là việc bạn gỡ bỏ tên cũ và đặt vào nó cái tên mới. Sử dụng lệnh *git mv* có cú pháp rất giống lệnh *mv* của hệ thống Linux. Ví dụ:
$ git mv bug.c feature.c
-=== Chức Năng Undo/Redo ===
+=== Chức Năng Undo/Redo ===
Đôi khi bạn chỉ muốn quay trở lại và bỏ đi những thay đổi trong quá khứ tại một thời điểm nào đó bởi vì chúng tất cả đã sai. Thì lệnh:
@@ -61,19 +61,19 @@ Date: Thu Jan 1 00:00:00 1970 +0000
----------------------------------
Chỉ vài ký tự của giá trị băm là đủ để chỉ ra một commit cụ thể;
-một cách khác là chép (copy) và dán (paste) giá trị băm. Gõ:
+một cách khác là chép và dán giá trị băm. Gõ:
$ git reset --hard 766f
-để phục hồi lại state đã được chỉ ra và xóa bỏ tất cả các lần commit mới hơn kể từ đó.
+để phục hồi lại trạng thái đã được chỉ ra và xóa bỏ tất cả các lần commit mới hơn kể từ đó.
Một lúc nào đó bạn lại muốn nhảy tới một bản cũ hơn. Trong trường hợp này thì gõ:
$ git checkout 82f5
-Nó giúp bạn quay lại đúng thời điểm đó, trong khi vẫn giữ lại những lần commit mới hơn. Tuy nhiên, giống như cỗ máy thời gian trong các bộ phim khoa học viễn tưởng, nếu bây giờ bạn sửa sau đó commit, bạn sẽ ở trong một thực tại khác, bởi vì hành động của bạn bây giờ đã khác với lúc chúng trong lần đầu tiên ở tại đây.
+Nó giúp bạn quay lại đúng thời điểm đó, trong khi vẫn giữ lại những lần commit mới hơn. Tuy nhiên, giống như cỗ máy thời gian trong các bộ phim khoa học viễn tưởng, nếu bây giờ bạn sửa sau đó commit, bạn sẽ ở trong một thực tại khác, bởi vì hành động của bạn bây giờ đã khác với khi chúng ta lần đầu tiên ở tại đây.
-Có cách thực tế hơn là sử dụng 'branch', và <<branch, chúng ta có nhiều điều để nói về nó sau này>>. Bây giờ, chỉ cần nhớ là
+Có cách thực tế hơn là sử dụng 'branch', và <<branch, chúng ta có nhiều điều để nói về nó sau này>>. Bây giờ, chỉ cần nhớ là:
$ git checkout master
@@ -84,9 +84,9 @@ Sự tương đồng với game trên máy tính:
- *`git reset --hard`*: lấy cái cũ đã được lưu lại và xóa tất cả các games mới hơn cái vừa lấy.
-- *`git checkout`*: lấy một cái cũ, nhưng chỉ chơi với nó, state của game sẽ tách riêng về phía mới hơn chỗ mà bạn đã ghi lại lần đầu tiên. Bất kỳ game nào bạn tạo từ bây giờ sẽ là bản cuối cùng trong nhánh riêng rẽ tương ứng với một thực tại khác mà bạn đã gia nhập vào. <<branch, chúng tôi sẽ nói sau>>.
+- *`git checkout`*: lấy một cái cũ, nhưng chỉ chơi với nó, trạng thái của game sẽ tách riêng về phía mới hơn chỗ mà bạn đã ghi lại lần đầu tiên. Bất kỳ game nào bạn tạo từ bây giờ sẽ là bản cuối cùng trong nhánh riêng rẽ tương ứng với một thực tại khác mà bạn đã gia nhập vào. <<branch, chúng tôi sẽ nói sau>>.
-Bạn có thể chọn chỉ phục hồi lại các tệp tin hay thư mục bạn muốn bằng cách thêm vào vào phần sau của câu lệnh:
+Bạn có thể chọn chỉ phục hồi lại các tệp tin hay thư mục bạn muốn bằng cách thêm vào chúng vào phần sau của câu lệnh:
$ git checkout 82f5 some.file another.file
@@ -99,7 +99,7 @@ Bạn không thích việc cắt dán ư? Hãy sử dụng:
$ git checkout :/"My first b"
để nhảy tới lần commit mà phần chú thích của nó bắt đầu với chuỗi bạn đã cho.
-Bạn cũng có thể yêu cầu state thứ 5 kể từ lần cuối:
+Bạn cũng có thể yêu cầu trạng thái thứ 5 kể từ cái cuối cùng:
$ git checkout master~5
@@ -113,12 +113,12 @@ Trong một phiên tòa, mỗi sự kiện được gắn với một bản ghi.
sẽ chỉ undo lần commit với giá trị băm đã chỉ ra. Sự quay trở lại được ghi nhận như là một lần
commit mới, bạn có thể xác nhận lại điều này bằng lệnh *git log*.
-=== Tạo Changelog ===
+=== Tạo Nhật Ký các thay đổi ===
Một số dự án yêu cầu có một http://en.wikipedia.org/wiki/Changelog[changelog].
Tạo một cái bằng cách gõ:
- $ git log > ChangeLog
+ $ git log > ThayĐổi
=== Tải về các Tệp tin ===
@@ -126,7 +126,7 @@ Lấy về một bản sao của một dự án quản lý bằng Git bằng cá
$ git clone git://server/path/to/files
-Ví dụ, để lấy tất cả các tệp tin mà tôi đã dùng để tạo ra cho trang này là:
+Ví dụ, để lấy tất cả các tệp tin mà tôi đã dùng để tạo ra cho quyển sách này là:
$ git clone git://git.or.cz/gitmagic.git
@@ -138,9 +138,9 @@ Nếu bạn đã tải về một bản sao của một dự án bằng lệnh *
$ git pull
-=== Xuất bản ===
+=== Xuất Bản ===
-Giả sử bạn đã tạo được script và bạn muốn chia sẻ nó với người khác. Bạn có thể bảo họ tải về từ máy tính của mình, nhưng nếu họ làm như thế trong khi bạn đang cải tiến script hay có những thay đổi mang tính thử nghiệm, họ có thể gặp trục trặc. Dĩ nhiên, đây là lý do tại sao mà chu kỳ phát hành phần mềm lại tồn tại phải không nào. Những người phát triển có thể làm việc thường xuyên trên một dự án, nhưng họ chỉ xuất bản những đoạn mã mà họ cảm thấy nó có thể dùng được để tránh ảnh hưởng đến người khác.
+Giả sử bạn đã tạo được một kho Git và bạn muốn chia sẻ nó với người khác. Bạn có thể bảo họ tải về từ máy tính của mình, nhưng nếu họ làm như thế trong khi bạn đang cải tiến hay có những thay đổi mang tính thử nghiệm, họ có thể gặp trục trặc. Dĩ nhiên, đây là lý do tại sao mà chu kỳ phát hành phần mềm lại tồn tại phải không nào. Những người phát triển có thể làm việc thường xuyên trên một dự án, nhưng họ chỉ xuất bản những đoạn mã mà họ cảm thấy nó có thể dùng được để tránh ảnh hưởng đến người khác.
Thực hiện điều này với Git, trong thư mục làm việc của Git:
@@ -152,7 +152,7 @@ Sau đó nói với những người cùng sử dụng hãy chạy:
$ git clone your.computer:/path/to/script
-để tải script về. Giả định là họ truy cập thông qua ssh. Nếu không, chạy *git daemon* và nói với người sử dụng là chạy lệnh sau để thay thế:
+để tải dữ liệu về. Giả định là họ truy cập thông qua ssh. Nếu không, chạy *git daemon* và nói với người sử dụng là chạy lệnh sau để thay thế:
$ git clone git://your.computer/path/to/script
@@ -164,9 +164,9 @@ và những người sử dụng có thể cập nhật dữ liệu của họ b
$ git pull
-Những người sử dụng sẽ không bao giờ thấy được script cuối cùng của bạn mà bạn không muốn họ thấy.
+Những người sử dụng sẽ không bao giờ thấy được dữ liệu cuối cùng của bạn mà bạn không muốn họ thấy.
-=== Tôi Đã Làm Gì? ===
+=== Tôi Đã Làm Được Gì? ===
Tìm tất cả các thay đổi kề từ lần bạn commit lần cuối bằng lệnh:
@@ -180,14 +180,14 @@ Hay giữa một bản nào đó và bản trước đây 2 bản:
$ git diff 1b6d "master~2"
-Trong từng trường hợp, đầu ra là một bảncái mà có thể được áp dụng với *git apply*.
-Try also:
+Trong từng trường hợp, đầu ra là một miếng vá mà có thể được sử dụng với lệnh *git apply*.
+Cũng có thể dùng lệnh:
$ git whatchanged --since="2 weeks ago"
Thường thường, tôi duyệt lịch sử bằng http://sourceforge.net/projects/qgit[qgit] để thay thế cách ở trên, bởi vì nó có giao diện đồ họa bóng bẩy, hay http://jonas.nitro.dk/tig/[tig], có giao diện dòng lệnh làm việc rất tốt với các máy có kết nối mạng chậm. Một lựa chọn khác là cài đặt máy chủ web, chạy lệnh *git instaweb* và sử dụng bất kỳ trình duyệt web nào.
-=== Bài Tập ===
+=== Bài Tập===
Coi A, B, C, D là 4 lần commit thành công, nơi mà B giống A ngoại trừ một số tệp tin bị xóa bỏ. Chúng ta muốn thêm các tệp tin đó trở lại D. Chúng ta thực hiện điều này bằng cách nào?
@@ -197,7 +197,7 @@ Coi A, B, C, D là 4 lần commit thành công, nơi mà B giống A ngoại tr
$ git diff B A | git apply
- 2. Kể từ lúc chúng ta ghi lại các tệp tin tại A, chúng ta có thể lấy lại:
+ 2. Kể từ sau khi chúng ta ghi lại các tệp tin tại A trở đi, chúng ta có thể lấy lại:
$ git checkout A foo.c bar.h
View
38 vi/branch.txt
@@ -2,17 +2,17 @@
Tạo Nhánh và Trộn là các đặc tính sát thủ của Git.
-*Vấn đề*: Những nhân tố bên ngoài chắc hẳn có đòi hỏi việc hoán chuyển nội dung. Một lỗi tồi tệ
+*Vấn đề đặt ra*: Những nhân tố bên ngoài chắc hẳn có đòi hỏi việc hoán chuyển văb cảnh. Một lỗi tồi tệ
xuất hiện trong phiên bản đã được phát hành mà không được cảnh báo gì. Điều tồi tệ nhất có thể xảy ra
-là phải xóa bỏ hẳn đặc tính kỹ thuật đó. Người phát triển phần mềm, người mà đã giúp bạn viết nó, cần biết lý do về việc bãi bỏ. Trong tất cả các trường hợp, bạn đột ngột phải xóa bỏ cái mà bạn đang làm và nhắm hoàn toàn vào một nhiệm vụ khác.
+là phải xóa bỏ hẳn đặc tính kỹ thuật đó. Người phát triển phần mềm, người mà đã giúp bạn viết nó, cần biết lý do về việc bãi bỏ. Trong tất cả các trường hợp, bạn buộc phải xóa bỏ cái mà bạn đang làm và làm một cái hoàn toàn mới.
-Việc gán đoạn suy nghĩ có thể làm giảm hiệu suất làm việc của bạn, và việc hoán chuyển nội dung càng cồng kềnh vướng víu càng tổn thất. Đối với các hệ thống quản lý mã nguồn tập trung chúng ta phải tải về một bản sao công việc mới từ máy chủ trung tâm. Các hệ thống phân tán hoạt động hiệu quả hơn, như là chúng ta có thể nhân bản một cách cục bộ.
+Việc gán đoạn suy nghĩ có thể làm giảm hiệu suất làm việc của bạn, và việc hoán chuyển nội dung càng cồng kềnh vướng víu càng gây hậu quả nặng nề. Đối với các hệ thống quản lý mã nguồn tập trung chúng ta phải tải về một bản sao công việc mới từ máy chủ trung tâm. Các hệ thống phân tán hoạt động hiệu quả hơn, như là chúng ta có thể nhân bản một cách cục bộ.
Nhưng việc nhân bản bắt buộc phải sao chép toàn bộ thư mục làm việc cũng như là toàn bộ các mục trong lịch sử cho đến thời điểm đã được chỉ ra. Dù là Git giảm bớt sự lãng phí cho việc này bằng cách chia sẻ và tạo ra các liên kết tệp tin cứng, chính bản thân các tệp tin dự án cũng phải được tạo ra trong các đề mục của chúng trong thư mục làm việc.
-*Giải pháp*: Git có một công cụ tốt hơn để sử lý tình huống này, nó nhanh và tiết kiệm không gian lưu trữ hơn lệnh nhân bản: *git branch*.
+*Giải pháp*: Git có một công cụ tốt hơn để sử lý tình huống này, nó nhanh và tiết kiệm không gian lưu trữ hơn lệnh nhân bản đó chính là: *git branch*.
-Với vài câu thần chú, các tệp tin trong thư mục của bạn dễ dàng biến đổi từ phiên bản này sang phiên bản khác. Sự chuyển đổi này có thể làm nhiều hơn việc quay lại hay chuyển tiếp trong lịch sử một các đơn thuần. Các tệp tin của bạn có thể chuyển hình thái từ bản phát hành cuối thành phiên bản thử nghiệm, thành phiên bản phát triển hiện hành, thành phiên bản của người bạn của bạn, và cứ như thế.
+Với vài câu thần chú, các tệp tin trong thư mục của bạn dễ dàng biến đổi từ phiên bản này sang phiên bản khác. Sự chuyển đổi này có thể làm nhiều hơn việc di chuyển trong trong lịch sử một các đơn thuần. Các tệp tin của bạn có thể chuyển hình thái từ bản phát hành cuối thành phiên bản thử nghiệm, thành phiên bản phát triển hiện hành, thành phiên bản của người bạn của bạn, và cứ như thế.
=== Nút Điều Khiển ===
@@ -23,12 +23,12 @@ Mỗi khi chơi trò chơi, bạn bấm vào nút (``nút điều khiển''), m
$ echo "Tôi thông minh hơn xếp của mình" > myfile.txt
$ git init
$ git add .
- $ git commit -m "Lần commit bắt đầu"
+ $ git commit -m "Lần commit đầu tiên"
Chúng ta đã tạo ra kho chứa Git mà nó theo dõi một tệp tin văn bản có chứa một thông điệp đã biết trước. Giờ hãy gõ:
$ git checkout -b boss # dường như chẳng có gì thay đổi sau lệnh này
- $ echo "Ông chủ thông minh hơn tôi" > myfile.txt
+ $ echo "Xếp thông minh hơn tôi" > myfile.txt
$ git commit -a -m "Lần commit khác"
Điều này cũng giống như việc chúng ta ghi đè lên tệp tin của mình sau đó commit nó. Nhưng không, đó chỉ là ảo tưởng. Gõ:
@@ -41,7 +41,7 @@ Chúng ta đã tạo ra kho chứa Git mà nó theo dõi một tệp tin văn b
Bạn có thể hoán chuyển giữa hai phiên bản của tệp tin tùy thích, và commit từng cái trong số chúng một cách độc lập.
-=== Dirty Work ===
+=== Bản Nháp ===
[[branch]]
Bạn nói mình đang làm việc với một số đặc tính kỹ thuật, và vì lý do nào đó, bạn muốn quay trở lại bản cách đây ba bản và tạm thời đặt vài dòng lệnh
@@ -50,7 +50,7 @@ in ra màn hình để có thể thấy được một số hàm hoạt động
$ git commit -a
$ git checkout HEAD~3
-Giờ thì bạn có thể thêm những dòng code tạm thời ở đâu mình muốn. Bạn còn có thể commit những thay đổi đó. Khi bạn đã làm xong,
+Giờ thì bạn có thể thêm những dòng mã lệnh tạm thời ở đâu mình muốn. Bạn còn có thể commit những thay đổi đó. Khi bạn đã làm xong, hãy thực hiện lệnh
$ git checkout master
@@ -77,10 +77,10 @@ Bạn đang phân vân giữa ngã ba đường khi bạn phải xác định l
Một khi bạn đã sửa lỗi:
- $ git commit -a -m "Sửa lỗi"
+ $ git commit -a -m "Đã sửa"
$ git checkout master
-và phục hồi lại công việc theo phận sự của mình. Bạn thậm chí có thể trộn với lần commit đã sửa để
+và quay lại công việc theo phận sự của mình. Bạn thậm chí có thể trộn với lần commit đã sửa để
sửa lỗi:
$ git merge fixes
@@ -105,9 +105,9 @@ có thể có nhiều cha, thế thì chúng ta phải theo cái nào?
Nó sẽ gọi ra 'cha' đầu tiên. Đây là
điều ta mong muốn bởi vì nhánh hiện hành trở thành cha đầu tiên trong suốt quá trình trộn;
một cách thường xuyên, bạn chỉ liên quan đến những thay đổi mình tạo ra trong nhánh
-hiện hành , cốt để mà đối lập với việc trộn thay đổi từ các nhánh khác.
+hiện hành, cốt để mà đối lập với việc trộn thay đổi từ các nhánh khác.
-Bạn hãy quy một cha nào đó với một dấu mũ. Ví dụ, để hiển thị
+Bạn hãy nhớ Git quy một cha nào đó với một dấu mũ. Ví dụ, để hiển thị
nhật ký tính từ 'cha' thứ hai:
$ git log HEAD^2
@@ -121,7 +121,7 @@ Bạn có thể tổ hợp các dấu mũ này với các kiểu khác nhau. Ví
$ git checkout 1b6d^^2~10 -b ancient
-bắt đầu một nhánh mới ``ancient'' tương ứng với trạng thái (state) lần commit thứ 10 trở về trước từ
+bắt đầu một nhánh mới ``ancient'' tương ứng với trạng thái lần commit thứ 10 trở về trước từ
cha thứ hai của cha thứ nhất của lần commit bắt đầu với 1b6d.
=== Làm Việc Liên Tục ===
@@ -145,7 +145,7 @@ và bạn sẽ phải thường xuyên quay trở lại để sửa lỗi nào
Nếu may mắn, hay trong trường hợp tốt, bạn có thể bỏ qua những dòng này.
$ git checkout master # Quay trở lại Part I.
- $ fix_problem
+ $ sửa_lỗi
$ git commit -a # Commit sau khi sửa lỗi.
$ git checkout part2 # Quay trở lại Part II.
$ git merge master # Trộn các thay đổi.
@@ -202,7 +202,7 @@ Xem thêm *git help branch*.
Nhánh ``master'' thông thường rất hữu dụng. Những người khác sẽ nghĩ rằng
kho chứa của bạn có nhánh với tên này, và nhánh đó chứa phiên bản chính thức
của dự án của bạn. Mặc dù bạn có thể đổi tên hay xóa bỏ nhánh ``master'',
-nhưng bạn nên tôn trọng thỏa thuận ngầm này.
+nhưng bạn không nên làm như thế mà hãy tôn trọng thỏa thuận ngầm này.
=== Nhánh Tạm ===
@@ -226,11 +226,11 @@ cứ như thế. Khi bạn muốn qua trở lại trạng thái đã được t
$ git stash apply # Bạn có thể sẽ phải giải quyết các xung đột có thể nảy sinh.
Bạn có thể có nhiều trạng thái được tạm giấu đi, và vận dụng chúng theo nhiều cách khác nhau. Xem
-*git help stash*. Bạn cũng có thể đoán được, Git duy trì các nhánh ở hậu trường để thực hiện việc này.
+*git help stash* để biết thêm chi tiết. Bạn cũng có thể đoán được, Git duy trì các nhánh ở hậu trường để thực hiện việc này.
=== Làm Theo Cách Của Mình ===
-Bạn có thể cảm thấy việc sử dụng nhánh phiền hà quá. Cuối cùng, clones hầu như
+Bạn có thể sẽ cảm thấy việc sử dụng nhánh phiền hà quá. Cuối cùng, clones có lẽ
lệnh nhanh nhất, và bạn có thể hoán chuyển giữa chúng với lệnh *cd* thay vì sử dụng
lệnh riêng của Git.
@@ -240,6 +240,6 @@ chỉ giữ một cửa sổ trình duyệt được mở, và sử dụng các
có lẽ lại khăng khăng cực đoan cho rằng: mở trên nhiều cửa sổ khác nhau và chẳng cần tab nữa.
Một nhóm khác lại thích cả hai một lúc.
-Việc tạo nhánh thì cũng giống như các tab cho thư mục làm việc của bạn, còn việc nhân bản thì lại giống như việc mở một cửa sổ duyệt mới. Những việc này nhanh chóng và nội bộ, thế thì sao lại không
+Việc tạo nhánh thì cũng giống như tạo các tab cho thư mục làm việc của bạn, còn việc nhân bản thì lại giống như việc mở một cửa sổ duyệt mới. Những việc này nhanh chóng và nội bộ, thế thì sao lại không
thử nghiệm để tìm thấy cách thực hiện thích hợp nhất cho mình? Git giúp bạn làm việc chính xác
như bạn muốn.
View
36 vi/clone.txt
@@ -2,11 +2,11 @@
Trong các hệ thống quản lý mã nguồn trước đây, checkout là tác vụ cơ bản để lấy các tệp tin về. Bạn lấy về toàn bộ các tập tin được lưu giữ trong từng phiên bản riêng biệt.
-Với Git và các hệ thống quản lý mã nguồn phân tán, clone là tác vụ cơ bản. Để lấy các tệp tin, bạn tạo một 'clone' (bản sao) của toàn bộ kho chứa. Nói cách khác, bạn thực tế là một bản sao của máy chủ trung tâm. Bất kỳ cái gì bạn thể làm được với kho chứa chính thì cũng làm được ở đây.
+Với Git và các hệ thống quản lý mã nguồn phân tán, clone là tác vụ cơ bản. Để lấy các tệp tin, bạn tạo một của toàn bộ kho chứa. Nói cách khác, bạn thực tế là một bản sao của máy chủ trung tâm. Bất kỳ cái gì bạn thể làm được với kho chứa chính thì cũng làm được ở đây.
=== Đồng bộ hóa Các Máy tính ===
-Tôi có thể tạo gói tarball hay sử dụng lệnh *rsync* để sao lưu (backup) và đồng bộ hóa dữ liệu. Nhưng thỉnh thoảng, tôi biên tập trên laptop của mình, nhưng lúc khác lại trên máy tính để bàn, và chúng có thể không có sự trao đổi được với nhau.
+Tôi có thể tạo gói tarball hay sử dụng lệnh *rsync* để sao lưu dự phòng và đồng bộ hóa dữ liệu. Nhưng thỉnh thoảng, tôi biên tập trên máy tính xách tay của mình, nhưng lúc khác lại trên máy tính để bàn, và chúng có thể không có sự trao đổi được với nhau.
Khởi tạo kho chứa Git và commit các tệp tin trên một máy tính. Sau đó trên máy tính kia chạy lệnh:
@@ -17,8 +17,8 @@ Khởi tạo kho chứa Git và commit các tệp tin trên một máy tính. Sa
$ git commit -a
$ git pull other.computer:/path/to/files HEAD
-sẽ lấy (pull) một state của các tệp tin trên máy tính khác về máy bạn đang làm việc. Nếu bạn vừa tạo ra một sự chỉnh sửa
-xung đột trong cùng một tệp tin , Git sẽ cho bạn biết và bạn có thể commit lại sau khi sửa chữa chúng.
+sẽ lấy về một trạng thái của các tệp tin trên máy tính khác về máy bạn đang làm việc. Nếu bạn vừa tạo ra một sự chỉnh sửa
+xung đột trong cùng một tệp tin , Git sẽ cho bạn biết và bạn có thể commit lại sau khi đã sửa chữa chúng.
=== Quản lý theo cách Cũ ===
@@ -40,7 +40,7 @@ Khởi động dịch vụ Git daemon nếu cần:
$ git daemon --detach # nó có thể đã hoạt động rồi
Để làm một máy chủ chạy dịch vụ Git, làm theo các chỉ dẫn sau để cài đặt
-và khởi tạo kho Git. Cách thường thấy nhất là điền vào form trên trang web.
+và khởi tạo kho Git. Cách thường thấy nhất là điền vào mẫu có sẵn trên trang web.
'Push' dự án của bạn lên máy chủ trung tâm bằng lệnh:
@@ -69,23 +69,23 @@ Gửi thay đổi của mình lên máy chủ trung tâm:
Nếu máy chủ trung tâm có thay đổi bởi hành động của một người phát triển phần mềm khác, quá trình
push sẽ bị lỗi, và anh ta phải pull về bản mới nhất, xử lý các xung đột khi trộn, sau đó thử lại.
-=== Kho Bare ===
+=== Kho Thuần ===
-Kho bare (kho trần) được đặt tên như vậy vì nó không chứa thư mục làm việc; nó chỉ chứa các tệp tin thường là ẩn trong thư mục phụ `.git`. Hay nói cách khác, nó chứa lịch sử mã nguồn của một dự án, và không bao giờ giữ snapshot của bất kỳ phiên bản nào.
+Kho thuần (bare) được đặt tên như vậy vì nó không chứa thư mục làm việc; nó chỉ chứa các tệp tin thường là ẩn trong thư mục phụ `.git`. Hay nói cách khác, nó chứa lịch sử mã nguồn của một dự án, và không bao giờ giữ dữ liệu còn đang dang dở của bất kỳ phiên bản nào.
-Kho bare có vai trò hoạt động giống như máy chủ trung tâm trong các hệ thống
-quản lý mã nguồn tập trung: thư mục chủ dự án của bạn. Các nhà phát triển phần mềm clone
+Kho thuần có vai trò hoạt động giống như máy chủ trung tâm trong các hệ thống
+quản lý mã nguồn tập trung: thư mục chủ dự án của bạn. Các nhà phát triển phần mềm nhân bản
dữ liệu dự án của bạn ở đây, và push các thay đổi chính thức lên đó. Thông thường nó
-đặt tại máy chủ mà máy này đôi khi còn làm một số việc khác nữa. Sự phát triển
+đặt tại máy chủ mà máy này đôi khi còn làm một số việc khác nữa. Sự biên soạn mã nguồn
xảy ra trên bản sao, vì vậy thư mục chủ của kho chứa có thể hoạt động mà không cần
thư mục làm việc.
-Nhiều lệnh Git gặp lỗi trên kho bare trừ phi biến môi trường `GIT_DIR` được đặt với giá trị là đường dẫn đến kho chứa, hay tùy chọn `--bare` được áp dụng.
+Nhiều lệnh Git gặp lỗi trên kho thuần trừ phi biến môi trường `GIT_DIR` được đặt với giá trị là đường dẫn đến kho chứa, hay tùy chọn `--bare` được áp dụng.
=== Push đối lập với pull ===
Tại sao chúng tôi lại giới thiệu lệnh push, thay vì trông cậy vào lệnh pull
-quen thuộc? Trước hết, việc pull gặp lỗi trên kho trần: thay vào đó bạn phải dùng lệnh 'fetch',
+quen thuộc? Trước hết, việc pull gặp lỗi trên kho thuần: thay vào đó bạn phải dùng lệnh 'fetch',
lệnh này chúng ta sẽ nói sau. Nhưng dù là chúng ta giữ kho chứa thông thường trên
máy chủ trung tâm, việc pull lên nó hơi cồng kềnh. Chúng ta phải
đăng nhập vào máy chủ trước, và cung cấp cho lệnh pull địa chỉ mạng
@@ -94,7 +94,7 @@ có khả năng truy cập shell máy chủ trong chỗ đầu tiên đó?
Tuy nhiên, ngoài trường hợp này ra, chúng ta còn nản lòng với việc push lên kho chứa, bởi vì tình trạng hỗn loạn có thể xảy khi thư mục đích có chứa thư mục làm việc.
-Tóm lại, khi bạn học Git, chỉ push khi đích là kho bare; nếu không thì dùng pull.
+Tóm lại, khi bạn học Git, chỉ push khi đích là kho thuần; nếu không thì dùng pull.
=== Rẽ Nhánh Dự Án ===
@@ -110,7 +110,7 @@ Từ bây giờ trở đi, bạn có thể trộn các sự thay đổi từ d
=== Sao Lưu Không Giới Hạn ===
-Bạn muốn lưu trữ dự án của mình ở nhiều nơi khác nhau ư? Nếu dự án của bạn có nhiều người cùng phát triển, bạn không cần phải làm gì cả! Mỗi một bản sao đều đồng thời có tác dụng như một bản sao lưu dự phòng. Không chỉ mỗi trạng thái hiện hành mà cả các mục lịch sử trong dự án của mình. Nhờ có giá trị băm bằng mật mã, nếu bản sao của người nào đó bị hỏng, nó sẽ được phát hiện ngay sau khi họ liên lạc với những người khác.
+Bạn muốn lưu trữ dự án của mình ở nhiều nơi khác nhau ư? Nếu dự án của bạn có nhiều người cùng phát triển, bạn không cần phải làm gì cả! Mỗi một bản sao đều đồng thời có tác dụng như một bản sao lưu dự phòng. Mỗi bản sao không chỉ lưu trạng thái hiện hành mà toàn bộ lịch sử trong dự án. Nhờ có giá trị băm bằng mật mã, nếu bản sao của người nào đó bị hỏng, nó sẽ được phát hiện ngay sau khi họ liên lạc với những người khác.
Nếu dự án của bạn không phổ biến, hãy tìm máy chủ lưu giữ bản sao của mình càng nhiều càng tốt.
@@ -131,7 +131,7 @@ và pull các thay đỏi từ một bản sao khác:
$ git pull /the/other/clone HEAD
-=== Guerilla ===
+=== Song Hành cùng các hệ thống SCM khác ===
Bạn đang làm việc cho một dự án có sử dụng hệ thống quản lý mã nguồn cũ, và bạn lại muốn sử dụng Git? Thế thì hãy khởi tạo kho chứa Git trong thư mục bạn đang làm việc:
@@ -143,7 +143,7 @@ sau đó clone nó:
$ git clone . /some/new/directory
-Bây giờ hãy chuyển đến thư mục mới đó và làm việc ở đây thay vì chỗ cũ, sử dụng Git để thỏa mãn tình yêu của mình. Đôi khi, bạn sẽ muốn đồng bộ hóa với những người khác nữa, trong trường hợp đó hãy chuyển tới thư mục nguyên bản (original), đồng bộ hóa bằng cách sử dụng một hệ thống quản lý mã nguồn khác, và gõ:
+Bây giờ hãy chuyển đến thư mục mới đó và làm việc ở đây thay vì chỗ cũ, sử dụng Git để thỏa mãn tình yêu của mình. Đôi khi, bạn sẽ muốn đồng bộ hóa với những người khác nữa, trong trường hợp đó hãy chuyển tới thư mục nguyên gốc, đồng bộ hóa bằng cách sử dụng một hệ thống quản lý mã nguồn khác, và gõ:
$ git add .
$ git commit -m "Đồng bộ hóa với những người khác"
@@ -169,7 +169,7 @@ hay là sử dụng Mercurial:
$ hg clone http://bitbucket.org/durin42/hg-git/
-Thật buồn là tôi không biết rằng có một plugin tương tự dành cho Git. Vì vậy, tôi ủng hộ Git hơn Mercurial khi dùng cho kho chứa chính, dù là bạn thích Mercurial hơn. Với một dự án Mercurial, thường thường một người tình nguyện duy trì kho Git song song cho tương thích với người sử dụng Git, cũng phải cảm ơn plugin `hg-git`, một dự án Git tự động tiếp nhận người sử dụng Mercurial.
+Thật buồn là tôi không biết rằng có một plugin tương tự dành cho Git. Vì vậy, tôi ủng hộ Git hơn Mercurial khi dùng cho kho chứa chính, dù là bạn thích Mercurial hơn. Với một dự án Mercurial, thường thường một người tình nguyện duy trì kho Git song song cho tương thích với người sử dụng Git, cũng phải cảm ơn plugin `hg-git`, một dự án Git tự động tiếp nhận người sử dụng Mercurial.
Mặc dù plugin có thể chuyển đổi Mercurial sang Git bằng cách push tới một kho rỗng, công việc này là dễ dàng với script `hg-fast-export.sh`, đã sẵn dùng từ:
@@ -193,7 +193,7 @@ Plugin `bzr-git` giúp người dùng Bazaar làm việc với kho Git trong ch
=== Tại sao Tôi sử dụng Git ===
-Trước tiên, tôi chọn Git bởi tôi nghe nói nó làm được việc phi thường là có thể quản lý mã nguồn cho một thứ khó quản lý như kernel của hệ điều hành Linux. Tôi chưa bao giờ nghĩ đến việc chuyển sang cái khác. Git làm được những việc thật đáng ngưỡng mộ, và tôi chưa từng bao giờ gặp các vấn đề với sai sót của nó. Do tôi hoạt động chủ yếu trên Linux, phát hành trên các nền tảng khác không phải là điều mà tôi quan tâm.
+Trước tiên, tôi chọn Git bởi tôi nghe nói nó làm được việc phi thường là có thể quản lý mã nguồn cho một thứ khó quản lý như hạt nhân của hệ điều hành Linux. Tôi chưa bao giờ nghĩ đến việc chuyển sang cái khác. Git làm được những việc thật đáng ngưỡng mộ, và tôi chưa từng bao giờ gặp các vấn đề với sai sót của nó. Do tôi hoạt động chủ yếu trên Linux, phát hành trên các nền tảng khác không phải là điều mà tôi quan tâm.
Ngoài ra, tôi thích lập trình bằng ngôn ngữ C và bash scripts để thực thi như là Python script: ở đây có rất ít sự phụ thuộc, và tôi đam mê với những hệ thống thi hành nhanh chóng.
View
32 vi/drawbacks.txt
@@ -1,6 +1,6 @@
== Phụ lục A: Hạn chế của Git ==
-Git bộc lộ một số nhược điểm mà tôi đã gặp qua. Một số có thể xử lý thủ công một cách dễ dàng bằng các script và hook, một số yêu cầu phải tổ chức lại hay xác lập lại dự án, một số ít rắc rối còn lại, chỉ còn cách là ngồi đợi. Hay tốt hơn cả là bắt tay vào và giúp đỡ!
+Git bộc lộ một số nhược điểm mà tôi đã gặp qua. Một số có thể xử lý thủ công một cách dễ dàng bằng các đoạn kịch bản và hook, một số yêu cầu phải tổ chức lại hay xác lập lại dự án, một số ít rắc rối còn lại, chỉ còn cách là ngồi đợi. Hay tốt hơn cả là bắt tay vào và giúp đỡ họ viết!
=== Điểm Yếu SHA1 ===
@@ -9,7 +9,7 @@ người ta đã đã phát hiện thấy sự va chạm giá trị băm. Trong
vài năm, có lẽ những chiếc PC thông thường cũng đủ sức để âm thầm
làm hư hỏng một kho Git.
-Hy vọng là Git sẽ chuyển sang sử dụng hàm băm tốt hơn trước khi tìm ra cách phá mã SHA1.
+Hy vọng là Git sẽ chuyển sang sử dụng hàm băm tốt hơn trước khi có người tìm ra cách phá mã SHA1.
=== Microsoft Windows ===
@@ -21,59 +21,59 @@ Sử dụng Git trên hệ điều hành Microsoft Windows có vẻ hơi cồng
=== Các Tệp tin Không liên quan ===
-Nếu dự án của bạn rất lớn và chứa rất nhiều tệp tin không có liên quan mà luôn luôn bị thay đổi, Git có thể chịu thiệt thòi hơn các hệ thống khác bởi vì các tệp tin riêng lẻ không được giữ dấu viết. Git giữ các dấu vết thay đổi cho toàn bộ dự án, điều này thường là có lợi.
+Nếu dự án của bạn rất lớn và chứa rất nhiều tệp tin không có liên quan mà luôn luôn bị thay đổi, Git có thể chịu thiệt thòi hơn các hệ thống khác bởi vì các tệp tin không được giữ dấu viết từng cái riêng lẻ. Git giữ các dấu vết thay đổi cho toàn bộ dự án, điều này thường là có lợi.
Giải pháp là chia nhỏ dự án của bạn ra, mỗi một phần bao gồm các tệp tin liên quan đến nhau. Hãy sử dụng *git submodule* nếu bạn vẫn muốn giữ mọi thứ trong một kho chung.
=== Ai Sửa và Sửa gì? ===
-Một số hệ thống quản lý mã nguồn bắt buộc bạn đánh dấu rõ ràng vào tệp tin theo một cách nào đó trước khi biên soạn. Trong khi mà điều này đặc biệt phiền toái khi nó lại dính líu đến việc phải nói chuyện với máy chủ trung tâm, việc làm này có hai lợi ích:
+Một số hệ thống quản lý mã nguồn bắt buộc bạn đánh dấu rõ ràng vào tệp tin theo một cách nào đó trước khi biên soạn. Trong khi mà điều này đặc biệt phiền toái nó lại dính líu đến việc phải liên lạc với máy chủ trung tâm, việc làm này có hai lợi ích:
- 1. Diffs thì nhanh bởi vì nó chỉ kiểm tra các tệp tin đã đánh dấu.
+ 1. Thực hiện lệnh 'diff' diễn ra nhanh bởi vì nó chỉ kiểm tra các tệp tin đã đánh dấu.
2. Một người có thể biết được khác đang làm việc trên một tệp tin bằng cách hỏi máy chủ trung tâm ai đã đánh dấu là đang sửa.
-Với một script thích hợp, bạn có thể lưu giữ theo cách này với. Điều này yêu cầu sự hợp tác từ người lập trình, người có thể chạy các script chuyên biệt khi biên soạn một tệp tin.
+Với một đoạn kịch bản thích hợp, bạn có thể lưu giữ theo cách này với. Điều này yêu cầu sự hợp tác từ người lập trình, người có thể chạy các kịch bản chuyên biệt khi biên soạn một tệp tin.
=== Lịch Sử Tệp Tin ===
-Từ khi Git ghi lại các thay đổi cho các dự án lớn, việc cấu trúc lại lịch sử của một tệp tin đơn lẻ yêu cầu phải làm việc nhiều hơn các chương trình quản lý mã nguồn giữ dấu vết theo các tệp tin riêng lẻ.
+Sau khi Git ghi lại các thay đổi cho các dự án lớn, việc cấu trúc lại lịch sử của một tệp tin đơn lẻ yêu cầu phải làm việc nhiều hơn các chương trình quản lý mã nguồn giữ dấu vết theo các tệp tin riêng lẻ.
-Hình phạt thường là không đáng kể, và thứ đáng giá mà nó nhận được là các tác vụ khac hoạt động hiệu quả đên không ngờ. Ví dụ, `git checkout` nhanh hơn `cp -a`, và dữ liệu trong dự án lớn nén tốt hơn việc gom lại từ tệp tin cơ bản.
+Hình phạt thường là không đáng kể, và thứ đáng giá mà nó nhận được là các tác vụ khác hoạt động hiệu quả đến không ngờ. Ví dụ, `git checkout` nhanh hơn `cp -a`, và dữ liệu trong dự án lớn nén tốt hơn việc gom lại từ tệp tin cơ bản.
=== Khởi tạo Bản Sao ===
Việc tạo một bản sao có vẻ hơi xa xỉ hơn là việc 'checkout' trong các hệ thống quản lý mã nguồn khác khi phần mềm có lịch sử phát triển lâu dài.
-Cái giá phải trả ban đầu là cần nhiều thời gian để lấy về, nhưng nếu làm như thế, các tác vụ cần làm sau này sẽ nhanh chóng và không cần có mạng. Tuy nhiên, trong một số hoàn cảnh, cách làm thích đáng hơn là tạo một bản sao không đầy đủ tất cả với tùy chọn `--depth`. Điều này giúp ta làm nhanh hơn, nhưng bản sao nhận được sẽ thiếu đi một số chức năng do đó bạn sẽ không thể thực thi được một số lệnh.
+Cái giá phải trả ban đầu là cần nhiều thời gian để lấy về, nhưng nếu đã làm như thế, các tác vụ cần làm sau này sẽ nhanh chóng và không cần có mạng. Tuy nhiên, trong một số hoàn cảnh, cách làm phù hợp hơn là tạo một bản sao không đầy đủ bằng tùy chọn `--depth`. Điều này giúp ta tạo bản sao nhanh hơn, nhưng bản sao nhận được sẽ thiếu đi một số chức năng do đó bạn sẽ không thể thực thi được một số lệnh.
=== Các Dự Án Hay Thay Đổi ===
-Git được viết ra với mục đích chú tâm đến kích thước tạo ra bởi các thay đổi. Con người chỉ tạo ra sự thay đổi rất nhỏ giữa các phiên bản. Như là bổ xung lời nhận xét có sửa lỗi ở đây, có đặc tính mới ở đây, sửa lỗi chú thích, v.v... Nhưng nếu các tệp tin của bạn căn bản khác nhau, thì trong mỗi lần commit, nó sẽ ghi lại toàn bộ các thay đổi vào lịch sử và làm cho dự án của bạn tất yếu sẽ tăng kích cỡ.
+Git được viết ra với mục đích chú tâm đến kích thước tạo ra bởi các thay đổi. Con người chỉ tạo ra sự thay đổi rất nhỏ giữa các phiên bản. Như là bổ xung lời nhận xét có sửa lỗi ở đây, có đặc tính mới ở đây, sửa lỗi chú thích, v.v.. Nhưng nếu các tệp tin của bạn căn bản khác nhau, thì trong mỗi lần commit, nó sẽ ghi lại toàn bộ các thay đổi vào lịch sử và làm cho dự án của bạn tất yếu sẽ tăng kích cỡ.
Không có bất kỳ một hệ thống quản lý mã nguồn nào có thể làm được điều này, nhưng những người sử dụng Git theo tiêu chuẩn sẽ còn phải chịu tổn thất hơn khi lịch sử của nó được nhân bản.
Đây là lý do tại sao các thay đổi quá lớn cần được xem xét. Định dạng các tệp tin có thể bị thay đổi. Các thay đổi nhỏ chỉ xảy ra phần lớn tại một số ít tệp tin.
-Việc xét đến việc sử dụng cơ sở dữ liệu hay các giải pháp sao-lưu/lưu-trữ có lẽ là thứ có vẻ thực tế hơn, không phải là hệ thống quản lý mã nguồn. Ví dụ, quản lý mã nguồn không thích hợp cho việc quản lý các ảnh được chụp một cách định kỳ từ webcam.
+Việc xét đến việc sử dụng cơ sở dữ liệu hay các giải pháp sao-lưu/lưu-trữ có lẽ là thứ có vẻ thực tế hơn, không nên dùng hệ thống quản lý mã nguồn. Ví dụ, quản lý mã nguồn không thích hợp cho việc quản lý các ảnh được chụp một cách định kỳ từ webcam.
-Nếu các tệp tin thực sự thay đổi thường xuyên và chúng cần phải quản lý, việc xem xét khả năng sử dụng Git hoạt động như một hệ thống quản lý tập trung là có thể chấp nhận được. Một người có thể tải về một bản sao không đầy đủ, nó chỉ lấy về một ít hay không lấy về lịch sử của dự án. Dĩ nhiên, nhiều công cụ dành cho Git sẽ không thể hoạt động được, và sự sửa chữa phải được chuyển lên như là các miếng vá. Điều này chắc chắn là tốt và nó giống như là ta không thể hiểu nổi tại sao một số người lại muốn lịch sử của rất nhiều các tệp tin chẳng hoạt động ổn định.
+Nếu các tệp tin thực sự thay đổi thường xuyên và chúng cần phải quản lý, việc xem xét khả năng sử dụng Git hoạt động như một hệ thống quản lý tập trung là có thể chấp nhận được. Một người có thể tải về một bản sao không đầy đủ, nó chỉ lấy về một ít hay không lấy về lịch sử của dự án. Dĩ nhiên, nhiều công cụ dành cho Git sẽ không thể hoạt động được, và sự sửa chữa phải được chuyển lên như là các miếng vá. Điều này chắc chắn là tốt và nó giống như là ta không thể hiểu nổi tại sao một số người lại muốn có được lịch sử của rất nhiều các tệp tin chẳng hoạt động ổn định.
-Một ví dụ khác là dự án phụ thuộc vào firmware, cái này có dạng thức là tệp tin nhị phân có kích thước rất lớn. Người sử dụng không quan tâm tới lịch sử của firmware, vả lại khả năng nén lại cũng rất ít, vì vậy quản lý firmware có lẽ là không cần thiết vì nó làm phình to kích thước kho chứa.
+Một ví dụ khác là dự án phụ thuộc vào firmware, cái này có dạng thức là tệp tin nhị phân có kích thước rất lớn. Người sử dụng không quan tâm tới lịch sử của firmware, vả lại khả năng nén của nó lại cũng rất ít, vì vậy quản lý firmware có lẽ là không cần thiết vì nó làm phình to kích thước kho chứa.
-Trong trường hợp này, mã nguồn có thể lưu giữ trong kho Git, và tệp tin nhị phân được giữ ở nơi khác. Để cho công việc trở nên dễ dàng hơn, một người có thể phân phối một script mà nó sử dụng Git để clone mã nguồn, và dùng lệnh rsync hay Git lấy về firmware.
+Trong trường hợp này, mã nguồn có thể lưu giữ trong kho Git, và tệp tin nhị phân được giữ ở nơi khác. Để cho công việc trở nên dễ dàng hơn, một người có thể tạo ra một đoạn kịch bản mà nó sử dụng Git để nhân bản mã nguồn, và dùng lệnh rsync hay Git lấy về firmware.
=== Bộ Đếm ===
Một số hệ quản trị mã nguồn tập trung duy trì một số nguyên dương tự động tăng lên khi có lần commit mới được chấp nhận. Git quy các thay đổi này bởi giá trị băm của chúng, điều này là tốt trong phần lớn hoàn cảnh.
-Nhưng một số người thích có nó ở dạng số nguyên. May mắn thay, rất dễ dàng để viết các script như thế với mỗi lần cập nhật, kho Git trung tâm Git gia một số nguyên, có thể là trong một thẻ (tag), và kết hợp nó với giá trị băm của lần commit cuối.
+Nhưng một số người thích có nó ở dạng số nguyên. May mắn thay, rất dễ dàng để viết các đoạn kịch bản làm được như thế với mỗi lần cập nhật, kho Git trung tâm Git gia một số nguyên, có thể là trong một thẻ (tag), và kết hợp nó với giá trị băm của lần commit cuối.
Mỗi bản sao có thể có một bộ đếm riêng, nhưng điều này chẳng ích lợi gì, chỉ có kho chứa trung tâm và bộ đếm của nó là có ý nghĩa với mọi người.
=== Với Thư Mục Rỗng ===
-Các thư mục rỗng không được theo dõi. Tạo ra các tệp tin giả để thử trục trặc này.
+Các thư mục rỗng không được theo dõi. Tạo ra các thư mục giả để thử trục trặc này.
Xét về mặt thi hành của Git, thay vì thiết kế của nó, điều hạn chế này này là đáng trách. Với một chút may mắn, một khi Git thấy có thêm lợi ích từ việc này, thêm nhiều người đòi hỏi tính năng này và nó sẽ được thực hiện.
View
18 vi/grandmaster.txt
@@ -2,7 +2,7 @@
Bây giờ, bạn có thể thông qua lệnh *git help* để bật trang trợ giúp lên và có thể hiểu
gần như tất cả mọi thứ. Tuy nhiên, việc xác định chính xác lệnh cần sử dụng để giải quyết
-các vấn đề đặt ra có lẽ chẳng dễ dàng gì. Có thể tôi có thể giúp bạn tiết kiệm được thời gian: bên dưới là một vài
+các vấn đề thực tế đặt ra có lẽ chẳng dễ dàng gì. Có thể tôi có thể giúp bạn tiết kiệm được thời gian: bên dưới là một vài
cách giải quyết các vấn đề thực tế đặt ra mà tôi đã từng sử dụng trong quá khứ.
=== Phát hành Mã Nguồn ===
@@ -61,7 +61,7 @@ bạn có thể đưa vào hay gỡ bỏ nhiều tệp tin vào một trạng th
chỉ trong các tệp tin riêng biệt. Có một sự lựa chọn khác, chạy lệnh *git commit \--interactive* mà nó
sẽ tự động commit sau khi bạn làm xong.
-=== Mục Lục: Git's Staging Area ===
+=== Mục Lục: Vùng trạng thái của Git ===
Chúng ta trốn tránh chưa muốn nói đến một thứ nổi tiếng của Git đó là 'index' (mục lục), nhưng chúng ta phải đối mặt với nó để mà
giảng giải những điều ở trên. Chỉ mục là vùng trạng thái tạm thời. Git ít khi di chuyển
@@ -70,12 +70,12 @@ dữ liệu vào mục lục, và sau đó sao chép dữ liệu trong chỉ m
cuối.
Ví dụ, lệnh *commit -a* thực sự bao gồm hai quá trình. Bước thứ nhất là đặt
-toàn bộ dữ liệu hiện tại của mọi tệp tin cần theo dõi vào bảng mục lục (index). Bước thứ
+toàn bộ dữ liệu hiện tại của mọi tệp tin cần theo dõi vào bảng mục lục. Bước thứ
hai là ghi vào bảng mục lục. Việc commit không sử dụng tùy chọn
*-a* chỉ thi hành bước thứ hai, và nó chỉ có ý nghĩa sau khi chạy lệnh
mà lệnh này bằng cách này hay cách khác thay đổi bảng chỉ mục, như là lệnh *git add* chẳng hạn.
-Thường thường chúng ta bỏ qua index và lấy cớ là chúng ta đang đọc trực tiếp và ghi thẳng vào trong lịch sử. Vì lý do này, chúng ta muốn việc điều khiển chính xác, như vậy chúng ta chỉnh sửa index bằng cách thủ công. Chúng ta đặt một snapshot của một số, không phải tất cả, các thay đổi của chúng ta vào bảng mục lục, và sau đó ghi những cái này vào lịch sử.
+Thường thường chúng ta bỏ qua mục lục và lấy cớ là chúng ta đang đọc trực tiếp và ghi thẳng vào trong lịch sử. Vì lý do này, chúng ta muốn việc điều khiển chính xác, như vậy chúng ta chỉnh sửa mục lục bằng cách thủ công. Chúng ta đặt một dữ liệu hiện hành của một số, không phải tất cả, các thay đổi của chúng ta vào bảng mục lục, và sau đó ghi những cái này vào lịch sử.
=== Đừng Quên HEAD Của Mình ===
@@ -100,8 +100,8 @@ Nhưng giả sử bạn không có được nó? Đừng lo: với những lện
Có thể ORIG_HEAD là chưa đủ. Có lẽ bạn vừa nhận thấy mình vừa tạo ra một sai sót có quy mô lớn và bạn cần phải quay lại một lần commit cách đây lâu lắm rồi trong một nhánh mà bạn đã quên rồi vì nó đã quá lâu.
Theo mặc định, Git giữ một lần commit ít nhất là hai tuần lễ, ngay cả khi bạn đã ra lệnh
-cho Git phá hủy nhánh chứa nó. Sự trục trặcviệc tìm giá trị băm
-thích hợp. Bạn có thể tìm kiếm tất cả các giá trị băm trong `.git/objects` và sử dụng cách thử sai tất cả các giá trị
+cho Git phá hủy nhánh chứa nó. Sự khó khănở chỗ làm thế nào để tìm được giá trị băm
+thích hợp. Bạn có thể tìm kiếm tất cả các giá trị băm trong `.git/objects` và sử dụng phương pháp thử sai tất cả các giá trị
để có được thứ mình muốn. Nhưng còn có cách dễ dàng hơn.
Git ghi lại mọi giá trị băm của mọi lần commit trong máy tính tại thư mục `.git/logs`. Thư mục con `refs` chứa lịch sử của tất cả các hoạt động trên tất cả cách nhánh, trong khi tệp tin `HEAD` giữ tất cả các giá trị băm mà nó từng có được. Phần sau có thể được sử dụng để tìm kiếm giá trị băm của các lần commits trên các nhánh cái mà đã bị cắt đi một cách tình cờ.
@@ -114,7 +114,7 @@ Thay vì phải cắt và dán giá trị băm từ reflog, hãy thử:
$ git checkout "@{10 minutes ago}"
-Hay checkout lần thứ 5th-last visited commit thông qua lệnh:
+Hay checkout lần thứ 5 kể từ lần commit cuối viếng thăm thông qua lệnh:
$ git checkout "@{5}"
@@ -136,7 +136,7 @@ trong trường hợp này những lần commit sẽ chỉ bị xóa bỏ khi b
=== Xây Dựng trên Git ===
-In true UNIX fashion, Git được thiết kế cho phép nó dễ dàng được sử dụng như là một thành phần bên dưới của các chương trình khác, như là cho giao diện đồ họa GUI và giao diện Web để thay thế cho giao diện dòng lệnh, công cụ quản lý các miếng vá, các công cụ nhập và chuyển đổi, và những thứ tương tự như thế. Trên thực tế, một số lệnh Git bản chất nó cũng là các kịch bản (scripts) đứng trên vai của những người khổng lồ, chính là hệ điều hành. Chỉ cần sửa đổi một chút, bạn có thể bắt Git làm việc phù hợp với sở thích của mình.
+Tuân thủ theo phong thái UNIX, Git được thiết kế cho phép nó dễ dàng được sử dụng như là một thành phần bên dưới của các chương trình khác, như là cho giao diện đồ họa GUI và giao diện Web để thay thế cho giao diện dòng lệnh, công cụ quản lý các miếng vá, các công cụ nhập và chuyển đổi, và những thứ tương tự như thế. Trên thực tế, một số lệnh Git bản chất nó cũng là các kịch bản đứng trên vai của những người khổng lồ, chính là hệ điều hành. Chỉ cần sửa đổi một chút, bạn có thể bắt Git làm việc phù hợp với sở thích của mình.
Một mẹo nhỏ là sử dụng một tính năng dựng sẵn trong Git là gán bí danh cho các lệnh để nó trở nên ngắn gọn hơn
sử dụng lệnh:
@@ -160,7 +160,7 @@ Thư mục con +contrib+ là một kho báu được tìm thấy trong số các
Đúng lúc, một số trong số chúng có thể được xúc tiến thành lệnh chính thức. Trên hệ thống Debian và
Ubuntu, thư mục này ở tại +/usr/share/doc/git-core/contrib+.
-Một thư mục phổ biến khác là +workdir/git-new-workdir+. Thông qua các liên kết tài tình, đoạn script này tạo ra một thư mục làm việc mới khi phần lịch sử thì chia sẻ với kho chứa nguyên gốc:
+Một thư mục phổ biến khác là +workdir/git-new-workdir+. Thông qua các liên kết tài tình, đoạn kịch bản này tạo ra một thư mục làm việc mới trong khi phần lịch sử thì chia sẻ với kho chứa nguyên gốc:
$ git-new-workdir an/existing/repo new/directory
View
20 vi/history.txt
@@ -25,7 +25,7 @@ Bạn muốn thêm vài chỉnh sửa vào lần cuối mình đã commit ư? Th
$ git commit --amend -a
-=== ... And Then Some ===
+=== ... Và Nhiều Lần mộtlúc ===
Hãy giả sử vấn đề trục trặc ở lần commit cách đây mười lần. Trong một buổi làm việc dài, bạn đã tạo ra hàng tá các lần commit. Nhưng bạn không hoàn toàn hài lòng với cách mà chúng được tổ chức, và một số lần commit cần được soạn lại phần mô tả. Thế thì hãy gõ:
@@ -42,7 +42,7 @@ Thế thì:
-Xóa bỏ các lần commit bằng cách xóa các dòng tương ứng.
-Đặt lại các lần commit bằng các đặt lại các dòng.
- Thay thế `pick` với:
- * `edit` để đánh dấu lần commit đó là dành cho việc tu bổ (amend).
+ * `edit` để đánh dấu lần commit đó là dành cho việc tu bổ.
* `reword` để thay đổi phần chú giải.
* `squash` để hòa trộn với lần commit trước.
* `fixup` để hòa trộn với lần commit trước và bỏ qua việc ghi lại phần chú giải.
@@ -58,7 +58,7 @@ Cách khác, chạy:
Do vậy cứ commit thoải mái và thường xuyên bởi vì bạn có thể dọn dẹp cho gọn gàng sau này bằng lệnh rebase.
-=== Các Thay Đổi Riêng Xếp Sau ===
+=== Thay Đổi Riêng Sắp Xếp Sau ===
Bạn đang làm việc trên một dự án đang hoạt động. Bạn đã tạo ra một số lần commit tại máy tính của mình, và
sau đó bạn đồng bộ hóa với cây chính thức bằng cách hòa trộn. Chu kỳ này tự lặp chính nó một số lần trước khi bạn thực sự push tới cây trên máy chủ trung tâm.
@@ -66,15 +66,15 @@ sau đó bạn đồng bộ hóa với cây chính thức bằng cách hòa tr
Nhưng hiện tại lịch sử bản sao Git trên máy tính của bạn là một mớ hỗn độn của những lần thay đổi trên máy tính riêng và máy chính thức. Bạn muốn thấy tất cả các thay đôi của riêng mình trong một đoạn liên tục không ngắt quãng, và sau tất cả các thay đổi từ văn phòng.
Đây chính là công việc dành cho lệnh *git rebase* đã được miêu tả ở trên. Trong nhiều trường hợp bạn có thể sử dụng
-cờ *--onto* và tránh xa sự tương tác.
+cờ *--onto* và tránh xa sự tương tác với các máy tính khác.
-Xem thêm trong *git help rebase* để thấy được chi tiết các ví dụ dành cho lệnh đáng kinh ngạc này. Bạn có thể chia cắt các lần commit. Bạn còn có thể xắp xếp lại các nhánh của một cấu trúc cây.
+Xem thêm trong *git help rebase* để thấy được chi tiết các ví dụ dành cho lệnh đáng kinh ngạc này. Bạn có thể chia cắt các lần commit. Bạn còn có thể xắp xếp lại các nhánh của một cấu trúc cây.
=== Viết Lại Lịch Sử ===
Thỉnh thoảng, bạn muốn việc quản lý mã nguồn giống việc người ta sơn vẽ chân dung một
con người, tẩy xóa chúng từ lịch sử như theo ý của Stalinesque. Ví dụ,
-giả sử chúng ta có ý định phát hành dự án, nhưng lại liên đới đến một tệp tin mà nóphải được giữ bí mật
+giả sử chúng ta có ý định phát hành dự án, nhưng lại liên đới đến một tệp tin mà nó phải được giữ bí mật
vì lý do nào đó. Chẳng hạn như tôi đã quên khi ghi lại số thẻ tín dụng vào trong một tệp tin
văn bản và ngẫu nhiên nó được thêm vào trong dự án. Việc xóa tệp tin này là
chưa đủ, bởi vì ta có thể đọc nó từ lần commit cũ. Chúng ta phải gỡ bỏ
@@ -153,7 +153,7 @@ những lệnh này có thể gửi một kho chứa ở dạng văn bản thôn
=== Vị Trí Nào Phát Sinh Lỗi? ===
-Bạn vừa mới phát hiện ra một đặc tính không hoạt động trong chương trình mà bạn chắc chắn là nó đã hoạt động vài tháng trước. Tệ quá! Lỗi đến từ đâu nhỉ? Nếu như chỉ có mình bạn kiểm tra cũng như phát triển đặc tính này.
+Bạn vừa mới phát hiện ra một đặc tính không hoạt động trong chương trình mà bạn chắc chắn là nó đã hoạt động vài tháng trước. Tệ quá! Lỗi bắt đầu từ chỗ nào nhỉ? Nếu như chỉ có mình bạn kiểm tra cũng như phát triển đặc tính này.
Lúc này thì đã quá muộn rồi. Tuy nhiên, chỉ cần bạn commit thường xuyên, Git
có thể xác định vị trí của trục trặc:
@@ -178,7 +178,7 @@ Thay vì thử nghiệm mọi thay đổi một cách thủ công, hãy tự đ
$ git bisect run my_script
-Git sử dụng giá trị trả về của lệnh đã cho, thông thường là từ các đoạn script, để
+Git sử dụng giá trị trả về của lệnh đã cho, thông thường là từ các đoạn kịch bản, để
quyết định là lệnh đã thực hiện tốt hay không: lệnh sẽ trả về giá trị 0
khi tốt, 125 khi sự thay đổi bị bỏ qua, và bất kỳ giá trị nào khác nằm giữa 1
và 127 nếu gặp lỗi. Một giá trị âm sẽ bãi bỏ lệnh bisect.
@@ -211,7 +211,7 @@ những người sử dụng sẽ lảng tránh việc sử dụng các lệnh c
đặc biệt là các lệnh cơ bản. Khi những người dùng phải chạy
các lệnh chạy chậm, hiệu suất bị giảm bởi vì nó làm gián đoạn công việc của cả một dây truyền.
-Tôi trực tiếp đã trải qua những hiện tượng đó. Git là hệ thống quản lý mã nguồn đầu tiên tôi sử dụng.
+Tôi trực tiếp đã trải qua những hiện tượng đó. Git là hệ thống quản lý mã nguồn đầu tiên tôi sử dụng.
Tôi nhanh chóng làm quen với nó, bị quyến rũ bởi những đặc tính kỹ thuật mà nó đã cung cấp.
Tôi đơn giản cho rằng các hệ thống khác thì cũng tương tự: việc chọn lựa một
hệ thống quản lý mã nguồn thì cũng chẳng khác việc chọn một trình biên soạn hay một
@@ -233,5 +233,5 @@ chính của mình, lệnh đã hoàn tất từ lâu rồi, và tôi phải lã
Ở đây còn có một hậu quả rất đáng quan tâm nữa: đoán trước được việc tắc nghẽn của mạng máy tính,
nhiều cá nhân riêng lẻ có thể chiếm dụng nhiều lưu lượng mạng hơn cần thiết trên các tác vụ
khác nhau để cố gắng giảm thiểu sự chậm trễ có thể xảy ra trong tương lai. Hậu quả cuối cùng là
-sự quá tải quá mức, việc vô tình việc ủng hộ việc tiêu dùng cá nhân như thế làm đốt cháy nhiều lưu lượng mạng hơn
+sự quá tải quá mức, việc vô tình ủng hộ việc tiêu dùng cá nhân như thế làm đốt cháy nhiều lưu lượng mạng hơn
và sau đó nó làm cho việc tắc nghẽn càng lúc càng trở nên tồi tệ hơn.
View
32 vi/intro.txt
@@ -8,45 +8,45 @@ Tôi đã chơi trò chơi trên máy tính suốt từ bé đến giờ. Ngư
Hãy nghĩ việc biên soạn mã nguồn, tài liệu cũng giống như việc chúng ta đang chơi trò chơi trên máy tính. Một khi bạn đã làm được kha khá, bạn sẽ muốn ghi lại thành quả công việc của mình. Để làm điều đó, bạn chỉ việc bấm vào nút 'Save' trong chương trình biên soạn của mình.
-Nhưng việc làm này sẽ ghi đè lên bản cũ. Điều này cũng giống như các trò chơi đã cũ chỉ cho phép ghi trên một tệp tin: bạn phải chắc chắn là mình muốn ghi lại, nếu không thì bạn không bao giờ có thể quay lại trạng thái cũ nữa. Và thật không may vì lần lưu trước đó có thể là đúng tại một điểm rất hay trong lượt chơi và bạn muốn thăm lại về sau. Tệ hơn nữa, bản ghi lại hiện tại lại không đúng, và thế là bạn sẽ phải bắt đầu lại.
+Nhưng việc làm này sẽ ghi đè lên bản cũ. Điều này cũng giống như các trò chơi đã cũ chỉ cho phép ghi trên một tệp tin: bạn phải chắc chắn là mình muốn ghi lại, nếu không thì bạn không bao giờ có thể quay lại trạng thái cũ nữa. Và thật không may vì lần lưu trước đó có thể là đúng tại một điểm rất hay trong lượt chơi và bạn muốn thăm lại về sau. Tệ hơn nữa là khi bản ghi lại hiện tại lại không đúng, và thế là bạn sẽ phải bắt đầu lại từ đầu.
=== Quản Lý Mã Nguồn ===
-Khi biên soạn, bạn có thể chọn 'Save As...' để tạo tệp tin với tên khác, hay là sao chép tệp tin ra một chỗ khác trước khi bạn ghi lại, nếu như bạn muốn dùng cả các bản cũ. Bạn có thể nén chúng lại để tiết kiệm dung lượng lưu trữ. Đây là dạng thức nguyên thủy và tốn nhiều công sức cho việc quản lý dữ liệu. Trò chơi trên máy tính đã cải tiến cách này từ rất lâu rồi, rất nhiều trong số chúng cung cấp khả năng ghi lại tự động theo thời gian.
+Khi biên soạn, bạn có thể chọn 'Save As...' để ghi lại tệp tin hiện tại nhưng với một cái tên khác, hay là sao chép tệp tin ra một chỗ khác trước khi bạn ghi lại, nếu như bạn muốn dùng cả các bản cũ. Bạn có thể nén chúng lại để tiết kiệm dung lượng lưu trữ. Đây là dạng thức nguyên thủy và tốn nhiều công sức cho việc quản lý dữ liệu. Trò chơi trên máy tính đã cải tiến cách trên từ rất lâu rồi, rất nhiều trong số chúng cung cấp cho bạn khả năng tự động ghi lại sau từng khoảng thời gian nhất định.
-Chúng ta sẽ giải quyết một vấn đề hơi hóc búa một chút nhé! Bạn nói rằng bạn có nhiều tệp tin cần làm việc cùng nhau, như mã nguồn cho một dự án chẳng hạn, hay các tệp tin cho một website. Bây giờ bạn muốn giữ một phiên bản cũ bạn phải lưu giữ toàn bộ thư mục. Giữ nhiều phiên bản như thế bằng cách thủ công thật bất tiện, và sẽ nhanh chóng trở nên tốn kém.
+Chúng ta sẽ giải quyết một vấn đề hơi hóc búa một chút nhé! Bạn nói rằng bạn có nhiều tệp tin có liên quan mật thiết với nhau, như mã nguồn cho một dự án chẳng hạn, hay các tệp tin cho một website. Bây giờ nếu bạn muốn giữ một phiên bản cũ bạn phải lưu giữ toàn bộ thư mục. Giữ nhiều phiên bản như thế bằng cách thủ công thật bất tiện, và sẽ nhanh chóng trở nên tốn kém.
-Đối với một số trò chơi, ghi lại một trò chơi thực tế bao gồm toàn bộ thư mục. Những trò chơi này che giấu những chi tiết từ phía người chơi phơi bày ra một giao diện thích hợp để quản lý các phiên bản của thư mục này.
+Đối với một số trò chơi, ghi lại một trò chơi thực tế bao gồm toàn bộ thư mục. Những trò chơi này thực thi việc này tự động chỉ đưa ra một giao diện thích hợp cho người chơi để quản lý các phiên bản của thư mục này.
-Hệ thống quản lý mã nguồn không có sự khác biệt nào. Chúng có một giao diện tinh tế để quản lý một nhóm các thứ trong thư mục. Bạn có thể ghi lại trạng thái của thư mục một cách thường xuyên, và bạn có thể tải lên bất kỳ một trạng thái nào đã được ghi lại trước đó. Không giống như các trò chơi trên máy tính, chúng thường khôn khéo hơn về việc tiết kiệm không gian lưu trữ. Thông thường, chỉ có một số ít tài liệu được sửa đổi giữa các phiên bản, và cũng không nhiều. Nó chỉ lưu giữ những cái có thay đổi thay vì toàn bộ tất cả.
+Các hệ thống quản lý mã nguồn cũng hoạt động theo cách ấy. Chúng có một giao diện tinh tế để quản lý một nhóm các thứ trong thư mục. Bạn có thể ghi lại trạng thái của thư mục một cách thường xuyên, và bạn có thể tải lên bất kỳ một trạng thái nào đã được ghi lại trước đó. Không giống như các trò chơi trên máy tính, chúng thường khôn khéo hơn về việc tiết kiệm không gian lưu trữ. Thông thường, chỉ có một số ít tài liệu được sửa đổi giữa các phiên bản, và cũng không nhiều. Nó chỉ lưu giữ những cái có thay đổi thay vì toàn bộ tất cả.
=== Hệ Thống Phân Tán ===
-Bây giờ hãy tưởng tượng có một trò chơi rất khó. Khó để hoàn thành đến mức là có nhiều game thủ lão luyện trên toàn thế giới quyết định lập thành đội và chia sẻ những trò chơi mà họ đã lưu lại với mục đích là để tất cả mọi người có thể theo dõi được chúng. Speedruns là những ví dụ trong đời sống thực: các đấu thủ được phân hóa theo các mức của cùng một trò chơi hợp tác với nhau để đạt được các kết quả đáng kinh ngạc.
+Bây giờ hãy tưởng tượng có một trò chơi rất khó. Khó để hoàn thành đến mức là có nhiều game thủ lão luyện trên toàn thế giới quyết định lập thành đội và chia sẻ những trò chơi mà họ đã lưu lại với mục đích là để tất cả mọi người có thể theo dõi được nhau. Speedruns là những ví dụ trong đời sống thực: các đấu thủ được phân hóa theo các mức của cùng một trò chơi hợp tác với nhau để đạt được các kết quả đáng kinh ngạc.
Làm thế nào bạn có thể cài đặt một hệ thống mà chúng có thể lấy được từng bản ghi của mỗi người một cách dễ dàng? Và tải lên cái mới hơn?
Ngày xưa, mọi dự án đều sử dụng hệ thống quản lý tập trung. Máy chủ ở một chỗ đâu đó và giữ tất cả các trò chơi đã được ghi lại. Không còn ai khác làm điều đó nữa. Mọi người giữ phần lớn các trò chơi được ghi lại trong máy của họ. Khi một đấu thủ muốn chơi, họ có thể tải về bản ghi lại cuối cùng đã lưu lại ở máy chủ, chơi một lúc, ghi lại và tải trở lại máy chủ để mọi người có thể sử dụng.
-Điều gì xảy ra khi một người chơi, vì một lý do nào đó, muốn có được lần chơi cũ hơn? thể là lần chơi hiện tại không ổn định hay có sai sót bởi vì một người chơi nào đó quên không chỉnh lại trò chơi về mức 3, và họ muốn tìm lần chơi đã ghi lại cuối cùng mà họ vẫn chưa hoàn thành. Hay có thể là họ muốn so sánh sự khác nhau giữa các lần chơi để thấy được công việc đã làm của từng người chơi.
+Điều gì xảy ra khi một người chơi, vì một lý do nào đó, muốn có được lần chơi cũ hơn? Lý do có thể là lần chơi hiện tại không ổn định hay có sai sót bởi vì một người chơi nào đó quên không chỉnh lại trò chơi về mức 3, và họ muốn tìm lần chơi đã ghi lại cuối cùng mà họ vẫn chưa hoàn thành. Hay có thể là họ muốn so sánh sự khác nhau giữa các lần chơi để thấy được thành quả của từng người chơi.
Có rất nhiều lý do vì sao cần đến bản cũ hơn, nhưng kết cục là giống nhau. Họ phải hỏi máy chủ trung tâm để lấy về trò chơi cũ đã được lưu lại. Càng ghi lại nhiều trò chơi, họ càng cần phải liên lạc nhiều với nhau.
-Những hệ thống quản lý mã nguồn thế hệ mới, Git cũng nằm trong số đó, được biết đến như một hệ thống phân tán, và có thể coi nó là phần mở rộng của một hệ thống tập trung. Khi người chơi tải về từ máy chủ chính, họ lấy toàn bộ tất cả các lần đã ghi lại, không chỉ bản cuối. Điều đó có nghĩa là họ trở thành bản sao của máy chủ trung tâm.
+Những hệ thống quản lý mã nguồn thế hệ mới, Git cũng nằm trong số đó, được biết đến như một hệ thống phân tán, và có thể coi nó là một hệ thống tập trung có mở rộng. Khi người chơi tải về từ máy chủ chính, họ lấy toàn bộ tất cả các lần đã ghi lại, không chỉ mỗi bản cuối cùng. Điều đó có nghĩa là họ trở thành bản sao của máy chủ trung tâm.
-Việc khởi tạo bản sao như thế có vẻ hơi xa hoa, đặc biệt là nếu nó có lịch sử phát triển lâu dài, nhưng cái giá phải trả cũng chỉ là việc cần nhiều thời gian để lấy về. Một lợi ích trực tiếp của việc này là khi các tài liệu cũ cần đến, việc liên lạc với máy chủ trung tâm là không cần thiết.
+Việc khởi tạo bản sao như thế có vẻ hơi xa hoa, đặc biệt là nếu nó có lịch sử phát triển lâu dài, nhưng cái giá phải trả cũng chỉ là việc cần nhiều thời gian để lấy về. Một lợi ích trực tiếp của việc này là khi các tài liệu cũ cần đến, việc liên lạc với máy chủ trung tâm là không cần thiết nữa.
-=== Suy Nghĩ Cổ Hủ ===
+=== Quan Niệm Cổ Hủ ===
-Một quan niệm phổ biến là hệ thống phân tán không thích hợp với các dự án có yêu cầu một kho chứa trung tâm chính thức. Chân lý tồn tại một cách khách quan mà không phụ thuộc vào nhận thức của con người. Chụp ảnh ai đó không có nghĩa là lấy đi linh hồn họ. Cũng như thế, nhân bản kho chính cũng không làm giảm đi sự quan trọng của nó.
+Một quan niệm phổ biến là hệ thống phân tán không thích hợp với các dự án có yêu cầu một kho chứa trung tâm chính thức. Không điều gì có thể chà đạp lên sự thật. Chụp ảnh ai đó không có nghĩa là lấy đi linh hồn họ. Cũng như thế, nhân bản kho chính cũng không làm giảm đi sự quan trọng của nó.
-Tóm lại, một hệ thống phân tán đã thiết kế tốt thì làm bất cứ công việc nào cũng khá hơn một hệ thống quản lý mã nguồn tập trung. Tài nguyên mạng thường thì tốn kém hơn các tài nguyên nội bộ. Chúng ta sẽ nói đến các hạn chế của hệ thống phân tán sau, sự so sánh này thường đúng: hệ thống phân tán là hữu hiệu hơn.
+Tóm lại, một hệ thống phân tán đã thiết kế tốt thì làm bất cứ công việc nào cũng khá hơn một hệ thống quản lý mã nguồn tập trung. Tài nguyên mạng thường thì tốn kém hơn các tài nguyên nội bộ. Chúng ta sẽ nói đến các hạn chế của hệ thống phân tán sau, sự so sánh như sau thường đúng: hệ thống phân tán tốt hơn.
Một dự án nhỏ có thể chỉ cần dùng một phần nhỏ các đặc tính được đưa ra bởi một
-hệ thống như thế, nhưng việc sử dụng một hệ thống không có khả năng mở rộng cho một dự án nhỏ thì cũng giống như việc sử dụng
+hệ thống như thế, nhưng việc sử dụng một hệ thống không có khả năng mở rộng cho một dự án nhỏ thì cũng giống như việc sử dụng
hệ thống số La Mã để tính toán các số nhỏ.
-Hơn thế nữa, dự án của bạn có thể lớn vượt ra ngoài mong đợi ban đầu. Việc sử dụng Git từ lúc khởi sự thì cũng giống như việc sử dụng một bộ dao vạn năng chỉ để phục vụ cho mỗi việc mở nút chai. Đến một ngày nào đó bạn cấn đến một cái chìa vít bạn sẽ vui sướng vì mình không chỉ có mỗi cái mở nút chai.
+Hơn thế nữa, dự án của bạn có thể lớn vượt ra ngoài dự kiến ban đầu. Việc sử dụng Git từ lúc khởi sự thì cũng giống như việc sử dụng một bộ dao vạn năng chỉ để phục vụ cho mỗi việc mở nút chai. Đến một ngày nào đó bạn cấn đến một cái chìa vít bạn sẽ vui sướng vì mình không chỉ có mỗi cái mở nút chai.
=== Xung Đột Khi Trộn ===
@@ -54,6 +54,6 @@ Với chủ đề này, dùng cách ví von nó với một trò chơi trên má
Giả sử Alice chèn thêm một dòng vào đầu một tệp tin, và Bob nối một dòng vào cuối của bản sao của mình. Cả hai đều tải lên các thay đổi của mình. Phần lớn các hệ thống sẽ tự động tìm ra hành động hợp lý: chấp nhận và trộn các sự thay đổi của họ, do đó cả hai sự thay đổi mà Alice và Bob tạo ra đều được dùng.
-Bây giờ giả sử cả Alice và Bob cùng sửa một dòng. Thế thì điều này không thể sử lý được mà không có sự can thiệp của con người. Người thứ hai tải lên sẽ được thông báo có xung đột xảy ra, _merge conflict_, và phải chọn một là sửa thêm nữa, hay sửa lại toàn bộ dòng đó.
+Bây giờ giả sử cả Alice và Bob cùng sửa một dòng. Thế thì mâu thuẫn này không thể sử lý được mà không có sự can thiệp của con người. Người thứ hai tải lên sẽ được thông báo có xung đột xảy ra, _merge conflict_, và phải chọn một là sửa thêm nữa, hay sửa lại toàn bộ dòng đó.
-Nhiều tình huống phức tạp có thể nảy sinh. Hệ thống quản lý mã nguồn giữ phần dễ dàng cho chúng, và để lại những tình huống khó khăn cho chúng ta. Thông thường cách ứng xử của chúng có thể điều chỉnh được.
+Nhiều tình huống phức tạp có thể nảy sinh. Hệ thống quản lý mã nguồn giữ phần dễ dàng cho chúng, và để lại những tình huống khó khăn cho chúng ta. Nhưng thông thường cách ứng xử của chúng có thể điều chỉnh được.
View
18 vi/multiplayer.txt
@@ -1,8 +1,8 @@
== Đa Người Dùng ==
-Lúc đầu tôi sử dụng Git cho dự án riêng mà tôi là người duy nhất phát triển nó.
+Lúc đầu tôi sử dụng Git cho dự án riêng của mình mà tôi cũng là người duy nhất phát triển nó.
Trong số những lệnh liên quan đến bản chất phân tán của Git, tôi chỉ cần lệnh *pull*
-và *clone* để giữ cùng một dự án nhưng ở những địa điểm khác nhau.
+và *clone* để giữ cùng một dự án nhưng ở những chỗ khác nhau.
Sau đó tôi muốn mã nguồn của mình được phổ biến trên mạng bằng việc sử dụng Git, và bao gồm cả những thay đổi từ
những người đóng góp. Tôi đã phải học cách làm thế nào để quản lý các dự án có nhiều người phát triển phần mềm
@@ -67,7 +67,7 @@ tín hiệu khói, v.v.. Người nhận khôi phục lại các lần commit t
Bộ nhận thậm chí có thể làm được việc này từ một kho chứa rỗng. Mặc dù kích
thước của nó, +somefile+ chứa các mục kho Git nguyên thủy.
-Trong các dự án lớn hơn, việc triệt tiêu lãng phí bằng lệnh bundle chỉ thay đổi phần thiếu
+Trong các dự án lớn hơn, việc triệt tiêu lãng phí bằng cách chỉ bundle những thay đổi còn thiếu
kho chứa khác. Ví dụ, giả sử lần commit ``1b6d...'' là lần commit gần nhất
đã được chia sẻ giữa cả hai thành viên:
@@ -87,7 +87,7 @@ và tạo một bản bundles mới với:
Miếng vá được trình bày ở dạng văn bản các thay đổi của bạn, nó dễ dàng được đọc hiểu bởi
con người cũng như là máy tính. Điều này mang lại cho chúng sức lôi cuốn toàn cầu. Bạn có thể gửi miếng vá qua
-thư điện tử cho những nhà phát triển phần mềm khác mà chẳng cần lo họ đang sử dụng hệ thống mã nguồn nào. Chừng nào
+thư điện tử cho những nhà phát triển phần mềm khác mà chẳng cần lo họ đang sử dụng hệ thống quản lý mã nguồn nào. Chừng nào
mà độc giả của bạn có thể đọc được thư điện tử của mình thì họ còn có thể thấy được phần chỉnh sửa của bạn. Tương tự thế, về phía mình,
những thứ bạn cần là có một địa chỉ thư điện tử: ở đây chẳng cần cài đặt kho chứa Git nào trên mạng.
@@ -95,7 +95,7 @@ Sử dụng lại ví dụ từ chương đầu tiên:
$ git diff 1b6d > my.patch
-đầu ra là một miếng vá mà bạn có thể dán vào một thư điện tử để thảo luận. Ở kho Git,
+đầu ra là một miếng vá mà bạn có thể dán vào một thư điện tử để trao đổi với người khác. Ở kho Git,
gõ:
$ git apply < my.patch
@@ -119,7 +119,7 @@ Lệnh này sẽ áp dụng cho miếng vá nhận được, đồng thời tạ
Với một chương trình đọc thư điện tử, bạn có thể sử dụng con chuột để chuyển định dạng thư về dạng văn bản thuần trước khi ghi miếng vá thành một tệp tin.
-Có một số khác biệt nhỏ giữa các trình đọc email, nhưng nếu bạn sử dụng một trong
+Có một số khác biệt nhỏ giữa các trình đọc đọc thư điện tử, nhưng nếu bạn sử dụng một trong
số chúng, bạn hầu như chắc chắn là người mà có thể cấu hình chúng một cách dễ dàng
mà chẳng cần phải đọc hướng dẫn sử dụng!
@@ -182,7 +182,7 @@ Hay bạn có thể xem nhánh ``experimental'' đang làm gì:
$ git log origin/experimental
-=== Multiple Remotes ===
+=== Đa Máy chủ ===
Giả sử hai người cùng phát triển trên một sự án của chúng ta, và họ muốn
giữ lại sự khác biệt trên cả hai. Chúng ta theo dõi hơn một kho chứa tại một thời điểm với lệnh:
@@ -225,7 +225,7 @@ Mặc dù tôi ít nhận được sự cộng tác, nhưng tôi tin rằng vi
tốt lên. Hãy đọc
http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[blog của Linus Torvalds].
-Git thuận lợi hơn việc các tệp tin, cũng như là nó
-tiết kiệm công sức cho việc chuyển đổi chúng thành những lần commit dành cho Git. Hơn thế nữa, Git lưu giữ các thông tin rất chi tiết
+Git thuận lợi trong việc tạo các miếng vá, cũng như là nó
+tiết kiệm công sức cho chúng ta trong việc chuyển đổi chúng thành những lần commit dành cho Git. Hơn thế nữa, Git lưu giữ các thông tin rất chi tiết
như là ghi lại tên và địa chỉ thư điện tử của tác giả, cũng như là ngày tháng và
thời gian, và nó cũng đòi hỏi tác giả phải mô tả về những thay đổi mà họ đã tạo ra.
View
37 vi/preface.txt
@@ -1,44 +1,45 @@
= Git Magic =
Ben Lynn
-Tháng Tám 2007
+Tháng Tám, 2007
== Lời nói đầu ==
-http://git.or.cz/[Git] là công cụ quản lý mã nguồn đa năng. Một công cụ quản lý mã nguồn tin cậy, chắc chắn, đa dụng và sự cực kỳ mềm dẻo của Git làm cho việc học nó trở nên khó khăn, tất nhiên là không nói đến người tạo ra nó.
+http://git.or.cz/[Git] là công cụ quản lý mã nguồn vạn năng. Đây là một công cụ quản lý mã nguồn tin cậy, ổn định, đa dụng và sự cực kỳ mềm dẻo và chính sự mềm dẻo của Git làm cho việc học nó trở nên khó khăn, tất nhiên là không nói đến người tạo ra nó.
-Theo quan sát của Arthur C. Clarke, bất kể công nghệ tiên tiến nào cũng không thể phân biệt được nó có kỳ diệu hay không. Đây cũng là cách hay đề đề cập đến Git: những người mới sử dụng không cần quan tâm đến bên trong làm việc như thế nào xem Git như là một điệu gizmo có thể làm những người coi nó là bạn sửng sốt và làm điên đầu các những người đối lập bằng khả năng thần kỳ của mình.
+Theo quan sát của Arthur C. Clarke, bất kể công nghệ tiên tiến nào cũng không thể phân biệt rạch ròi là nó có kỳ diệu hay không. Đây cũng là cách hay đề đề cập đến Git: những người mới sử dụng không cần quan tâm đến bên trong Git làm việc như thế nào mà hãy xem khả năng thần kỳ của nó như là một điệu gizmo có thể làm những người coi nó là bạn sửng sốt và làm điên đầu các những người đối lập.
Thay vì đi sâu vào chi tiết, chúng tôi đưa ra phác thảo cách làm việc của các hiệu ứng chuyên biệt. Sau khi sử dụng lặp lại nhiều lần, từ từ bạn sẽ hiểu từng mẹo một, và thực hiện được những việc mà mình muốn làm.
.Bản dịch
- - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Tiếng Trung Quốc (Giản thể)]: dịch bởi JunJie, Meng and JiangWei.
- - link:/~blynn/gitmagic/intl/es/[Tiếng Tây Ban Nha]: dịch bởi Rodrigo Toledo và Ariset Llerena Tapia.
- - link:/~blynn/gitmagic/intl/de/[Tiếng Đức]: dịch bởi Benjamin Bellee and Armin Stebich. Armin xuất bản http://gitmagic.lordofbikes.de/[bản dịch tiếng Đức trên website của chính mình].
- - link:/~blynn/gitmagic/intl/ru/[Tiếng Nga]: dịch bởi Tikhon Tarnavsky, Mikhail Dymskov, và một số người khác.
- - link:/~blynn/gitmagic/intl/fr/[Tiếng Pháp]: dịch bởi Alexandre Garel. Và đồng thời được xuất bản tại http://tutoriels.itaapy.com/[itaapy].
+ - link:/\~blynn/gitmagic/intl/zh_cn/[Tiếng Trung Giản thể]: dịch bởi JunJie, Meng và JiangWei. Đã chuyển đổi sang:/~blynn/gitmagic/intl/zh_tw/[Tiếng Trung Phồn thể] thông qua lệnh +cconv -f UTF8-CN -t UTF8-TW+.
+ - link:/~blynn/gitmagic/intl/fr/[Tiếng Pháp]: dịch bởi Alexandre Garel; và đồng thời được xuất bản tại http://tutoriels.itaapy.com/[itaapy].
+ - link:/~blynn/gitmagic/intl/de/[Tiếng Đức]: dịch bởi Benjamin Bellee và Armin Stebich. Armin ; và đồng thời xuất bản http://gitmagic.lordofbikes.de/[bản dịch tiếng Đức trên website của chính mình].
- http://www.slideshare.net/slide_user/magia-git[Tiếng Bồ Đào Nha]: dịch bởi Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[định dạng ODT]].
- - link:/~blynn/gitmagic/intl/vi/[Tiếng Việt]: dịch bởi Trần Ngọc Quân và đồng thời xuất bản http://vnwildman.users.sourceforge.net/gitmagic.html[bản dịch này trên trang Web cá nhân của mình].
+ - link:/~blynn/gitmagic/intl/ru/[Tiếng Nga]: dịch bởi Tikhon Tarnavsky, Mikhail Dymskov và một số người khác.
+ - link:/~blynn/gitmagic/intl/es/[Tiếng Tây Ban Nha]: dịch bởi Rodrigo Toledo và Ariset Llerena Tapia.
+ - link:/~blynn/gitmagic/intl/vi/[Tiếng Việt]: dịch bởi Trần Ngọc Quân và đồng thời xuất bản bản dịch này trên http://vnwildman.users.sourceforge.net/gitmagic.html[trang Web cá nhân của mình].
.Các định dạng khác
- link:book.html[Trang web đơn]: định dạng HTML đơn giản, không định dạng bằng CSS.
- link:book.pdf[Định dạng PDF]: thuận tiện cho việc in ấn.
- - http://packages.debian.org/gitmagic[gói dành cho Debian], http:://packages.ubuntu.com/gitmagic[gói dành cho Ubuntu]: cài tự động tại địa chỉ này. Làm thủ công tại http://csdcf.stanford.edu/status/[khi bạn không có kết nối mạng].
+ - http://packages.debian.org/gitmagic[Gói dành cho Debian], http:://packages.ubuntu.com/gitmagic[gói dành cho Ubuntu]: cài tự động tại địa chỉ này. Hay tải về và cài đặt thủ công tại http://csdcf.stanford.edu/status/[đây] khi bạn không nối mạng.
- http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[Sách giấy [Amazon.com]]: 64 trang, 15.24cm x 22.86cm, đen trắng. Rất tiện sử dụng vì chẳng cần đến điện.
=== Lời cảm ơn! ===
+Tôi gửi lời cảm ơn đến những người đã dịch quyển sách này.
+Tôi rất cảm kích vì có được số lượng độc giả rộng lớn có được bởi những người
+đã được nêu tên ở trên.
+
Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin, và Tyler Breisacher đã đóng góp trong việc sửa chữa và cải tiến.
François Marier đã bảo trì gói Debian do Daniel
Baumann khởi xướng.
-JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues,
-Benjamin Bellee, Armin Stebich và Trần Ngọc Quân đã dịch bản hướng dẫn này.
-
-Tôi cũng gửi lời cảm ơn tới sự giúp đỡ và sự tán dương của các bạn. Tôi muốn
-trích dẫn lời các bạn ra ở đây, nhưng làm như thế có vẻ hơi lố bịch.
+Tôi cũng gửi lời cảm ơn tới sự giúp đỡ và sự tán dương của các bạn. Tôi muốn
+trích dẫn ra ở đây, nhưng làm như thế có vẻ hơi lố bịch.
Nếu tôi có sai sót gì, xin hãy thông tin hay gửi bản vá cho tôi!
@@ -48,14 +49,14 @@ Nếu tôi có sai sót gì, xin hãy thông tin hay gửi bản vá cho tôi!
- http://gitorious.org/[http://gitorious.org/] là một địa chỉ lưu giữ Git khác nhằm vào các dự án nguồn mở.
- http://github.com/[http://github.com/] lưu giữ các dự án nguồn mở miễn phí, và dự án riêng có thu phí.
-Trân thành cảm ơn các địa chỉ đã lưu giữ bản hướng dẫn này.
+Trân thành cảm ơn các máy chủ đã lưu giữ bản hướng dẫn này.
=== Giấy phép sử dụng ===
-Hướng dẫn này được phát hành dựa trên giấy phép http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License version 3]. Đương nhiên, nội dung của cuốn sách được lưu giữ trong kho Git,
+Hướng dẫn này được phát hành dựa trên Giấy Ghép Công phiên bản 3 http://www.gnu.org/licenses/gpl-3.0.html[the GNU General Public License version 3]. Đương nhiên, nội dung của quyển sách được quản lý bằng Git,
và bạn có thể dễ dàng có được nó bằng cách gõ:
- $ git clone git://repo.or.cz/gitmagic.git # Tạo thư mục "gitmagic".
+ $ git clone git://repo.or.cz/gitmagic.git # Tạo ra thư mục "gitmagic".
hay từ các kho chứa khác:
View
20 vi/secrets.txt
@@ -1,6 +1,6 @@
-== Các Mật ==
+== Bí Quyết của Git ==
-Chúng ta mổ xẻ để hiểu được làm thế nào mà Git có thể thi hành kỳ diệu như vậy. Tôi sẽ không thể nói quá chi tiết được. Nếu bạn muốn có được sự mô tả chỉ tiết thì hãy đọc http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[sổ tay].
+Chúng ta mổ xẻ để hiểu được làm thế nào mà Git có thể thi hành kỳ diệu như vậy. Tôi sẽ không thể nói quá chi tiết được. Nếu bạn muốn có được sự mô tả chỉ tiết thì hãy đọc http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[sổ tay hướng dẫn sử dụng Git].
=== Tính Ẩn ===
@@ -8,9 +8,9 @@ Git làm việc có vẻ kín đáo? Chỉ cần nói riêng về việc sử d
Các hệ thống quản lý mã nguồn khác ép buộc bạn luôn luôn phải tranh đấu với thói quan liêu. Quyền truy cập của các tệp tin có thể là chỉ cho phép đọc trừ phi bạn nói rõ với máy chủ trung tâm là các tệp tin nào bạn muốn chỉnh sửa. Tốc độ làm việc của phần lớn các lệnh sẽ tỷ lệ nghịch với số lượng người sử dụng. Mọi công việc sẽ đình trệ khi mạng máy tính hay máy chủ ngừng hoạt động.
-Đối lập với hạn chế trên, Git đơn giản giữ lịch sử của dự án của bạn trong thư mục `.git` trong thư mục làm việc của bạn. Đây là bản sao lịch sử của riêng bạn, do vậy bạn có thể làm việc không cần mạng cho đến khi cần truyền thông với những người khác. Bạn có toàn quyền quyết định với các tệp tin của mình bởi vì Git có thể tạo lại trạng thái đã ghi lại từ `.git` bất kỳ lúc nào một cách dễ dàng.
+Đối lập với hạn chế trên, Git đơn giản giữ lịch sử của dự án của bạn tại thư mục `.git` trong thư mục làm việc của bạn. Đây là bản sao lịch sử của riêng bạn, do vậy bạn có thể làm việc không cần mạng cho đến khi cần truyền thông với những người khác. Bạn có toàn quyền quyết định với các tệp tin của mình bởi vì Git có thể tạo lại trạng thái đã ghi lại từ `.git` bất kỳ lúc nào một cách dễ dàng.
-=== Tính Toàn Vẹn ===
+=== Toàn Vẹn Dữ Liệu ===
Phần lớn mọi người sử dụng phương pháp mã hóa để giữ cho thông tin của mình không bị nhòm ngó, nhưng có thứ quan trọng không kém đó là giữ cho thông tin của mình được toàn vẹn. Chính việc sử dụng hàm băm mã hóa đã làm ngăn ngừa sự sai hỏng dữ liệu do rủi ro hay ác ý.