[devel-distro] Глядя на жуть в коммитах m-p-d

[Денис Смирнов]

On Tue, Dec 01, 2009 at 08:03:24PM +0700, REAL wrote:

R> А можно не только над m-p-d? Знаю, что этот rebase существует, но не 
R> знаю ни для чего он, ни как использовать. Просто для саморазвития, и 
R> для того, чтобы не тратить время на самостоятельное освоение, думаю, 
R> не только я с удовольствием послушаю.

Когда над одним проектом работает более одного человека, часто получается
следующая ситуация:

A (начальный коммит) -> B (работа одного человека)  \_ merge
                     -> C (работа второго человека) /

Чем это плохо? Нет последовательности коммитов. Вместо линии получается
граф, и чем больше людей работает над проектом и делают merge друг у друга
-- тем более страшной получается история.

Это делает невозможным нормальное применение таких инструментов как
git-bisect, например. Да и просто разбираться в этой каше -- неудобно.

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

Путь 1: merge
Путь 2: cherry-pick (по сути это "наложить патч из вон того коммита на
текущий коммит, сохранив заголовки и авторство патча")

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

Теперь другой вариант -- я сделал много-много-много изменений. Делать git
cherry-pick ты задолбаешься. Поэтому есть git rebase -- упрощенно это как
раз "сделать git cherry-pick на все патчи из моего дерева, поверх вон того
дерева", но гораздо более умный -- может пропускать уже интегрированные
патчи, и т.д.

Мой подход выглядит так:

# предварительно настроено чтобы его master ко мне импортировался как
# бранч с именем 'boyarsh'
git fetch boyarsh
# надо находится в своем master
git checkout master
# делаем rebase
git rebase boyarsh
# на этом этапе все мои изменения будут наложены поверх самого свежего
# бранча boyarsh

# если возникли конфликты -- правлю, делаю git update-index (все как при
# merge), но вместо git commit даю команду:
git rebase --continue

# если данный патч надо просто проигнорировать, например он был уже
# интегрирован и теперь просто пустой, то:
git rebase --skip

Под конец процедуры все мои патчи наложены поверх последнего бранча
boyarsh.

Теперь остается только сделать повторную сборку, убедиться что все Ok, и
можно делать git push.

На этом этап возникает некоторая сложность -- это не будет commit
наследник того, что было у нас раньше за push'ено. Поэтому git push надо
делать с --force, ну или соответствующим образом .git/config писать ;)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel-distro/attachments/20091201/a65dca41/attachment.bin>