Главная ► Разработка ПО ► Системы контроля версий: начинаем работать с GIT

Начинаем работать с системой контроля версий GIT (для чайников)

(Часть 4.3.15. Rebase или как упростить историю коммитов)

4.3.15. Rebase или как упростить историю коммитов.

Когда разработка ведется в нескольких ветках одновременно, при объединении веток, история коммитов начинает сильно ветвиться. Для примера рассмотрим нашу историю коммитов приведенную на рисунке 53.

Как видно на рисунке присутствует небольшое ветвление коммитов. Синим цветом выделены изменения вносимые в ветке master, красным – изменения взятые из ветки next. Такое ветвление вызвано работой всего с двумя ветками и 13 коммитами. Представьте, что будет если у вас 3-4 ветки и несколько сотен коммитов, а если разработка ПО ведется не одним человеком, а командой из нескольких десятков разработчиков?

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

Давайте разберем работу этого механизма на примере.

Для начала приведем ветки master и next в соответствие между собой, так как из-за предыдущих изменений они разошлись и при объединении возникнет конфликт. Я делаю это, чтобы в следующем примере ничего не отвлекало от изучения механизма Rebase.

Переключаемся на ветку master и добавляем в нее все изменения из ветки next.Как объединять ветки описано в п 4.3.12.

В результате объединения образовался конфликт, приведенный на рисунке 54.

Конфликт при объединении веток.

Как устранять конфликты описано в пункте 4.3.13. Я решил оставить изменения и ветки master и ветки next, для чего открыл файл main.c и удалил спецсимволы (<<<<<<<< Head, =======, >>>>>>> ref/heads/Next) выделения мест конфликта, а затем сохранил изменения в ветке master. Переключаемся на ветку next и загружаем в нее изменения из ветки master, конфликтов здесь уже не возникнет, так что все очень просто.

Теперь, когда ветки master и next идентичны, приступим к подготовке примера. Внесем изменения в ветку next и master, для чего переключаемся на ветку next и вносим в файл main.c следующее изменение:

#include < stdio.h >
#include < unistd.h >

double t=0.1;
int y=7;
double g=6.9;

int main (void)
{
int k=0;
printf (“Hello word!!!\n”);
y=y+3;
g=g+t;
sleep (5);

return k;
}

Синим цветом выделена добавленная строка. Сохраняем изменения в репозиторий с комментарием «Change in next for Rebase».

Переключаемся на ветку master и вносим следующие изменения в файл prog1.c:

#include < math.h >
#include < stdio.h >

long int cube (int x)
{
printf (“%d\n”,x);
return x*x*x;
}

Синим цветом выделена добавленная строка. Сохраняем изменения в репозиторий с комментарием «Change in master for Rebase».

Добавим изменения внесенные в ветки next в ветку мастер с помощью механизма Rebase, для чего в меню Branch выбираем пункт «Rebase HEAD to» или «Rebase to HEAD».

«Rebase HEAD to» - объединяет выбранные коммиты с текущей веткой, как это показано на рисунке 55.

«Rebase to HEAD» - добавляет выбранные коммиты в начало текущей ветки, как это показано на рисунок 56.

Rebase HEAD to Rebase to HEAD

После выбора «Rebase HEAD to» или «Rebase to HEAD» в открывшемся окне (рисунок 57) выберите коммит, все изменения до которого (включительно) хотите добавить в ветку master (я выбрал коммит «Change in net for Rebase») и нажмите кнопку «Rebase HEAD to» или «Rebase to HEAD».

После этих действий, если не возникло конфликта, выбранные изменения будут добавлены в ветку master. В нашем случае конфликтов не будет, так как изменения в ветке master и next делались в разных файлах. Как разрешать конфликты описано в п. 4.3.13.

Приведу примеры нашей истории коммитов после добавления изменений из ветке next в ветку master с помощью merge (рисунок 58), Rebase HEAD to (рисунок 59), Rebase to HEAD (рисунок 60).

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

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

<<< Предыдущий раздел Следующий раздел >>>