GitUM: различия между версиями

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


* http://git.etersoft.ru/people/piastry/packages/?p=gitum.git
* http://git.etersoft.ru/people/piastry/packages/?p=gitum.git
== Ссылки ==
=== Почему не merge ===
* http://gitready.com/advanced/2009/02/11/pull-with-rebase.html
* http://randyfay.com/node/103 : git config --global branch.autosetuprebase always
* http://gitevangelism.blogspot.com/2011/02/git-push-force-and-merging-without.html
* http://libav.org/git-howto.html (Проект libav: «merge commits are forbidden»)
* http://www.kerrybuckley.org/2008/06/18/avoiding-merge-commits-in-git/
* http://yannesposito.com/Scratch/en/blog/2010-03-23-Encapsulate-git/
Обратная точка зрения:
* http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html


== Заключение ==
== Заключение ==


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


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

Версия 15:11, 1 августа 2012

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

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

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

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

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

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

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

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

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


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 ]


Исходный код

Ссылки

Почему не merge

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

Заключение

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

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