File: basic.txt

package info (click to toggle)
gitmagic 20160304-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid, stretch
  • size: 2,280 kB
  • ctags: 20
  • sloc: makefile: 98; sh: 38
file content (199 lines) | stat: -rw-r--r-- 12,626 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
== Базові операції ==

Перш ніж занурюватися в нетрі численних команд Git, спробуйте скористатися наведеними нижче простими прикладами, щоб трохи освоїтися. Кожен із них корисний, незважаючи на свою простоту. Насправді перші місяці використання Git я не виходив за рамки матеріалу цього розділу.

=== Збереження стану ===

Збираєтеся спробувати внести якісь радикальні зміни? Попередньо створіть знімок всіх файлів у поточному каталозі за допомогою команд

 $ git init
 $ git add .
 $ git commit -m "Моя перша резервна копія"

Тепер, якщо нові правки все зіпсували, можна відновити початкову версію:

 $ git reset --hard

Щоб зберегти стан знову:

 $ git commit -a -m "Друга резервна копія"

=== Додавання, видалення, перейменування ===

Наведений вище приклад відстежує лише ті файли, які існували при першому запуску *git add*. Якщо ви створили нові файли або підкаталоги, доведеться сказати Git'у:

 $ git add readme.txt Documentation

Аналогічно, якщо хочете, щоб Git забув про деякі файли:

 $ git rm kludge.h obsolete.c
 $ git rm -r incriminating/evidence/

Git видалить ці файли, якщо ви не видалили їх самі.

Перейменування файлу — це те ж саме, що й видалення старого імені та додавання нового. Для цього є *git mv*, яка має той же синтаксис, що і команда *mv*. Наприклад:

 $ git mv bug.c feature.c

=== Розширені скасування/повернення ===

Іноді просто хочеться повернутися назад і забути всі зміни до певного моменту, тому що всі вони були неправильними. У такому випадку

 $ git log

покаже список останніх коммітів і їхні хеші SHA1:

----------------------------------
commit 766f9881690d240ba334153047649b8b8f11c664
Author: Іван <ivan@example.com>
Date:   Tue Mar 14 01:59:26 2000 -0800

    Замінив printf() на write().

commit 82f5ea346a2e651544956a8653c0f58dc151275c
Author: Марічка <marichka@example.com>
Date:   Thu Jan 1 00:00:00 1970 +0000

    Початковий комміт.
----------------------------------

Щоб вказати комміт, достатньо перших декількох символів його хешу, але можете скопіювати і весь хеш. Наберіть:

 $ git reset --hard 766f

для відновлення стану до зазначеного комміта і видалення всіх наступних безповоротно.

Можливо, іншим разом ви захочете швидко перескочити до старого стану. У цьому випадку наберіть

 $ git checkout 82f5

Ця команда перенесе вас назад у часі, зберігши при цьому більш нові комміти. Однак, як і у фантастичних фільмах про подорожі в часі, якщо тепер ви відредагуєте і закоммітите код, то потрапите в альтернативну реальність, тому що ваші дії відрізняються від тих, що були минулого разу.

Ця альтернативна реальність називається «гілкою» (branch) і <<branch,трохи пізніше ми поговоримо про це докладніше>>. А зараз просто запам'ятайте, що команда

 $ git checkout master

поверне вас назад у теперішнє. Крім того, щоб не отримувати попереджень від Git, завжди робіть commit або скидайте зміни перед запуском checkout.

Ще раз скористаємося аналогією з комп'ютерними іграми:

- *git reset --hard*: завантажує раніше збережену гру і видаляє всі версії, збережені після тількищо завантаженої.

- *git checkout*: завантажує стару гру, але якщо ви продовжуєте грати, стан гри буде відрізнятися від більш нових збережень, які ви зробили в перший раз. Будь-яка гра, яку ви тепер зберігаєте, потрапляє в окрему гілку, що представляє альтернативну реальність, в яку ви потрапили. <<branch,Ми обговоримо це пізніше>>.

Можна також відновити тільки певні файли і підкаталоги, перерахувавши їх імена після команди:

 $ git checkout 82f5 якийсь.файл інший.файл

Будьте уважні: така форма *checkout* може мовчки перезаписати файли. Щоб уникнути неприємних несподіванок, виконуйте commit перед checkout, особливо якщо ви тільки вивчаєте Git. Взагалі, якщо ви не впевнені у якісь операції, чи то команда Git чи ні, виконайте попередньо *git commit -a*.

