Синхронизация с оригиналом (глава 5)

book/05-distributed-git/sections/contributing.asc

@@ -59,30 +59,35 @@ image::images/git-diff-check.png["Вывод команды `git diff --check`"]
 Последнее, что нужно иметь ввиду -- это сообщение коммита.
 Привычка создавать качественные сообщения к коммитам позволяет упростить использование и взаимодействие посредством Git.
 Как правило, ваши сообщения должны начинаться кратким однострочным описанием не более 50 символов, затем должна идти пустая строка, после которой следует более детальное описание.
-Проект Git требует, чтобы детальное описание включало вашу мотивацию при внесении изменения и сравнение с текущей реализацией -- это хороший пример для подражания.
-Так же хорошей идеей будет использование фраз в повелительном наклонении настоящего времени.
-Другими словами -- используйте команды.
-Вместо «Я добавил тесты для» или «Добавление тестов для», используйте «Добавить тесты для».
-Ниже представлен шаблон, написанный Tim Pope:
+Проект Git требует, чтобы детальное описание включало причину внесения изменений и сравнение с текущей реализацией -- это хороший пример для подражания.
+
+Пишите сообщение коммита в императиве: «Fix bug» а не «Fixed bug» или «Fixes bug».
+
+Вот отличный шаблон хорошего сообщения коммита, который мы слегка адаптировали из шаблона, https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[изначально написанного Тимом Поупом]:
 
 [source,text]
 ----
-Краткое (50 символов или меньше) описание изменений
+Краткое (не более 50 символов) резюме с заглавной буквы
 
-Текст более детального описания, если необходим. Старайтесь
-не превышать длину строки в 72 символа. В некоторых случаях
-первая строка подразумевается как тема письма, а всё остальное -- 
-тело письма. Пустая строка, разделяющая сообщение, критически важна
-(если существует детальное описание); такие утилиты как rebase
-могут запутаться, если вы запустите сразу две.
+Более детальный, поясняющий текст, если он требуется.
+Старайтесь не превышать длину строки в 72 символа.
+В некоторых случаях первая строка подразумевается как тема письма, а всё остальное -- как тело письма.
+Пустая строка, отделяющая сводку от тела, имеет решающее значение 
+(за исключением случаев, когда детального описания нет);
+в противном случае такие инструменты, как rebase, могут вас запутать.
 
-Последующие параграфы должны отделяться пустыми строками.
+Сообщения коммитов следует писать в повелительном наклонении: «Fix bug» (Исправь баг), а не «Fixed bug» (Исправлен баг) или «Fixes bug» (Исправляет баг).
+Это соглашение соответствует сообщениям коммитов, генерируемых такими командами, как `git merge` и `git revert`.
 
-  - Списки тоже подходят
+Последующие абзацы идут после пустых строк.
+
+  - Допускаются обозначения пунктов списка
 
   - Обычно, элементы списка обозначаются с помощью тире или звёздочки,
-    предваряются одиночным пробелом, а разделяются пустой строкой, но
+    с одним пробелом перед ними, а разделяются пустой строкой, но
     соглашения могут отличаться
+
+  - Допускается обратный абзацный отступ.
 ----
 
 Вам и вашим разработчикам будет гораздо проще, если все сообщения ваших коммитов будут так выглядеть.
@@ -118,8 +123,8 @@ Cloning into 'simplegit'...
 ...
 $ cd simplegit/
 $ vim lib/simplegit.rb
-$ git commit -am 'remove invalid default value'
-[master 738ee87] remove invalid default value
+$ git commit -am 'Remove invalid default value'
+[master 738ee87] Remove invalid default value
  1 files changed, 1 insertions(+), 1 deletions(-)
 ----
 
@@ -133,8 +138,8 @@ Cloning into 'simplegit'...
 ...
 $ cd simplegit/
 $ vim TODO
-$ git commit -am 'add reset task'
-[master fbff5bc] add reset task
+$ git commit -am 'Add reset task'
+[master fbff5bc] Add reset task
  1 files changed, 1 insertions(+), 0 deletions(-)
 ----
 
@@ -248,7 +253,7 @@ commit 738ee872852dfaa9d6634e0dea7a324040193016
 Author: John Smith <[email protected]>
 Date:   Fri May 29 16:01:27 2009 -0700
 
-   remove invalid default value
+   Remove invalid default value
 ----
 
 `issue54..origin/master` -- это синтаксис фильтра, который указывает Git отображать только список коммитов, которые существуют в последней ветке (в данном случае `origin/master`), но отсутствуют в первой (в данном случае `issue54`).
