Переклад book/10-git-internals/sections/refs.asc

book/10-git-internals/sections/refs.asc

@@ -1,11 +1,11 @@
 [[_git_refs]]
-=== Git References
+=== Посилання Git
 
-You can run something like `git log 1a410e` to look through your whole history, but you still have to remember that `1a410e` is the last commit in order to walk that history to find all those objects.
-You need a file in which you can store the SHA-1 value under a simple name so you can use that pointer rather than the raw SHA-1 value.
+Ви можете виконати щось на кшталт `git log 1a410e`, щоб продивитись усю історію, проте ви все одно маєте пам’ятати, що `1a410e` є останнім комітом, щоб пройтись по цій історії та знайти всі ці об’єкти.
+Вам потрібен файл, в якому ви будете зберігати значення SHA-1 під простим ім’ям, щоб ви могли використати цей вказівник замість сирого значення SHA-1.
 
-In Git, these are called ``references'' or ``refs;'' you can find the files that contain the SHA-1 values in the `.git/refs` directory.
-In the current project, this directory contains no files, but it does contain a simple structure:
+У Git це називається ``посилання'' (reference або ref). Ви можете знайти файли, які містять значення SHA-1 у директорії `.git/refs`.
+У поточному проекті, ця директорія не містить файлів, проте вона містить просту структуру:
 
 [source,console]
 ----
@@ -16,14 +16,14 @@ $ find .git/refs
 $ find .git/refs -type f
 ----
 
-To create a new reference that will help you remember where your latest commit is, you can technically do something as simple as this:
+Щоб створити нове посилання, яке допоможе вам пам’ятати, де знаходиться ваш останній коміт, ви технічно можете зробити щось настільки просте:
 
 [source,console]
 ----
 $ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 ----
 
-Now, you can use the head reference you just created instead of the SHA-1 value in your Git commands:
+Тепер, ви можете використати щойно створене посилання замість значення SHA-1 у командах Git:
 
 [source,console]
 ----
@@ -33,23 +33,23 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-You aren't encouraged to directly edit the reference files.
-Git provides a safer command to do this if you want to update a reference called `update-ref`:
+Ми не заохочуємо вас редагувати файли посилань напряму.
+Git надає безпечнішу команду для цього, якщо ви бажаєте оновити посилання, під назвою `update-ref`:
 
 [source,console]
 ----
 $ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 ----
 
-That's basically what a branch in Git is: a simple pointer or reference to the head of a line of work.
-To create a branch back at the second commit, you can do this:
+В основі, це і є гілкою в Git: простий вказівник чи посилання на верхівку лінії роботи.
+Щоб створити гілку з другого коміту, ви можете зробити наступне:
 
 [source,console]
 ----
 $ git update-ref refs/heads/test cac0ca
 ----
 
-Your branch will contain only work from that commit down:
+Ваша гілка буде містити лише роботу з цього коміту й попередню:
 
 [source,console]
 ----
@@ -58,49 +58,49 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-Now, your Git database conceptually looks something like this:
+Тепер, ваша база даних Git концептуально виглядає так:
 
-.Git directory objects with branch head references included.
-image::images/data-model-4.png[Git directory objects with branch head references included.]
+.Об’єкти директорії Git, включно з посиланнями гілок.
+image::images/data-model-4.png[Об’єкти директорії Git, включно з посиланнями гілок.]
 
-When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create.
+Коли ви виконуєте такі команди як `git branch (ім’я гілки)`, Git по суті виконує команду `update-ref`, щоб додати SHA-1 останнього коміту поточної гілки до якого забажаєте нового посилання.
 
 [[_the_head]]
-==== The HEAD
+==== HEAD
 
-The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit?
-The answer is the HEAD file.
+Тепер питання в тому, як Git дізнається SHA-1 останнього коміту, коли ви виконуєте `git branch (ім’я гілки)`?
+Відповідь у файлі HEAD.
 
