Git в домашнем хозяйстве. Часть 2: Уоу-уоу потише, не конфликтуй!

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

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

Я использую Git + командная строка + SourceTree под MacOS и Ubuntu (в убунте xterm). И там и там работа абсолютно идентична.

Что ж, не будем медлить — вперед!

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

## Ветки. Что это? Ходим по веткам и коммитам.

Ветки — это цепочки коммитов. Любой коммит, как вы помните, характеризует состояние рабочей папки на каком-то этапе разработки.
Указатель на текущий коммит называется HEAD. То есть, когда вы перемещаетесь по коммитам, чтобы вернуть состояние рабочей папки в тот или иной вид, согласно этапам разработки, вы просто передвигаете указатель HEAD на тот или иной коммит. Указатель передвигается командой git checkout. В качестве параметра мы можем указать хеш коммита, тэг, название ветки (тогда мы окажемся на самом конце ветки), или указатель HEAD и «крышечки», то есть, чтобы уйти на 5 коммитов назад можно написать HEAD^^^^^. На самом деле есть еще другие параметры, но о них читайте в доках — в 95% случаев хватает поиска по хэшику или переход назад на количество «крышечек».

Эмпирично на картинке это выглядит так:

1. У нас одна ветка и указатель HEAD на самом верху.
2. Мы решаем уйти на 2 коммита назад и создать ветку.
Для этого переводим указатель HEAD на 2 коммита назад (если промахнулись, то стОит вернуться командой git checkout master, и попробовать еще раз):

git checkout HEAD^^

И создаем новую ветку:

git checkout -b new-branch

Здесь checkout -b означает создать ветку и сразу перейти на нее (перенести на нее указатель HEAD). При создании ветки не создается новый коммит — то есть мы находимся на коммите, который находится в мастере. Ну оно и понятно — мы же собираемся пилить ветку из какого-то исходного состояния рабочей папки, вот мы это состояние и определяем стартом новой ветки.

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

git push origin new-branch

На сервере будет создана ветка origin/new-branch, и наша локальная ветка будет за ней следить. И, собственно, пушить ветку в удаленный репозиторий нужно этой командой.
Да, локальная ветка и удаленная — разные вещи.
Я знаю, что здесь кроется тонна непоняток, но, думаю, вы разберетесь с этим сами)

3. Работаем в ветке.
Работая в ветке, мы создаем цепочку коммитов, которые уводят нас все дальше от исходного состояния рабочей папки. Что мы и видим из рисунка.

4. Удаляем ветки.
Чтобы удалить ветку, содержимое которой уже слито в другую ветку, можно использовать команду:

git branch -d branch-name

Если вы хотите удалить ветку, содержимое которой не слито в другую ветку (а это значит потерять код из этой ветки), используйте команду с ключом в виде большой буквы D:

git branch -D branch-name

## Соединяем ветки. Merge и Rebase.

Сначала немного рисунков на бумаге.
Из предыдущего рисунка видно, что мы сделали какие-то изменения в new-branch и мы хотим вернуть эти изменения в master.
Это можно сделать командой merge.


То есть мы делаем 2 действия:
1. Переключаемся на ветку КУДА будем мержить. В данном случае в ветку master.

git checkout master

2. Мёржим:

git merge new-branch

В результате мержа создается новый коммит, который автоматически подписывается комментарием (типа ветка такая-то смержена с такой-то). Этот коммит создается в ветке, КУДА мы мержили, и HEAD сдвигается на этот коммит — то есть мы оказываемся на верхушечке.
Если изменения в ветке new-branch сделаны только в тех местах, где не было изменений в master, то git сам все сделает правильно. Если изменения были в одних и тех же местах в обоих ветках, то будет merge conflict, но об этом чуть позже.

Если вы в результате неправильного мержа что-то поломали, или просто опрометчиво смержили то всегда можно откатить состояние репозитория на коммит назад, находясь на коммите мержа:

git reset --hard HEAD^

То есть мы говорим: гит, давай-ка ресетни состояние репозитория до предыдущего коммита, при этом измени состояние рабочей папки до состояния предыдущего коммита (это ключ --hard).

Теперь другая история. Делаем rebase.
Ребэйз — это такая операция, которая изменяет откуда растет ветка. Например, мы отбранчевались от мастера, написали свою фичу, а в это время другой разработчик вмержил в мастер свою фичу. Мы можем сделать так, чтобы наша ветка стала вся полностью произрастать из нового коммита в мастере при помощи команды rebase.


Здесь тоже все без магии. На картинке ветка new-branch стартует с 3-его коммита master, а мы хотим, чтобы она стартовала с самого крайнего — 5-ого — коммита.
1. Сначала переключаемся на ветку, которую хотим ребэйзить:

git checkout new-branch

2. Делаем ребэйз на master (то есть = на самый верхний коммит ветки master):
git rebase master
Ребэйз происходит очень просто. Сначала переносится 1-ый коммит из ребэйзимой (ой, словечко-то какое) ветки на новое место. Следом за ним — второй, потом третий и так далее. И если в каком-то из коммитов есть изменения в тех же местах, что и в новых коммитах мастера, то нужно будет разрешить merge conflict. При этом процесс rebase останавливается, вы разрешаете конфликт, и для продолжения процесса в консоли пишете:

git rebase --continue

Если вы решили отказаться от текущего ребэйза, пишите в консоли:

git rebase --abort

## Разрешаем любые конфликты недорого.