@@ -342,8 +347,8 @@ image::images/small-team-flow.png["Общий вид последователь
 $ git checkout -b featureA
 Switched to a new branch 'featureA'
 $ vim lib/simplegit.rb
-$ git commit -am 'add limit to log function'
-[featureA 3300904] add limit to log function
+$ git commit -am 'Add limit to log function'
+[featureA 3300904] Add limit to log function
  1 files changed, 1 insertions(+), 1 deletions(-)
 ----
 
@@ -364,7 +369,7 @@ To jessica@githost:simplegit.git
 
 [source,console]
 ----
-# Компьтер Джессики
+# Компьютер Джессики
 $ git fetch origin
 $ git checkout -b featureB origin/master
 Switched to a new branch 'featureB'
@@ -375,12 +380,12 @@ Switched to a new branch 'featureB'
 [source,console]
 ----
 $ vim lib/simplegit.rb
-$ git commit -am 'made the ls-tree function recursive'
-[featureB e5b0fdc] made the ls-tree function recursive
+$ git commit -am 'Make ls-tree function recursive'
+[featureB e5b0fdc] Make ls-tree function recursive
  1 files changed, 1 insertions(+), 1 deletions(-)
 $ vim lib/simplegit.rb
-$ git commit -am 'add ls-files'
-[featureB 8512791] add ls-files
+$ git commit -am 'Add ls-files'
+[featureB 8512791] Add ls-files
  1 files changed, 5 insertions(+), 0 deletions(-)
 ----
 
@@ -520,15 +525,15 @@ $ git commit
 
 [NOTE]
 ====
-Если вы захотите использовать `rebase -i` для схлопывания коммитов в единый или для их перестановки чтобы облегчить модерирование ваших патчей -- воспользуйтесь разделом <<ch07-git-tools#r_rewriting_history>> для получения детальной информации об интерактивном перебазировании.
+Вы можете захотеть использовать `rebase -i`, чтобы свести свою работу в один коммит или переставить коммиты местами, чтобы сопровождающему было легче проверять патч -- смотрите раздел <<ch07-git-tools#r_rewriting_history>> для получения детальной информации об интерактивном перебазировании.
 ====
 
 Когда работа в тематической ветке завершена и вы готовы передать изменения исходному проекту, перейдите на страницу исходного проекта и нажмите кнопку «Fork», тем самым создавая доступный для записи форк проекта.
 Затем нужно добавить URL на созданный проект как второй удалённый репозиторий, в нашем случае с именем `myfork`:
 
 [source,console]
 ----
-$ git remote add myfork (url)
+$ git remote add myfork <url>
 ----
 
 После этого следует отправить проделанную работу в него.
@@ -555,15 +560,15 @@ $ git push -u myfork featureA
 $ git request-pull origin/master myfork
 The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
 Jessica Smith (1):
-        added a new function
+        Create new function
 
 are available in the git repository at:
 
   git://githost/simplegit.git featureA
 
 Jessica Smith (2):
-      add limit to log function
-      change log output to 30 from 25
+      Add limit to log function
+      Increase log output to 30 from 25
 
  lib/simplegit.rb |   10 +++++++++-
  1 files changed, 9 insertions(+), 1 deletions(-)
@@ -618,8 +623,8 @@ image::images/public-small-2.png["История коммитов после р
 [source,console]
 ----
 $ git checkout -b featureBv2 origin/master
-$ git merge --no-commit --squash featureB
-# (change implementation)
+$ git merge --squash featureB
+  ... change implementation ...
 $ git commit
 $ git push myfork featureBv2
 ----
@@ -662,7 +667,7 @@ $ git commit
 ----
 $ git format-patch -M origin/master
 0001-add-limit-to-log-function.patch
-0002-changed-log-output-to-30-from-25.patch
+0002-increase-log-output-to-30-from-25.patch
 ----
 
 Команда `format-patch` выводит список имён файлов патчей, которые она создаёт.
@@ -675,7 +680,7 @@ $ cat 0001-add-limit-to-log-function.patch
 From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 From: Jessica Smith <[email protected]>
 Date: Sun, 6 Apr 2008 10:17:23 -0700
-Subject: [PATCH 1/2] add limit to log function
+Subject: [PATCH 1/2] Add limit to log function
 
 Limit log functionality to the first 20
 
@@ -728,7 +733,7 @@ index 76f47bc..f9815f1 100644
 
 [source,console]
 ----
-$ cat *.patch | git imap-send
+$ cat *.patch |git imap-send
 Resolving imap.gmail.com... ok
 Connecting to [74.125.142.109]:993... ok
 Logging in...
@@ -739,7 +744,7 @@ sending 2 messages
 Теперь вы можете перейти в папку Drafts, изменить поле To, указав адрес почтовой рассылки, при необходимости заполнить поле СС, указав адрес сопровождающего или ответственного, и отправить письмо.
 
 Так же вы можете отправить свои патчи используя SMTP сервер.
-Как и в предыдущем случае, вы можете использовать набор команд `git config` или создать секцию sendemail в файле `~/.gitconfig`:
+Как и в предыдущем случае, вы можете использовать набор команд `git config` или создать секцию `sendemail` в файле `~/.gitconfig`:
 
 [source,ini]
 ----
@@ -755,8 +760,8 @@ sending 2 messages
 [source,console]
 ----
 $ git send-email *.patch
-0001-added-limit-to-log-function.patch
-0002-changed-log-output-to-30-from-25.patch
+0001-add-limit-to-log-function.patch
+0002-increase-log-output-to-30-from-25.patch
 Who should the emails appear to be from? [Jessica Smith <[email protected]>]
 Emails will be sent from: Jessica Smith <[email protected]>
 Who should the emails be sent to? [email protected]
@@ -773,7 +778,7 @@ OK. Log says:
 Sendmail: /usr/sbin/sendmail -i [email protected]
 From: Jessica Smith <[email protected]>
 To: [email protected]
-Subject: [PATCH 1/2] added limit to log function
+Subject: [PATCH 1/2] Add limit to log function
 Date: Sat, 30 May 2009 13:29:15 -0700
 Message-Id: <[email protected]>
 X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
@@ -790,6 +795,11 @@ Result: OK
 
 ==== Заключение
 
-В этом разделе рассмотрен ряд основных рабочих процессов, с которыми вы можете столкнуться при участии в различных Git проектах, а так же представлен ряд новых инструментов, чтобы помочь вам управлять этим процессом.
-Далее, вы взглянете на работу с другой стороны: сопровождение Git проекта.
-Вы научитесь быть доброжелательным диктатором или менеджером по интеграции.
+В этом разделе мы рассмотрели ряд общепринятых рабочих схем и поговорили о различиях между работой в составе небольшой команды над проектами с закрытым исходным кодом и участием в большом публичном проекте.
+Вы знаете, что нужно проверять ошибки в пробелах перед созданием коммита, и можете написать отличное сообщение коммита.
+Вы научились оформлять патчи и отправлять их по электронной почте в список рассылки разработчиков.
+Работа со слияниями также была покрыта в контексте различных рабочих процессов.
+Теперь вы хорошо подготовлены для совместной работы над любым проектом.
+
+Далее рассмотрим ситуацию с другой стороны: как сопровождать проект Git.
+Вы узнаете, как быть великодушным диктатором или менеджером по интеграции.

book/05-distributed-git/sections/distributed-workflows.asc

@@ -48,7 +48,7 @@ image::images/centralized_workflow.png["Централизованный раб
 2.  Участник клонирует этот репозиторий и вносит изменения.
 3.  Участник отправляет свои изменения в свой публичный репозиторий.
 4.  Участник отправляет письмо сопровождающему с запросом на слияние изменений.
-5.  Сопровождающий добавляет репозиторий участника как удалённый и сливает изменения локально
+5.  Сопровождающий добавляет репозиторий участника как удалённый и сливает изменения локально.
 6.  Сопровождающий отправляет слитые изменения в основной репозиторий.
 
 [[rwfdiag_b]]
@@ -83,6 +83,19 @@ image::images/benevolent-dictator.png["Рабочий процесс с добр
 Такой вид организации рабочего процесса не является обычным, но может быть применён к очень большим проектам или в сильно иерархической среде.
 Это позволяет лидеру проекта (диктатору) делегировать большую часть работы и собирать большие подмножества кода в различных точках до того как они будут интегрированы.
 
+[[_patterns_for_managing_source_code_branches]]
+==== Шаблоны для управления ветками исходного кода
+
+[NOTE]
+====
+Мартин Фаулер сделал руководство «Шаблоны для управления ветками исходного кода».
+Это руководство охватывает все стандартные рабочие процессы Git и объясняет, как и когда их использовать.
+Также есть раздел, в котором сравнивается высокая и низкая частота слияния.
+
+https://martinfowler.com/articles/branching-patterns.html
+====
+
+
 ==== Заключение
 
 Это наиболее часто используемые подходы в организации рабочего процесса на основании распределенных систем, таких как Git.