-The HEAD file is a symbolic reference to the branch you're currently on.
-By symbolic reference, we mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference.
-If you look at the file, you'll normally see something like this:
+Файл HEAD -- це символічне посилання на поточну гілку.
+Під символічним посиланням, ми маємо на увазі, що, на відміну від звичайного посилання, воно зазвичай не містить значення SHA-1, а натомість вказівник на інше посилання.
+Якщо ви подивитесь на цей файл, то зазвичай побачите щось таке:
 
 [source,console]
 ----
 $ cat .git/HEAD
 ref: refs/heads/master
 ----
 
-If you run `git checkout test`, Git updates the file to look like this:
+Якщо виконати `git checkout test`, Git оновлює цей файл наступним чином:
 
 [source,console]
 ----
 $ cat .git/HEAD
 ref: refs/heads/test
 ----
 
-When you run `git commit`, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to.
+Коли ви виконуєте `git commit`, він створює об’єкт коміту, якому встановлює батьківській коміт у те значення SHA-1, на яке вказує посилання, на яке вказує HEAD.
 
-You can also manually edit this file, but again a safer command exists to do so: `symbolic-ref`.
-You can read the value of your HEAD via this command:
+Ви також можете вручну редагувати цей файл, проте знову таки, існує безпечніша команда: `symbolic-ref`.
+Ви можете зчитати значення HEAD за допомогою цієї команди:
 
 [source,console]
 ----
 $ git symbolic-ref HEAD
 refs/heads/master
 ----
 
-You can also set the value of HEAD:
+Ви також можете встановити значення HEAD:
 
 [source,console]
 ----
@@ -109,48 +109,48 @@ $ cat .git/HEAD
 ref: refs/heads/test
 ----
 
-You can't set a symbolic reference outside of the refs style:
+Ви не можете встановлювати символічні посилання поза стилем refs:
 
 [source,console]
 ----
 $ git symbolic-ref HEAD test
 fatal: Refusing to point HEAD outside of refs/
 ----
 
-==== Tags
+==== Теґи
 
-We just finished discussing Git's three main object types, but there is a fourth.
-The tag object is very much like a commit object – it contains a tagger, a date, a message, and a pointer.
-The main difference is that a tag object generally points to a commit rather than a tree.
-It's like a branch reference, but it never moves – it always points to the same commit but gives it a friendlier name.
+Ми щойно завершили обговорення трьох головних типів об’єктів Git, проте існує четвертий.
+Об’єкт теґ дуже схожий на об’єкт коміт – він містить автора теґу, дату, повідомлення та вказівник.
+Головна різниця в тому, що об’єкт теґ вказує на коміт, а не на дерево.
+Це схоже на посилання гілки, проте воно ніколи не переміщується – завжди вказує на один коміт, проте надає йому зрозуміліше ім’я.
 
-As discussed in <<_git_basics_chapter>>, there are two types of tags: annotated and lightweight.
-You can make a lightweight tag by running something like this:
+Як вже обговорено в <<_git_basics_chapter>>, існують два головних типи теґів: анотовані та легкі.
+Ви можете створити легкий теґ, якщо виконаєте щось таке:
 
 [source,console]
 ----
 $ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 ----
 