И мы плавно переходим к вопросу разрешения конфликтов. Это тема больная, особенно для файлов проектов (то есть для Xcode это, например, *.xcodeproj, и сломать его в результате мержа — как два пальца об асфальт) или для изменяемых ресурсов.
Но для исходных кодов все обычно решается легче легкого.
Будет 100500 картинок, но не пугайтесь.

Предположим, что есть два разработчика (Asa и Akira), которым нужно поработать над общим файлом main.c, который сейчас выглядит вот так:


Исходное дерево проекта выглядит так:

Asa

И, допустим, Asa бранчует из текущего мастера ветку, и меняет main.c за несколько коммитов.
В командной строке это выглядит цепочкой команд добавления нужных файлов в коммит и добавления коммитов (да, эта картиночка для того, чтобы показать, что командная строка вовсе и не хард-кор, а вполне себе годный и удобный инструмент, особенно, когда приходится писать много кода, много пользоваться hot-key'ами, и привыкаешь не смотреть на клавиатуру).


Код main.c в ветке Asa стал выглядеть вот так:

Akira

В это же самое время Akira бранчует свою ветку с того же самого мастера, что и Asa.
И просто вычищает все, что в проекте не пригодится за пару коммитов и приводит вид кода к принятому гайдлайну.
В итоге в её ветке код выглядит так:

С чего-то поменялся мастер.

В это время прямо в мастере какой-то хрен добавляет в Main.c Copyright. Это могло случиться в результате того, что в мастер вмержили ветку, в которой закончили разработку раньше, чем в ветках Asa и Akira.

И в итоге мы получаем вот такое состояние веток в репозитории:

Что делать, Akira? Надо мёржить)

Допустим, первой в мастер мёржить стала Akira. Она сделала это просто командой merge (ай-ай-ай! Плохая Akira!) вот так, и напоролась на конфликт:


В SourceTree мы видим, как появились какие-то незакоммиченные изменения. Эти изменения создал сам git, чтобы обозначить, что его смутило в файлах. Недолго думая, находим в списке файл с восклицательным знаком — это значит, там есть конфликты, нажимаем по нему правой клавишей мыши, выбираем Resolve Conflicts -> Launch External Tool.


Открывается утилита разрешения мерж конфликтов. Она выглядит, как 3 текстовых редактора в одном — сверху два, и снизу один. Сверху слева — что было в мастере, справа — что у вас (точнее, сейчас у Akira), снизу = что будет в итоге. Снизу справа выбор Actions для быстрого выбора — оставить то, сто справа, слева, оба и т.д. Нам нужно оставить изменения из мастера про Copyright, поэтому просто выбираем оставить то, что слева.


Сохраняем и выходим (нажимаем Cmd+s, потом Cmd+q).
Конфликт разрешен, больше конфликтов нет, зато появился файл main.c.orig — это просто копия файла до разрешения конфликта. Я их сразу удаляю на фиг.
Теперь вручную закоммитим изменения:

git commit

В появившемся vim-е просто набираем ESC, пишем :wq для выхода с сохранением, так как за нас все уже заполнено, и жмем ентер — всё, смержили.

Asa и rebase.

Asa пошла другим путем — она решила заюзать rebase — то есть сделать так, как будто ее ветка стартовала с крайнего в мастере коммита — с мержа Akira. Она делает вот что, и напарывается на конфликт:


Но не нужно отчаиваться, просто открываем SourceTree, там открываем Merge Tool, как и в прошлый раз, нажимаем Cmd+D (найти следующий конфликт). Видим картину:


Всего лишь надо выбрать префиксного или постфиксного инкремента. Выбираем правую часть, потому что так хочется. Привычные Cmd+s, Cmd+q.
SourceTree показывает, что проблем больше нет, можно продолжать процедуру rebase.

git rebase --continue

И, черт побери, опять конфликт!


Но мы уже знаем что делать. SourceTree->Resolve Conflicts->External Tool. Видим картину:

Хехх, а тут надо чуточку подумать.
Было:

trace_puts("Hello ARM World!");

У нас:

// Send a greeting to the trace device (skipped on Release).
 trace_puts("Hello ARM World! My name is Asa!");

Надо оставить свою часть, но при этом удалить комментарий. Что мы и делаем. Переходим к следующему конфликту по Cmd+d.

Конфликт, очевидно, решим в точности так же, как и предыдущий. Конфликтов больше нет. Cmd+s, Cmd+q.

git rebase --continue

На этот раз все заканчивается благополучно, видим завершение rebase в консоли:


Теперь посмотрим что стало с нашим деревом коммитов.


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

git push --force origin asa

То есть заставить удаленный репозиторий полностью переписать свою ветку asa нашей веткой asa.

Теперь в идеале надо удалить ветку akira, схлопнуть ветку asa до одного коммита с помощью команды git rebase -i, и вмержить получившийся коммит в master. Тогда история в master будет красивая и линейная. Но, хоть это и не сложно, но я хочу спать, так что в следующий раз.

P.S.
В следующей части думаю описать еще следующие штуки (если, конечно, это требуется):
1. Возвращение из стейджа. Хождение по коммитам. Кейс: 1 файл откатить назад на 2 версии, отредактировать, впилить в мастер.
2. В ответ на комментарий про Роскомнадзор и поднятие своей системы контроля версий хочу рассказать, что делать, если удаленный репозиторий более недоступен, а работать надо. Как можно все сделать в локальной сети или даже локально на машине.
3. Зачем нужно выбирать язык в GitHub (и наверное в BitBucket), и про .gitignore.