# coding: utf-8

1.3.5 Ветвление, редактирование, фиксация, объединение

Если Вы следовали за шагами в Разделе 1.3.4, Вы могли заметить, что GitHub автоматически показывает содержание файла README на основной странице репозитария. В нашем случае, так как проект сгенерирован с использованием команды rails файл README – тот, который идет с Rails (Рис. 1.9). Это не очень полезно, так что в этом разделе мы сделаем наше первое редактирование, изменив README чтобы описать наш проект, а не саму платформу Rails. В процессе, мы увидим первый пример ветвления, редактирования, фиксации, операцию слияния, которые я рекомендую использовать с Git.

Рисунок 1.9: Начальный (и довольно бесполезный) файл README для нашего проекта в GitHub.

Рисунок 1.9: Начальный (и довольно бесполезный) файл README нашего проекта в GitHub.

Ветвление

Git невероятно хорош в создании веток, которые фактически являются копиями репозитария, где мы можем произвести (возможно экспериментальные) изменения, не модифицируя родительские файлы. В большинстве случаев родительский репозитарий – master ветка, и мы можем создать новую тему ответвления используя checkout с флагом -b:

  $ git checkout -b modify-README
  Switched to a new branch 'modify-README'
  $ git branch
  master
  * modify-README

Здесь вторая команда, git branch, только перечисляет все локальные ветки, а звездочка * указывает, какая ветка в настоящий момент включена. Отметьте, что git checkout -b modify-README одновременно и создает новую ветку и переключает на нее, на что указывает звездочка перед modify-README веткой. (Если Вы настроили псевдоним co в Разделе 1.3, можете использовать git co -b modify-README вместо этого.)

Полностью оценить достоинства ветвления можно только работая над проектом совместно с множеством разработчиков,22 но ветки полезны даже для учебника единственного разработчика, такого как этот. В частности ветка master изолируется от любых изменений, которые мы производим в теме ветки, так что даже если мы действительно наворотили лишнего, мы можем всегда отказться от изменений, вернувшись в master ветку и удалив тему ветки. Мы увидим, как сделать это в конце раздела.

Между прочим, для изменений столь малых как это, обычно я бы не стал заморачиваться новой веткой, но никогда не слишком рано, чтобы начать практиковать хорошие привычки.

Редактирование

После создания темы ветки мы отредактируем его (файл readme), чтобы сделать немного более наглядным. Мне нравится использовать язык разметки Markdown для этих целей, и если Вы будете использовать расширение файла .markdown тогда GitHub будет автоматически форматировать его в приятный для вас вид. Итак, сначала мы будем использовать Git версию Unix команды mv (“move”) , чтобы изменить название, а затем заполним его содержанием Листинга 1.6:

  $ git mv README README.markdown
  $ mate README.markdown
Листинг 1.6. Новый файл README, README.markdown
  # Ruby on Rails Tutorial: первое приложение

Это первое приложение для 
[*Ruby on Rails Tutorial: Learn Rails by Example*](https://railstutorial.org/) 
 [Майкл Хартл](http://michaelhartl.com/).

Фиксация

С произведенными изменениями мы можем посмотреть статус нашей ветки:

  $ git status
  # On branch modify-README
  # Changes to be committed:
  #   (use "git reset HEAD <file>..." to unstage)
  #
  #       renamed:    README -> README.markdown
  #
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #       modified:   README.markdown
  #

В этой точке мы могли бы использовать git add . как в Разделе 1.3.2, но Git предусматривает флаг -a как сокращение для (очень частого) случая фиксации всех изменений к существующим файлам (или файлов, созданных с использованием git mv, которые не считаются новыми для Git):

  $ git commit -a -m "Improved the README file"
  2 files changed, 5 insertions(+), 243  deletions(-)
  delete mode 100644 README
  create mode 100644 README.markdown

Будьте осторожны с использованием флага -a; если Вы добавили какие-либо новые файлы в проект после последней фиксации, Вы должны сообщить Git о них используя сначалаgit add.

Объединение

Теперь, когда мы закончили производить наши изменения, мы готовы объединить результаты с нашей master веткой:23

  $ git checkout master

  Switched to branch 'master'
  $ git merge modify-README
  Updating 34f06b7..2c92bef
  Fast forward
  README          |  243 -------------------------------------------------------
  README.markdown |    5 +
  2 files changed, 5 insertions(+), 243 deletions(-)
  delete mode 100644 README
  create mode 100644 README.markdown

Отметьте, что вывод Git часто включает такие вещи как 34f06b7, которые связаны с внутренним представлением Git репозитариев. Ваши конкретные результаты будут отличаться в этих деталях, но остальное по своей сути должно соответствовать выводу, показанному выше.

После того, как Вы объединили изменения, Вы можете почистить свои ветки, стерев тему ветки, используя git branch -d , если Вы хотите, сделайте это так:

  $ git branch -d modify-README
  Deleted branch modify-README (was 2c92bef).

Этот шаг не является обязательным, и, фактически, это довольно распространено - оставлять тему ветки нетронутой. Что позволяет переключаться между темой ветки и master веткой, объединяя изменения каждый раз, когда Вы достигаете естественной точки остановки.

Как упомянуто выше, также возможно отказаться от Ваших изменений темы ветки, в этом случае с git branch -D:

  # Только для иллюстрации; не делайте этого,
    если планируете в дальнейшем пользоваться веткой
  $ git checkout -b topic-branch
  $ <really screw up the branch>
  $ git add .
  $ git commit -a -m "Screwed up"
  $ git checkout master
  $ git branch -D topic-branch

В отличие от флага -d, флаг -D сотрет ветку даже если мы не объединили изменения.

Отправка

Теперь, когда мы обновили README, мы можем отправить изменения в GitHub чтобы увидеть результат. Так как мы уже сделали одну отправку (Раздел 1.3.4), на большинстве систем, мы теперь можем опустить origin master, и просто выполнить git push:24

  $ git push

На некоторых системах, эта команда выдает ошибку:

  $ git push
  fatal: The current branch master is not tracking anything.

В этом случае необходимо выполнить git push origin master как в Разделе 1.3.4.

Как и обещалось, GitHub приятно форматирует новый файл, используя Markdown (Рис. 1.10).

Рисунок 1.10: Улучшеный файл README форматированный в Markdown.

Рисунок 1.10: Улучшеный файл README форматированный в Markdown.

# coding: utf-8