GitUM

Материал из Etersoft wiki
Перейти к навигацииПерейти к поиску

GitUm (Git Upstream Manager) — средство для поддержки работы над ответвлением проекта в git-репозитории

Краткое руководство

Gitum имеет 5 рабочих веток:

1. Ветка апстрим репозитория.

2. Ветка с патчами наверху — рабочая ветка, создаётся локально.

3. Ветка с непрерывной историей изменений.

4. Ветка с патчами в виде отдельных файлов — каждый коммит это состояние репозитория.

5. Ветка с конфигурационным файлом, где содержатся имена 4-х предыдущих веток. Носит всегда название gitum-config. Может отсутствовать - используются имена веток по умолчанию.


1) Создадим конфигурационный файл gitum

gitum create --remote origin/master --upstream upstream --rebased rebased --current mainline --patches patches

Где

  • origin/master — апстрим репозиторий/ветка (или просто любая локальная ветка — тогда без /), из которой будем тянуть изменения;
  • upstream — наша копия ветки origin/master;
  • rebased — ветка с нашими патчами наверху;
  • mainline — отображает последовательную историю;
  • patches — ветка с нашими патчами в виде отдельных файлов.


Три последние ветки создаются сами. То есть на момент выполнения команды нужно, чтобы существовала ветка master, в которой находится последняя копия удалённой ветки, с которой мы будем вытягивать изменения. Так же, если в качестве remote мы указываем локальную ветку, то она тоже должна существовать. (Указанные значения являются значениями по умолчанию в случае, когда create явно не указывает параметр.)


2) Перенесём изменения из апстрим репозитория

gitum merge [ --track ]

В процессе merge могут возникать конфликты слияния. Нужно разрешить очередной конфликт, добавить исправленные файлы командой 

git add

и продолжить процесс: 

gitum merge --continue


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

gitum merge --abort


Либо пропустить текущий патч и продолжить процесс: 

gitum merge --skip


В результате в ветке разработки mainline у нас появятся копии коммитов из удалённой ветки (сохранено описание, авторство и, по возможности,функционал). Так же вы сможете заметить, что история остаётся непрерывной и отсутствие коммитов вида: "Merge remote into local". Так же можно указать вручную с какой веткой проводить слияние, указав вначале: 

gitum merge --branch local_branch

или 

gitum merge --branch remote1/branch1

Опция --track позволяет сохранить указанную ветку для использования по умолчанию.


3) Сохраним изменения в gitum репозиторий

После того, как мы изменили ветку rebased (добавили коммиты или изменили старые), надо обновить ветки mainline и patches: 

gitum update


добавит результирующий diff между ветками rebased и mainline.


4) Восстановим исходное состояние рабочей ветки

Если после модификации ветки rebased решено вернуть её в предыдущее состояние, то используется команда 

gitum restore

которая так же принимает опцию --commit из ветки patches (по умолчанию — HEAD из patches).

В случае потери всех веток используется опция --full.


5) Склонируем удалённый gitum репозиторий

gitum clone GITUM-REPO DIR


что склонирует репозиторий по адресу GITUM-REPO в директорию DIR.


6) Вытянем изменения из удалённого gitum репозитория

gitum pull [ --remote REMOTE ] [ --track ]

при этом наши локальные патчи расположатся поверх новых изменений — история сохраняется.

Если в процессе наложения возникли проблемы, то нужно их исправить, сделать git add и дать команду 

gitum pull --resolved

или пропустить текущий патч (--skip), или прервать процесс и вернуть первоначальное состояние репозитория с помощью 

gitum pull --abort.

Опция --track позволяет сохранить указанный удалённый репозиторий для использования по умолчанию.


7) Сохраним изменения в удалённый gitum репозиторий

gitum push [ --remote REMOTE ] [ --track ]

Опция --track позволяет сохранить указанный удалённый репозиторий для использования по умолчанию.


8) Удалим gitum файлы из репозитория

gitum remove [ --full | --branches | --configfiles ]

Дополнительно

  • У gitum есть опция --repo ПУТЬ, которая указывает путь до gitum-репозитория. Если опция не указана, то поиск ведётся в текущем каталоге.

Примеры использования

Сюжет 1. Разработчик вносит изменения, создавая новые коммиты.

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

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

(Сейчас: спросит описание коммита и создаст один коммит в mainline!)

Сюжет 2. Мерж с апстримом

Иизменения из апстрима вынимаются в виде отдельных коммитов, при этом выполняется git rebase, возможно, выполняющий (возможно, с ручным вмешательством) изменение созданных у нас коммитов.

В результате в mainline должны быть перенесены коммиты апстрима (с их собственным описанием), а также добавлен коммит, изменяющий наши коммиты (с предложенным автоматически названием). Возможно, патчи изменений наших коммитов в mainline стоит разбивать по коммитам, и каждый называть "rebase: original commit message"


Замечания

  • Используется файл /tmp/gitum? Недопустимо.
  • Должен быть скрипт для тестирования (создание репозитория, веток, выполнение основных команд, проверка появления необходимых файлов)
  • Должен работать просто gitum create (с параметрами по умолчанию)
  • При начальной инициализации требует, чтобы ветка upstream была заранее руками создана — зачем это нужно?
  • Нужен пример создания gitum-репозитория на примере удалённого (с github)
  • При gitum update предлагает ввести описание коммита для mainline (где наследование?!): При update из rebased должны переноситься новые коммиты по отдельности (без вопросов об описании коммита), плюс изменения в репозитории, если есть, с запросом коммита.
  • В ветке patches полное дерево зачем-то ещё есть — можно от него избавится?
  • Просто gitum pull не работает
  • В рамках борьбы с абортами предлагаю заменить --abort на --abandon
  • gitum update работает только в корневой директории
  • Если выполнить не в корневой директории, отменятся последний commit


Исходный код

Ссылки

Почему не merge

Обратная точка зрения:

Заключение

Просьба ко всем, кому интересен данный проект его попробовать и написать свой отзыв в багу: http://bugs.etersoft.ru/show_bug.cgi?id=7690.

Приветствуются любые замечания и пожелания с вашей стороны!

Источник — http://wiki.etersoft.ru/index.php?title=GitUM&oldid=806