Минимизации усилий пост

[beldmit]

Наблюдаю в дружественной конторе следующую ситуацию:

1. Есть продукт, который они пилят. С выпускаемыми версиями и прочим. При выпуске новой версии upstream-ом на неё надо переходить.

2. Есть большой патч к этому продукту разработки собственно этой конторы. Его необходимо всегда иметь в актуальном виде одним куском. Применяться он должен к апстриму.

3. Есть набор патчей третьей стороны, который должен жить отдельными кусочками, но попадать в итоговую сборку. Поштучно.

Как этот РАБКРИН лучше обустроить?

Мне в голову приходит сценарий с двумя ветками, соответствующими пп. 2 и 3, с периодическими git rebase сначала ветки со своими патчами на апстрим, а потом ветки с патчами третьей стороны - на то, что получилось в "своей" ветке. Или я неправильно понимаю, что есть git rebase?

Comments

[beldmit.livejournal.com]

А зачем 3-4?

[gegmopo4.livejournal.com]

Одна ветка — ванилла (п.1). В неё выкладываются свежие версии апстрима и больше никаких изменений. После этого ответвляется ветка для сторонних патчей (п.3). Когда они наложены, ответвляется ветка для своих патчей (п.3). Если приходят новые сторонние патчи, они накладываются на вторую ветку и мержатс в третью. Когда выходит новая версия, обновляется первая ветка, от неё ответвляется новая вторая ветка, на которую заново накладываются сторонние патчи (или сразу мержатся из старой второй), от которой ответвляется новая третья ветка, в которую мержится старая третья ветка. В любой момент доступны апстрим, апстрим со сторонними патчами и со всеми патчами для любой версии. Если новый апстрим окажется слишком ломаным, всегда можно откатиться на старую версию со всеми патчами и продолжить накладывать свои изменения, пока апстрим не починят.

Если сторонние и свои патчи мало пересекаются и независимы, можно в третьей ветке (ответвляемой от второй) поддерживать только свои изменения, а мержить вторую с третьей в четвёртой.

Но может быть git не так работает, я с точки зрения svn и hg.

[besm6.livejournal.com]

vanilla есть и так.