10683133d3e4b78a09aac8633c1501aac93ca885
[gitmagic.git] / uk / multiplayer.txt
blob10683133d3e4b78a09aac8633c1501aac93ca885
1 == Багатокористувацький Git ==
3 Спочатку я використовував Git для особистого проекту, в якому був єдиним розробником. Серед команд, які відносяться до розподілених властивостей Git, мені були потрібні тільки *pull* і *clone*, щоб зберігати один і той же проект у різних місцях.
5 Пізніше я захотів опублікувати свій код за допомогою Git і включати зміни помічників. Мені довелося навчитися управляти проектами, в яких беруть участь багато людей по всьому світу. На щастя, в цьому сильна сторона Git і, можливо, сам сенс його існування.
7 === Хто я? ===
9 Кожен комміт містить ім'я автора та адресу електронної пошти, які виводяться командою *git log*. За замовчуванням Git використовує системні налаштування для заповнення цих полів. Щоб встановити їх явно, введіть
11   $ git config --global user.name "John Doe"
12   $ git config --global user.email johndoe@example.com
14 Щоб встановити ці параметри лише для поточного сховища, пропустіть опцію --global.
16 === Git через SSH, HTTP ===
18 Припустимо, у вас є SSH доступ до веб-сервера, але Git не встановлений. Git може зв'язуватися через HTTP, хоча це і менш ефективно, ніж його власний протокол.
20 Скачайте, скомпілюйте, встановіть Git у вашому акаунті; створіть сховище в каталозі, доступному через web:
22  $ GIT_DIR=proj.git git init
23  $ cd proj.git
24  $ git --bare update-server-info
25  $ cp hooks/post-update.sample hooks/post-update
27 Для старих версій Git команда копіювання не спрацює і ви повинні будете запустити
29  $ chmod a+x hooks/post-update
31 Тепер ви можете публікувати свої останні правки через SSH з будь-якого клону:
33  $ git push веб.сервер:/шлях/до/proj.git master
35 і хто завгодно зможе взяти ваш проект за допомогою
37  $ git clone http://веб.сервер/proj.git
39 === Git через що завгодно ===
41 Хочете синхронізувати сховища без серверів або взагалі без мережевого підключення? Змушені імпровізувати на ходу в непередбаченій ситуації? Ми бачили, як <<makinghistory, *git fast-export* і *git fast-import* можуть перетворити сховища в один файл і назад>>. За допомогою обміну такими файлами ми можемо переносити сховища git будь-якими доступними засобами, але є більш ефективний інструмент: *git bundle*.
43 Відправник створює пакет (bundle):
45  $ git bundle create деякий_файл HEAD
47 Потім передає пакет, +деякий_файл+, іншій команді будь-якими засобами, як то: електронна пошта, флешка, *xxd* друк і подальше розпізнавання тексту, надиктовка бітів по телефону, димові сигнали і так далі. Одержувач відновлює комміти з пакету, ввівши
49  $ git pull деякий_файл
51 Одержувач може зробити це навіть у порожньому сховищі. Незважаючи на свій невеликий розмір, +деякий_файл+ містить все вихідне сховище Git.
53 У великих проектах для усунення надлишків обсягу пакетують тільки зміни, яких немає в інших сховищах. Наприклад, нехай комміт ``1b6d...'' — останній спільний для обох груп:
55  $ git bundle create деякий_файл HEAD ^1b6d
57 Якщо це робиться часто, можна легко забути, який комміт був відправлений останнім. Довідка пропонує для вирішення цієї проблеми використовувати теги. А саме, після передачі пакета введіть
59  $ git tag -f останній_пакет HEAD
61 і створюйте оновлені пакети за допомогою
63  $ git bundle create новий_пакет HEAD ^останній_пакет
65 === Патчі: загальне застосування ===
67 Патчі — це тексти змін, цілком зрозумілі як для людини, так і комп'ютера. Це робить їх дуже привабливим форматом обміну. Патч можна послати розробникам по електронній пошті, незалежно від того, яку систему управління версіями вони використовують. Вашим кореспондентам достатньо можливості читати електронну пошту, щоб побачити ваші зміни. Точно так само, з Вашого боку потрібна лише адреса електронної пошти: немає потреби в налаштуванні онлайн сховища Git.
69 Пригадаємо з першого розділу:
71  $ git diff 1b6d
73 виводить патч, який може бути вставлений в лист для обговорення. У Git сховищі введіть
75  $ git apply < мій.patch
77 для застосування патча.
79 У більш формальних випадках, коли потрібно зберегти ім'я автора та підписи, створюйте відповідні патчі з заданої точки, набравши
81  $ git format-patch 1b6d
83 Отримані файли можуть бути відправлені за допомогою *git-send-email* або вручну. Ви також можете вказати діапазон коммітів:
85  $ git format-patch 1b6d..HEAD^^
87 На приймаючій стороні збережіть лист в файл і введіть:
89  $ git am < email.txt
91 Це застосує вхідні виправлення і створить комміт, що включає ім'я автора та іншу інформацію.
93 З web-інтерфейсом до електронної пошти вам, можливо, буде потрібно натиснути кнопку, щоб подивитися електронну пошту в своєму початковому вигляді перед збереженням патча в файл.
95 Для клієнтів електронної пошти, що використовують mbox, є невеликі відмінності, але якщо ви використовуєте один з них, то ви, очевидно, можете легко розібратися в цьому без читання описів!
97 === Приносимо вибачення, ми переїхали ===
99 Після клонування сховища команди *git push* або *git pull* автоматично відправляють і отримують його за початковою адресою. Яким чином Git це робить? Секрет полягає в налаштуваннях, заданих при створенні клона. Давайте поглянемо:
101  $ git config --list
103 Опція +remote.origin.url+ задає вихідний адресу; ``origin'' — ім'я початкового сховища. Як і ім'я гілки ``master'', це домовленість. Ми можемо змінити або видалити це скорочене ім'я, але як правило, немає причин для цього.
105 Якщо оригінальне сховище переїхало, можна оновити його адресу командою
107  $ git config remote.origin.url git://новий.url/proj.git
109 Опція +branch.master.merge+ задає віддалену гілку за замовчуванням для *git pull*. В ході початкового клонування вона встановлюється на поточну гілку джерельного сховища, так що навіть якщо HEAD джерельного сховища згодом переміститься на іншу гілку, pull буде вірно слідувати початковій гілці.
111 Цей параметр звертається тільки до сховища, яке ми спочатку клонували і яке записано в параметрі +branch.master.remote+. При виконанні pull з інших сховищ ми повинні вказати потрібну гілку:
113  $ git pull git://приклад.com/other.git master
115 Це пояснює, чому деякі з наших попередніх прикладів push і pull не мали аргументів.
117 === Віддалені гілки ===
119 При клонуванні сховища ви також клонуєте всі його гілки. Ви можете не помітити цього, тому що Git приховує їх: ви повинні запитати їх явно. Це запобігає протиріччю між гілками у віддаленому сховищі і вашими гілками, а також робить Git простішим для початківців.
121 Список віддалених гілок можна подивитися командою
123  $ git branch -r
125 Ви повинні побачити щось подібне
127  origin/HEAD
128  origin/master
129  origin/experimental
131 Ці імена відповідають гілкам і «голові» в віддаленому сховищі; їх можна використовувати в звичайних командах Git. Наприклад, ви зробили багато коммітів, і хотіли б порівняти поточний стан з останньою завантаженою версією. Ви можете шукати в журналах потрібний SHA1 хеш, але набагато легше набрати
133  $ git diff origin/HEAD
135 Також можна побачити, для чого була створена гілка ``experimental'':
137  $ git log origin/experimental
139 === Кілька віддалених сховищ ===
141 Припустимо, що над нашим проектом працюють ще два розробники і ми хочемо стежити за обома. Ми можемо спостерігати більш ніж за одним сховищем одночасно, ось так:
143  $ git remote add other git://приклад.com/деяке_сховище.git
144  $ git pull other деяка_гілка
146 Зараз ми зробили злиття з гілкою з другого сховища. Тепер у нас є легкий доступ до всіх гілок у всіх сховищах:
148  $ git diff origin/experimental^ other/деяка_гілка~5
150 Але що якщо ми просто хочемо порівняти їх зміни, не зачіпаючи свою роботу? Іншими словами, ми хочемо вивчити чужі гілки, не даючи їх змінам вторгатися в наш робочий каталог. Тоді замість pull наберіть
152  $ git fetch # Перенести із origin, типово.
153  $ git fetch other # Перенести від другого програміста.
155 Так ми лише переносимо їх історію. Хоча робочий каталог залишається недоторканими, ми можемо звернутися до будь гілці в будь-якому сховищі команди, працюючої з Git, оскільки тепер у нас є локальна копія.
157 Пригадаємо, що pull це просто *fetch*, а потім *merge*. Зазвичай ми використовуємо *pull*, тому що ми хочемо влити до себе останній комміт після отримання чужої гілки. Описана ситуація — визначний виняток.
159 Про те, як відключити віддалені сховища, ігнорувати окремі гілки і багато іншого дивіться у *git help remote*.
161 === Мої вподобання ===
163 Я віддаю перевагу, щоб люди, що приєднуються до моїх проектів, створювали сховища, з яких я зможу отримувати зміни за допомогою pull. Деякі хостинги Git дозволяють створювати власні розгалуження (форки) проекту в один дотик.
165 Після отримання дерева з віддаленого сховища я запускаю команди Git для навігації і вивчення змін, в ідеалі добре організованих і описаних. Я роблю злиття зі своїми змінами і можливо вношу подальші правки. Коли я задоволений результатом, я заливаю зміни в головне сховище.
167 Хоча зі мною мало співпрацюють, я вірю, що цей підхід добре масштабується. Дивіться http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[цей запис в блозі Лінуса Торвальдса].
169 Залишатися в світі Git трохи зручніше, ніж використовувати файли патчів, оскільки це позбавляє мене від перетворення їх в комміти Git. Крім того, Git управляє деталями на зразок збереження імені автора та адреси електронної пошти, а також дати і часу, і просить авторів описувати свої зміни.