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

Рисунок 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
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.