From 00050977912268994cf391f26d2094b61712fe01 Mon Sep 17 00:00:00 2001 From: =?utf8?q?=D0=92=D0=BE=D0=BB=D0=BE=D0=B4=D0=B8=D0=BC=D0=B8=D1=80=20?= =?utf8?q?=D0=91=D0=BE=D0=B4=D0=B5=D0=BD=D1=87=D1=83=D0=BA?= Date: Wed, 26 Dec 2012 15:53:23 +0200 Subject: [PATCH] translation completed --- uk/drawbacks.txt | 8 ++++---- uk/grandmaster.txt | 4 ++-- uk/history.txt | 60 +++++++++++++++++++++++++++--------------------------- uk/multiplayer.txt | 20 +++++++++--------- uk/secrets.txt | 6 +++--- 5 files changed, 49 insertions(+), 49 deletions(-) diff --git a/uk/drawbacks.txt b/uk/drawbacks.txt index ed6b5fc..0930986 100644 --- a/uk/drawbacks.txt +++ b/uk/drawbacks.txt @@ -1,6 +1,6 @@ == Додаток A: Недоліки Git == -Є деякі проблеми Git, які я сховав під сукно. Деякі з них можна легко вирішити за допомогою скриптів і хуків, деякі вимагають реорганізації або перегляду проекту, а кілька неприємностей, що залишилися, доведеться потерпіти. А ще краще - взятися за них і вирішити! +Є деякі проблеми Git, які я сховав під сукно. Деякі з них можна легко вирішити за допомогою скриптів і хуків, деякі вимагають реорганізації або перегляду проекту, а кілька неприємностей, що залишилися, доведеться потерпіти. А ще краще — взятися за них і вирішити! === Слабкі сторони SHA1 === @@ -56,9 +56,9 @@ Git був написаний, щоб бути швидким при відно Якщо файли дійсно повинні постійно змінюватися і при цьому версіонуватися, може мати сенс використовувати Git централізованим чином. Можна створювати дрібні клони, з невеликою історією або без історії взагалі. Звичайно, багато інструментів Git будуть недоступні, і виправлення доведеться подавати у вигляді патчів. Можливо, це і добре, тому що неясно, навіщо комусь знадобиться історія вкрай нестабільних файлів. -Інший приклад - це проект, залежний від прошивки, приймаючої форму величезного двійкового файлу. Її історія нецікава користувачам, а поновлення погано стискаються, тому ревізії прошивки будуть невиправдано роздувати розмір сховища. +Інший приклад — це проект, залежний від прошивки, приймаючої форму величезного двійкового файлу. Її історія нецікава користувачам, а поновлення погано стискаються, тому ревізії прошивки будуть невиправдано роздувати розмір сховища. -У цьому випадку вихідний код варто тримати в сховищі Git, а бінарні файли - окремо. Для спрощення життя можна поширювати скрипт, який використовує Git для клонування коду та rsync або дрібний клон Git для прошивки. +У цьому випадку вихідний код варто тримати в сховищі Git, а бінарні файли — окремо. Для спрощення життя можна поширювати скрипт, який використовує Git для клонування коду та rsync або дрібний клон Git для прошивки. === Глобальний лічильник === @@ -82,7 +82,7 @@ Git'у було б вигідно визначити нульовий коммі Тоді запуск *git log*, наприклад, показував би користувачеві, що комміти ще не були зроблені, замість того щоб завершуватися з фатальною помилкою. Аналогічно для інших інструментів. -Кожен початковий комміт - неявний нащадок цього нульового комміта. +Кожен початковий комміт — неявний нащадок цього нульового комміта. Однак тут, на жаль, є деякі проблемні випадки. Якщо кілька гілок з різними початковими коммітами зливаються, то rebase результату вимагає значного ручного втручання. diff --git a/uk/grandmaster.txt b/uk/grandmaster.txt index 0bb9a66..00f9a79 100644 --- a/uk/grandmaster.txt +++ b/uk/grandmaster.txt @@ -41,7 +41,7 @@ Git прогляне файли в поточному каталозі і сам Що робити, якщо ви змінили безліч файлів в багатьох місцях? Перевірка кожної окремої зміни стає обтяжливою рутиною. У цьому випадку використовуйте *git add -i*. Її інтерфейс не такий простий, але більш гнучкий. У декілька натискань можна додати або прибрати з буфера кілька файлів одночасно, або переглянути і вибрати зміни лише в окремих файлах. Як варіант, запустіть *git commit \--interactive*, яка автоматично зробить комміт коли ви закінчите. -=== Індекс - буферна зона Git === +=== Індекс — буферна зона Git === До цих пір ми уникали знаменитого 'індексу' Git, але тепер ми повинні розглянути його, для пояснення вищесказаного. Індекс це тимчасовий буфер. Git рідко переміщує дані безпосередньо між вашим проектом і його історією. Замість цього Git спочатку записує дані в індекс, а вже потім копіює їх з індексу за місцем призначення. @@ -110,7 +110,7 @@ Git записує кожен підрахований ним хеш коммі $ git config --global alias.co checkout $ git config --global --get-regexp alias # відображає поточні аліаси alias.co checkout - $ git co foo # те ж саме, що і 'git checkout foo' + $ git co foo # те ж саме, що і 'git checkout foo' Інший приклад: можна виводити поточну гілку в запрошенні командного рядка або заголовку вікна терміналу. Запуск diff --git a/uk/history.txt b/uk/history.txt index 16f9653..157c4f3 100644 --- a/uk/history.txt +++ b/uk/history.txt @@ -3,11 +3,11 @@ Внаслідок розподіленої природи Git, історію змін можна легко редагувати. Однак, якщо ви втручаєтеся в минуле, будьте обережні: змінюйте тільки ту частину історії, якою володієте ви і тільки ви. Інакше, як народи вічно з'ясовують, хто ж саме зробив і які безчинства, так і у вас будуть проблеми з примиренням при спробі поєднати різні дерева історії. Деякі розробники переконані, що історія повинна бути незмінна з усіма огріхами та іншим. Інші вважають, що дерева потрібно робити презентабельними перед випуском їх у публічний доступ. -Git враховує обидві думки. Переписування історії, як і клонування, розгалуження і злиття, – лише ще одна можливість, яку дає вам Git. Розумне її використання залежить тільки від вас. +Git враховує обидві думки. Переписування історії, як і клонування, розгалуження і злиття, — лише ще одна можливість, яку дає вам Git. Розумне її використання залежить тільки від вас. === Залишаючись коректним === -Тільки що зробили комміт і зрозуміли, що повинні були ввести інший опис? запустіть +Щойно зробили комміт і зрозуміли, що повинні були ввести інший опис? Запустіть $ git commit --amend @@ -19,11 +19,11 @@ Git враховує обидві думки. Переписування іст === …І ще дещо === -Давайте уявимо, що попередня проблема насправді в десять разів гірше. Після тривалої роботи ви зробили ряд коммітов, але ви не дуже-то задоволені тим, як вони організовані, і деякі описи коммітів треба б злегка переформулювати. Тоді запустіть +Давайте уявимо, що попередня проблема насправді в десять разів гірше. Після тривалої роботи ви зробили ряд коммітів, але ви не дуже-то задоволені тим, як вони організовані, і деякі описи коммітів треба б злегка переформулювати. Тоді запустіть $ git rebase -i HEAD~10 -і останні десять коммітов з'являться у вашому улюбленому редакторі (задається змінною оточення $EDITOR). Наприклад: +і останні десять коммітів з’являться у вашому улюбленому редакторі (задається змінною оточення $EDITOR). Наприклад: pick 5c6eb73 Додав посилання repo.or.cz pick a311a64 Переставив аналогії в „Працюй як хочеш“ @@ -33,12 +33,12 @@ Git враховує обидві думки. Переписування іст Тут, 5c6eb73 є найстарішим коммітом і 100834f є найновішим. Тепер ви можете: - Видаляти комміти шляхом видалення рядків. Подібно команді revert, але видаляє запис: це буде так ніби комміта ніколи не існувало. -- Міняти порядок коммітов, переставляючи рядки. +- Міняти порядок коммітів, переставляючи рядки. - Заміняти `pick` на: - * `edit` щоб позначати комміт для внесення правок; - * `reword` щоб змінити опис у журналі; - * `squash` щоб злити комміт з попереднім; - * `fixup` щоб злити комміт з попереднім і відкинути його опис. + * `edit`, щоб позначати комміт для внесення правок; + * `reword`, щоб змінити опис у журналі; + * `squash`, щоб злити комміт з попереднім; + * `fixup`, щоб злити комміт з попереднім і відкинути його опис. Наприклад, ми могли б замінити другий `pick` з `squash`: @@ -47,9 +47,9 @@ Git враховує обидві думки. Переписування іст pick 100834f Додав ціль для push в Makefile Після того, як ми збережемо і вийдемо, Git зіллє a311a64 у 5c6eb73. Так *squash* зливає -у наступний комміт: think ``squash up''. +у наступний комміт вгорі: думайте ``squash up''. -Тоді Git then об’єднує повідомлення журналу і і подає їх для редагування. Команда +Тоді Git об’єднує повідомлення журналу і подає їх для редагування. Команда *fixup* пропускає цей етап; злиті повідомлення журналу просто відкидаються. Якщо ви позначили комміт командою *edit*, Git поверне вас в минуле, до найстарішого такого комміта. @@ -58,29 +58,29 @@ Git враховує обидві думки. Переписування іст $ git rebase --continue -Git виводить комміти доти, поки буде наступний *edit* або не залишиться нічого. +Git виводить комміти до наступного *edit* або до поточного, якщо не залишиться нічого. Ви також можете відмовитися від перебазування (rebase) з: $ git rebase --abort -Одним словом, робіть комміти якомога раніше і якомога частіше - ви завжди зможете навести порядок за допомогою rebase. +Одним словом, робіть комміти раніше і частіше — ви завжди зможете навести порядок за допомогою rebase. === Локальні зміни зберігаються === -Припустимо, ви працюєте над активним проектом. За якийсь час ви робите кілька коммітов, потім синхронізуєте з офіційним деревом через злиття. Цикл повторюється кілька разів, поки ви не будете готові влити зміни в центральне дерево. +Припустимо, ви працюєте над активним проектом. За якийсь час ви робите кілька коммітів, потім синхронізуєте з офіційним деревом через злиття. Цикл повторюється кілька разів, поки ви не будете готові влити зміни в центральне дерево. -Проте тепер історія змін в локальному клоні Git являє собою кашу з ваших та офіційних змін. Вам би хотілося бачити всі свої зміни неперервною лінією, а потім - всі офіційні зміни. +Проте тепер історія змін в локальному клоні Git являє собою кашу з ваших та офіційних змін. Вам би хотілося бачити всі свої зміни неперервною лінією, а потім — всі офіційні зміни. -Це робота для команди *git rebase*, як описано вище. Найчастіше, має сенс використовувати прапор *--onto*, щоб прибрати переплетення. +Це робота для команди *git rebase*, як описано вище. Найчастіше, має сенс використовувати опцію *--onto*, щоб прибрати переплетення. Також дивіться *git help rebase* для отримання детальних прикладів використання цієї чудової команди. Ви можете розщеплювати комміти. Ви можете навіть змінювати порядок гілок у дереві. -Будьте обережні: rebase – це потужна команда. Для складних rebases, спочатку зробіть резервну копію за допомогою *git clone*. +Будьте обережні: rebase — це потужна команда. Для складних rebases, спочатку зробіть резервну копію за допомогою *git clone*. === Переписуючи історію === -Іноді вам може знадобитися в системі управління версіями аналог «замазування» людей на офіційних фотографіях, як би стираючого їх з історії в дусі сталінізму. Наприклад, припустимо, що ми вже збираємося випустити реліз проекту, але він містить файл, який не повинен стати надбанням громадськості з якихось причин. Можливо, я зберіг номер своєї кредитки в текстовий файл і випадково додав його в проект. Видалити файл недостатньо: він може бути доступний з старих коммітів. Нам треба видалити файл з усіх ревізій: +Іноді вам може знадобитися в системі керування версіями аналог «замазування» людей на офіційних фотографіях, як би стираючого їх з історії в дусі сталінізму. Наприклад, припустимо, що ми вже збираємося випустити реліз проекту, але він містить файл, який не повинен стати надбанням громадськості з якихось причин. Можливо, я зберіг номер своєї кредитки в текстовий файл і випадково додав його в проект. Видалити файл недостатньо: він може бути доступним зі старих коммітів. Нам треба видалити файл з усіх ревізій: $ git filter-branch --tree-filter 'rm цілком/таємний/файл' HEAD @@ -88,9 +88,9 @@ Git виводить комміти доти, поки буде наступни Після цієї команди каталог +.git/refs/original+ буде описувати стан, який був до її виклику. Переконайтеся, що команда filter-branch зробила те, що ви хотіли, і якщо хочете знову використовувати цю команду, видаліть цей каталог. -І, нарешті, замініть клони вашого проекту виправленої версією, якщо збираєтеся надалі з ними працювати. +І, нарешті, замініть клони вашого проекту виправленою версією, якщо збираєтеся надалі з ними працювати. -=== Створюючи Історію === +=== Створюючи історію === [[makinghistory]] Хочете перевести проект під управління Git? Якщо зараз він знаходиться під управлінням якоїсь із добре відомих систем керування версіями, то цілком імовірно, що хтось вже написав необхідні скрипти для експорту всієї історії проекту в Git. @@ -135,8 +135,8 @@ EOT Потім створіть сховище Git з цього тимчасового файлу за допомогою команд: -$ mkdir project; cd project; git init -$ git fast-import --date-format=rfc2822 < /tmp/history + $ mkdir project; cd project; git init + $ git fast-import --date-format=rfc2822 < /tmp/history Ви можете витягти останню версію проекту за допомогою @@ -146,7 +146,7 @@ $ git fast-import --date-format=rfc2822 < /tmp/history === Коли ж все пішло не так? === -Ви тільки що виявили, що деякий функціонал вашої програми не працює, але ви зовсім чітко пам'ятаєте, що він працював лише кілька місяців тому. Ох ... Звідки ж взялася помилка? Ви ж це перевіряли відразу як розробили. +Ви тільки що виявили, що деякий функціонал вашої програми не працює, але ви досить чітко пам’ятаєте, що він працював лише кілька місяців тому. Ох ... Звідки ж взялася помилка? Ви ж це перевіряли відразу як розробили. У будь-якому випадку, вже надто пізно. Однак, якщо ви фіксували свої зміни досить часто, то Git зможе точно вказати проблему: @@ -176,18 +176,18 @@ Git витягне стан рівно посередині. Перевірте $ git blame bug.c -Вона забезпечує кожен рядок вибраного файлу примітками, що розкривають, хто і коли останнім її редагував. На відміну ж від багатьох інших систем управління версіями, ця операція відбувається без з'єднання з мережею, вибираючи дані з локального диску. +Вона забезпечує кожен рядок вибраного файлу примітками, що розкривають, хто і коли останнім його редагував. На відміну ж від багатьох інших систем керування версіями, ця операція відбувається без з’єднання з мережею, вибираючи дані з локального диску. === Особистий досвід === -У централізованих системах керування версіями зміни історії - досить складна операція, і доступна вона лише адміністраторам. Клонування, розгалуження і злиття неможливі без взаємодії по мережі. Так само йдуть справи і з базовими операціями, такими як перегляд історії або фіксація змін. У деяких системах мережеве з'єднання потрібне навіть для перегляду власних змін, або відкриття файлу для редагування. +У централізованих системах керування версіями зміни історії — досить складна операція, і доступна вона лише адміністраторам. Клонування, розгалуження і злиття неможливі без взаємодії по мережі. Так само йдуть справи і з базовими операціями, такими як перегляд історії або фіксація змін. У деяких системах мережеве з’єднання потрібне навіть для перегляду власних змін, або відкриття файлу для редагування. -Централізовані системи виключають можливість роботи без мережі і вимагають більш дорогої мережевої інфраструктури, особливо із збільшенням кількості розробників. Що важливіше, всі операції відбуваються повільніше, зазвичай до такої міри, що користувачі уникають користування «просунутими» командами без крайньої необхідності. У радикальних випадках це стосується навіть більшості базових команд. Коли користувачі змушені запускати повільні команди, продуктивність страждає через переривання робочого процесу. +Централізовані системи виключають можливість роботи без мережі і вимагають більш дорогої мережевої інфраструктури, особливо із збільшенням кількості розробників. Що важливіше, всі операції відбуваються повільніше, зазвичай до такої міри, що користувачі уникають користування „просунутими“ командами без крайньої необхідності. У радикальних випадках це стосується навіть більшості базових команд. Коли користувачі змушені запускати повільні команди, продуктивність страждає через переривання робочого процесу. -Я відчув цей феномен на собі. Git був моєю першою системою керування версіями. Я швидко звик до нього і став відноситься до його можливостей як до належного. Я припускав, що й інші системи схожі на нього: вибір системи управління версіями не повинен відрізнятися від вибору текстового редактора або переглядача. +Я відчув цей феномен на собі. Git був моєю першою системою керування версіями. Я швидко звик до нього і став відноситься до його можливостей як до належного. Я припускав, що й інші системи схожі на нього: вибір системи керування версіями не повинен відрізнятися від вибору текстового редактора або переглядача. -Коли трохи пізніше я був змушений використовувати централізовану систему управління версіями, я був шокований. Ненадійне інтернет-з'єднання не має великого значення при використанні Git, але робить розробку нестерпною, коли від нього вимагають надійності як у жорсткого диска. На додачу я виявив, що став уникати деяких команд через затримку у їх виконанні, що завадило мені дотримуватися кращого робочого процесу. +Коли трохи пізніше я був змушений використовувати централізовану систему керування версіями, я був шокований. Ненадійне інтернет-з’єднання не має великого значення при використанні Git, але робить розробку нестерпною, коли від нього вимагають надійності як у жорсткого диска. На додачу я виявив, що став уникати деяких команд через затримку у їх виконанні, що завадило мені дотримуватися кращого робочого процесу. -Коли мені було потрібно запустити повільну команду, порушення ходу моїх думок надавало несумірний збиток розробці. Чекаючи закінчення зв'язку з сервером, я змушений був займатися чимось іншим, щоб згаяти час; наприклад, перевіркою пошти або написанням документації. До того часу, як я повертався до початкової задачі, виконання команди було давно закінчено, але мені доводилося витрачати багато часу, щоб згадати, що саме я робив. Люди не дуже пристосовані для перемикання між завданнями. +Коли мені було потрібно запустити повільну команду, порушення ходу моїх думок надавало несумірний збиток розробці. Чекаючи закінчення зв’язку з сервером, я змушений був займатися чимось іншим, щоб згаяти час; наприклад, перевіркою пошти або написанням документації. До того часу, як я повертався до початкової задачі, виконання команди було давно закінчено, але мені доводилося витрачати багато часу, щоб згадати, що саме я робив. Люди не дуже пристосовані для перемикання між завданнями. -Крім того, є цікавий ефект «трагедії суспільних ресурсів»: передбачаючи майбутню перевантаженість мережі, деякі люди в спробі запобігти майбутнім затримкам починають використовувати більш широкі канали, ніж їм реально потрібно для поточних завдань. Сумарна активність збільшує завантаження мережі, заохочуючи людей задіяти все більш високошвидкісні канали для запобігання ще більшим затримкам. +Крім того, є цікавий ефект „трагедії суспільних ресурсів“: передбачаючи майбутню перевантаженість мережі, деякі люди в спробі запобігти майбутнім затримкам починають використовувати більш широкі канали, ніж їм реально потрібні для поточних завдань. Сумарна активність збільшує завантаження мережі, заохочуючи людей задіяти все більш високошвидкісні канали для запобігання ще більшим затримкам. diff --git a/uk/multiplayer.txt b/uk/multiplayer.txt index 1068313..bcc9da5 100644 --- a/uk/multiplayer.txt +++ b/uk/multiplayer.txt @@ -2,7 +2,7 @@ Спочатку я використовував Git для особистого проекту, в якому був єдиним розробником. Серед команд, які відносяться до розподілених властивостей Git, мені були потрібні тільки *pull* і *clone*, щоб зберігати один і той же проект у різних місцях. -Пізніше я захотів опублікувати свій код за допомогою Git і включати зміни помічників. Мені довелося навчитися управляти проектами, в яких беруть участь багато людей по всьому світу. На щастя, в цьому сильна сторона Git і, можливо, сам сенс його існування. +Пізніше я захотів опублікувати свій код за допомогою Git і включати зміни помічників. Мені довелося навчитися керувати проектами, в яких беруть участь багато людей по всьому світу. На щастя, в цьому сильна сторона Git і, можливо, сам сенс його існування. === Хто я? === @@ -44,7 +44,7 @@ $ git bundle create деякий_файл HEAD -Потім передає пакет, +деякий_файл+, іншій команді будь-якими засобами, як то: електронна пошта, флешка, *xxd* друк і подальше розпізнавання тексту, надиктовка бітів по телефону, димові сигнали і так далі. Одержувач відновлює комміти з пакету, ввівши +Потім передає пакет, +деякий_файл+, іншій команді будь-якими засобами, такими як: електронна пошта, флешка, *xxd* друк і подальше розпізнавання тексту, надиктовка бітів по телефону, димові сигнали і так далі. Одержувач відновлює комміти з пакету, ввівши $ git pull деякий_файл @@ -64,7 +64,7 @@ === Патчі: загальне застосування === -Патчі — це тексти змін, цілком зрозумілі як для людини, так і комп'ютера. Це робить їх дуже привабливим форматом обміну. Патч можна послати розробникам по електронній пошті, незалежно від того, яку систему управління версіями вони використовують. Вашим кореспондентам достатньо можливості читати електронну пошту, щоб побачити ваші зміни. Точно так само, з Вашого боку потрібна лише адреса електронної пошти: немає потреби в налаштуванні онлайн сховища Git. +Патчі — це тексти змін, цілком зрозумілі як для людини, так і комп’ютера. Це робить їх дуже привабливим форматом обміну. Патч можна послати розробникам по електронній пошті, незалежно від того, яку систему управління версіями вони використовують. Вашим кореспондентам достатньо можливості читати електронну пошту, щоб побачити ваші зміни. Точно так само, з Вашого боку потрібна лише адреса електронної пошти: немає потреби в налаштуванні онлайн сховища Git. Пригадаємо з першого розділу: @@ -76,7 +76,7 @@ для застосування патча. -У більш формальних випадках, коли потрібно зберегти ім'я автора та підписи, створюйте відповідні патчі з заданої точки, набравши +У більш формальних випадках, коли потрібно зберегти ім’я автора та підписи, створюйте відповідні патчі з заданої точки, набравши $ git format-patch 1b6d @@ -88,7 +88,7 @@ $ git am < email.txt -Це застосує вхідні виправлення і створить комміт, що включає ім'я автора та іншу інформацію. +Це застосує вхідні виправлення і створить комміт, що включає ім’я автора та іншу інформацію. З web-інтерфейсом до електронної пошти вам, можливо, буде потрібно натиснути кнопку, щоб подивитися електронну пошту в своєму початковому вигляді перед збереженням патча в файл. @@ -128,7 +128,7 @@ origin/master origin/experimental -Ці імена відповідають гілкам і «голові» в віддаленому сховищі; їх можна використовувати в звичайних командах Git. Наприклад, ви зробили багато коммітів, і хотіли б порівняти поточний стан з останньою завантаженою версією. Ви можете шукати в журналах потрібний SHA1 хеш, але набагато легше набрати +Ці імена відповідають гілкам і „голові“ у віддаленому сховищі; їх можна використовувати в звичайних командах Git. Наприклад, ви зробили багато коммітів, і хотіли б порівняти поточний стан з останньою завантаженою версією. Ви можете шукати в журналах потрібний SHA1 хеш, але набагато легше набрати $ git diff origin/HEAD @@ -152,18 +152,18 @@ $ git fetch # Перенести із origin, типово. $ git fetch other # Перенести від другого програміста. -Так ми лише переносимо їх історію. Хоча робочий каталог залишається недоторканими, ми можемо звернутися до будь гілці в будь-якому сховищі команди, працюючої з Git, оскільки тепер у нас є локальна копія. +Так ми лише переносимо їх історію. Хоча робочий каталог залишається недоторканими, ми можемо звернутися до будь-якої гілки в будь-якому сховищі команди, працюючої з Git, оскільки тепер у нас є локальна копія. -Пригадаємо, що pull це просто *fetch*, а потім *merge*. Зазвичай ми використовуємо *pull*, тому що ми хочемо влити до себе останній комміт після отримання чужої гілки. Описана ситуація — визначний виняток. +Пригадаємо, що pull це просто *fetch*, а потім *merge*. Зазвичай ми використовуємо *pull*, тому що ми хочемо влити до себе останній комміт після отримання чужої гілки. Описана ситуація — помітний виняток. Про те, як відключити віддалені сховища, ігнорувати окремі гілки і багато іншого дивіться у *git help remote*. === Мої вподобання === -Я віддаю перевагу, щоб люди, що приєднуються до моїх проектів, створювали сховища, з яких я зможу отримувати зміни за допомогою pull. Деякі хостинги Git дозволяють створювати власні розгалуження (форки) проекту в один дотик. +Я віддаю перевагу тому, щоб люди, що приєднуються до моїх проектів, створювали сховища, з яких я зможу отримувати зміни за допомогою pull. Деякі хостинги Git дозволяють створювати власні розгалуження (форки) проекту в один дотик. Після отримання дерева з віддаленого сховища я запускаю команди Git для навігації і вивчення змін, в ідеалі добре організованих і описаних. Я роблю злиття зі своїми змінами і можливо вношу подальші правки. Коли я задоволений результатом, я заливаю зміни в головне сховище. Хоча зі мною мало співпрацюють, я вірю, що цей підхід добре масштабується. Дивіться http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[цей запис в блозі Лінуса Торвальдса]. -Залишатися в світі Git трохи зручніше, ніж використовувати файли патчів, оскільки це позбавляє мене від перетворення їх в комміти Git. Крім того, Git управляє деталями на зразок збереження імені автора та адреси електронної пошти, а також дати і часу, і просить авторів описувати свої зміни. +Залишатися в світі Git трохи зручніше, ніж використовувати файли патчів, оскільки це позбавляє мене від перетворення їх в комміти Git. Крім того, Git керує деталями на зразок збереження імені автора та адреси електронної пошти, а також дати і часу, і просить авторів описувати свої зміни. diff --git a/uk/secrets.txt b/uk/secrets.txt index 6767cb8..0467218 100644 --- a/uk/secrets.txt +++ b/uk/secrets.txt @@ -64,7 +64,7 @@ Git евристично знаходить файли, які були пере $ printf "blob 6\000sweet\n" | sha1sum -Git використовує „адресацію по вмісту“: файли зберігаються у відповідності не з іменами, а з хешамі вмісту, – у файлі, який ми називаємо „блоб-об’єктом“. Хеш можна розуміти як унікальний ідентифікатор вмісту файлу, що означає звернення до файлів за їх вмістом. Початковий `blob 6` – лише заголовок, що складається з типу об'єкта і його довжини в байтах і спрощує внутрішній облік. +Git використовує „адресацію по вмісту“: файли зберігаються у відповідності не з іменами, а з хешамі вмісту, — у файлі, який ми називаємо „блоб-об’єктом“. Хеш можна розуміти як унікальний ідентифікатор вмісту файлу, що означає звернення до файлів за їх вмістом. Початковий `blob 6` — лише заголовок, що складається з типу об'єкта і його довжини в байтах і спрощує внутрішній облік. Таким чином, я можу легко передбачити, що ви побачите. Ім'я файлу не має значення: для створення блоб-об’єкта використовується тільки його вміст. @@ -104,7 +104,7 @@ SHA1 хеш його вмісту: Перевірка хешу за допомогою cat-file складніша, оскільки її висновок містить не тільки „сирий“ розпакований файл об’єкта. -Цей файл – об'єкт „дерево“ ('tree', прим. пер.): перелік ланцюгів, що складаються з типу, імені файлу та його хешу. У нашому прикладі: тип файлу – 100644, що означає, що `rose` це звичайний файл; а хеш – блоб-об’єкт, в якому міститься вміст `rose`. Інші можливі типи файлів: виконувані файли, символічні посилання або каталоги. В останньому випадку, хеш вказує на об’єкт „дерево“. +Цей файл — об'єкт „дерево“ ('tree', прим. пер.): перелік ланцюгів, що складаються з типу, імені файлу та його хешу. У нашому прикладі: тип файлу — 100644, що означає, що `rose` це звичайний файл; а хеш — блоб-об’єкт, в якому міститься вміст `rose`. Інші можливі типи файлів: виконувані файли, символічні посилання або каталоги. В останньому випадку, хеш вказує на об’єкт „дерево“. Якщо ви запускали filter-branch, у вас є старі об’єкти які вам більше не потрібні. Хоча після закінчення терміну зберігання вони будуть викинуті автоматично, ми видалимо їх зараз, щоб було легше стежити за нашим іграшковим прикладом: @@ -116,7 +116,7 @@ SHA1 хеш його вмісту: === Комміти === -Ми розглянули два з трьох об'єктів. Третій об’єкт – „комміт“ (commit). Його вміст залежить від опису комміта, як і від дати і часу його створення. Для відповідповідності тому, що ми маємо, ми повинні трохи „підкрутити“ Git: +Ми розглянули два з трьох об'єктів. Третій об’єкт — „комміт“ (commit). Його вміст залежить від опису комміта, як і від дати і часу його створення. Для відповідповідності тому, що ми маємо, ми повинні трохи „підкрутити“ Git: $ git commit --amend -m Shakespeare # Змінимо опис комміта. $ git filter-branch --env-filter 'export -- 2.11.4.GIT