Не любите копіювати і вставляти хеші? Використовуйте

 $ git checkout :/"Моя перша р"

для переходу на комміт, опис якого починається з наведеного рядка.

Можна також запитати 5-й з кінця збережений стан:

 $ git checkout master~5

=== Повернення ===

У залі суду пункти протоколу можуть викреслювати прямо під час слухання. Подібним чином і ви можете вибирати комміти для скасування.

 $ git commit -a
 $ git revert 1b6d

скасує комміт із заданим хешем. Повернення буде збережене у вигляді нового комміта. Можете запустити *git log*, щоб переконатися в цьому.

=== Створення списку змін ===

Деяким проектам потрібен http://en.wikipedia.org/wiki/Changelog[спискок змін (changelog)]. Створіть його такою командою:

 $ git log > ChangeLog

=== Завантаження файлів ===

Отримати копію проекту під управлінням Git можна, набравши

 $ git clone git://сервер/шлях/до/файлів

Наприклад, щоб отримати всі файли, які я використав для створення цього документу,

 $ git clone git://git.or.cz/gitmagic.git

Пізніше ми поговоримо про команду *clone* докладніше.

=== Тримаючи руку на пульсі ===

Якщо ви вже завантажили копію проекту за допомогою *git clone*, можете оновити її до останньої версії, використовуючи

 $ git pull

=== Невідкладна публікація ===

Припустимо, ви написали скрипт, яким хочете поділитися з іншими. Можна просто запропонувати їм скачувати його з вашого комп'ютера, але якщо вони будуть робити це коли ви допрацьовуєте його або додаєте експериментальну функціональність, у них можуть виникнути проблеми. Очевидно, тому й існують цикли розробки. Розробники можуть постійно працювати над проектом, але загальнодоступним вони роблять свій код лише після того, як приведуть його у пристойний вигляд.

Щоб зробити це за допомогою Git, виконайте в каталозі, де лежить ваш скрипт,

 $ git init
 $ git add .
 $ git commit -m "Перший реліз"

Потім скажіть вашим користувачам запустити

 $ git clone ваш.комп’ютер:/шлях/до/скрипту

щоб завантажити ваш скрипт. Тут мається на увазі, що у них є доступ по ssh. Якщо ні, запустіть *git daemon* і скажіть користувачам запустити цю команду замість вищенаведеної:

 $ git clone git://ваш.комп’ютер/шлях/до/скрипту

З цих пір щоразу, коли ваш скрипт готовий до релізу, виконуйте

 $ git commit -a -m "Наступний реліз"

і ваші користувачі зможуть оновити свої версії, перейшовши в каталог з вашим скриптом і набравши

 $ git pull

Ваші користувачі ніколи не наткнуться на версію скрипта, яку ви не хочете їм показувати.

=== Що я зробив? ===

З'ясуйте, які зміни ви зробили з часу останнього комміта:

 $ git diff

Чи з вчорашнього дня:

 $ git diff "@{yesterday}"

Чи між певною версією і версією, зробленою 2 комміти назад:

 $ git diff 1b6d "master~2"

У кожному разі на виході буде патч, який може бути застосований за допомогою *git apply*. Спробуйте також:

 $ git whatchanged --since="2 weeks ago"

Часто замість цього я використовую для перегляду історії http://sourceforge.net/projects/qgit[qgit], через приємний інтерфейс, або http://jonas.nitro.dk/tig[tig] з текстовим інтерфейсом, який добре працює через повільне з'єднання. Як варіант, встановіть веб-сервер, введіть *git instaweb* і запустіть будь-який веб-браузер.

=== Вправа ===

Нехай A, B, C, D — чотири послідовні комміти, де В відрізняється від A лише кількома видаленими файлами. Ми хочемо повернути ці файли в D. Як ми можемо це зробити?

Існує як мінімум три розв’язки. Припустимо, що ми знаходимося на D.

  1. Різниця між A і B — видалені файли. Ми можемо створити патч, що відображає ці зміни, і застосувати його:

   $ git diff B A | git apply

  2. Оскільки в комміті A ми зберегли файли, то можемо відновити їх:

   $ git checkout A foo.c bar.h

  3. Ми можемо розглядати перехід від A до B як зміни, які хочемо скасувати:

   $ git revert B

Який спосіб найкращий? Той, який вам більше подобається. За допомогою Git легко отримати бажане і часто існує багато способів це зробити.