-That is all a lightweight tag is – a reference that never moves.
-An annotated tag is more complex, however.
-If you create an annotated tag, Git creates a tag object and then writes a reference to point to it rather than directly to the commit.
-You can see this by creating an annotated tag (`-a` specifies that it's an annotated tag):
+Це і є легкий теґ – посилання, яке ніколи не змінюється.
+Анотований тег, втім, складніший.
+Якщо ви створите анотований теґ, Git створить об’єкт теґ, а потім запише посилання, яке вказує на нього, а не на сам коміт.
+Ви можете побачити це, якщо створите анотований теґ (`-a` означає, що це буде анотований теґ):
 
 [source,console]
 ----
 $ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
 ----
 
-Here's the object SHA-1 value it created:
+Ось значення SHA-1 створеного об’єкту:
 
 [source,console]
 ----
 $ cat .git/refs/tags/v1.1
 9585191f37f7b0fb9444f35a9bf50de191beadc2
 ----
 
-Now, run the `cat-file` command on that SHA-1 value:
+Тепер, виконайте команду `cat-file` для цього значення SHA-1:
 
 [source,console]
 ----
@@ -163,23 +163,23 @@ tagger Scott Chacon <schacon@gmail.com> Sat May 23 16:48:58 2009 -0700
 test tag
 ----
 
-Notice that the object entry points to the commit SHA-1 value that you tagged.
-Also notice that it doesn't need to point to a commit; you can tag any Git object.
-In the Git source code, for example, the maintainer has added their GPG public key as a blob object and then tagged it.
-You can view the public key by running this in a clone of the Git repository:
+Завважте, що елемент object вказує на значення SHA-1 коміту, який ви позначили теґом.
+Також зверніть увагу, що це не обов’язково має бути коміт; ви можете створити теґ для будь-якого об’єкту Git.
+Наприклад, у вихідному коді Git, супроводжувач додав свій публічний ключ GPG як блоб та створив для нього теґ.
+Ви можете відобразити публічний ключ, якщо виконаєте наступне після клонування Git репозиторію:
 
 [source,console]
 ----
 $ git cat-file blob junio-gpg-pub
 ----
 
-The Linux kernel repository also has a non-commit-pointing tag object – the first tag created points to the initial tree of the import of the source code.
+Репозиторій ядра Linux  також має об’єкт теґ, який вказує не на коміт – перший створений теґ вказує на початкове дерево імпорту вихідного коду.
 
-==== Remotes
+==== Віддалені посилання
 
-The third type of reference that you'll see is a remote reference.
-If you add a remote and push to it, Git stores the value you last pushed to that remote for each branch in the `refs/remotes` directory.
-For instance, you can add a remote called `origin` and push your `master` branch to it:
+Третій тип посилань, які вам зустрінуться -- це віддалені посилання.
+Якщо ви додасте віддалене сховище та надішлете до нього зміни, Git збереже значення, яке ви востаннє надсилали, для кожної гілки в директорії `refs/remotes`.
+Наприклад, ви можете додати віддалене сховище під назвою `origin` та надіслати до нього свій `master`:
 
 [source,console]
 ----
@@ -193,14 +193,14 @@ To git@github.com:schacon/simplegit-progit.git
   a11bef0..ca82a6d  master -> master
 ----
 
-Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file:
+Потім, ви можете бачити, якою була гілка `master` віддаленого сховища `origin`, коли ви востаннє взаємодіяли зі сервером, перевіривши файл `refs/remotes/origin/master`:
 
 [source,console]
 ----
 $ cat .git/refs/remotes/origin/master
 ca82a6dff817ec66f44342007202690a93763949
 ----
 
-Remote references differ from branches (`refs/heads` references) mainly in that they're considered read-only.
-You can `git checkout` to one, but Git won't point HEAD at one, so you'll never update it with a `commit` command.
-Git manages them as bookmarks to the last known state of where those branches were on those servers.
+Віддалені посилання відрізняються від гілок (посилань `refs/heads`) головним чином тим, що вважаються доступними лише для читання.
+Ви можете переключитись на нього, проте Git не переключить туди HEAD, отже ви ніколи його не обновите за допомогою команди `commit`.
+Git вважає їх закладками на останній відомий стан того, де були ці гілки на цих серверах.

status.json

@@ -103,7 +103,7 @@
       "sections/objects.asc": 0,
       "sections/packfiles.asc": 0,
       "sections/plumbing-porcelain.asc": 100,
-      "sections/refs.asc": 0,
+      "sections/refs.asc": 100,
       "sections/refspec.asc": 0,
       "sections/transfer-protocols.asc": 0
     },