История изменений

Забей. Без деталей того, что тебе нужно я не могу сказать что тебе подойдет. Может твои мысли верные, а мои нет. Сделай минимум: без лишних усложнений, без излишних упрощений.

Не знаю, хорошая это аналогия или нет. Взгляни на слои в gimp (photoshop). Каждый слой отображает конечную версию рисунка. В отличие от самого рисования в gimp, где слои можно совмещать, у тебя каждый слой это конечная версия кода, и единственная. Твоя же задача упрощается, когда ты можешь явно указать к какому слою следует обратиться, чтобы вернуть все назад И продолжить от этого момента новую версию [развития событий].

Без бранчевания ты можешь извращаться через rollback, overcommit (дописывания в текующую ветку того, что уже было) и т.п. Может, тебе этот путь будет проще и более понятен. Смысл бранчевания в моем случае: избежать перезаписи кода, взамен сразу же откатившись в нужную точку/ветку+ревизию (она будет последней).

Если у тебя один файл на проект и/или твой код-помощник никак не зависит от кол-ва используемых проектом файлов, то тебе хватит одной ветки. Когда код-помощник будет выплевывать разный код в зависимости от входных файлов, тогда стоит глянуть на концепцию с бранчами.

Еще раз, это все в общем виде. И читать мысли я пока не умею =)

P.S. Бранчу нужно создавать тогда, когда изменились входные данные (пользователь создал новый файл и от его содержания выхлоп изменился).

Забей. Без деталей того, что тебе нужно я не могу сказать что тебе подойдет. Может твои мысли верные, а мои нет. Сделай минимум: без лишних усложнений, без излишних упрощений.

Не знаю, хорошая это аналогия или нет. Взгляни на слои в gimp (photoshop). Каждый слой отображает конечную версию рисунка. В отличие от самого рисования в gimp, где слои можно совмещать, у тебя каждый слой это конечная версия кода, и единственная. Твоя же задача упрощается, когда ты можешь явно указать к какому слою следует обратиться, чтобы вернуть все назад И продолжить от этого момента новую версию [развития событий].

Без бранчевания ты можешь извращаться через rollback, overcommit (дописывания в текующую ветку того, что уже было) и т.п. Может, тебе этот путь будет проще и более понятен. Смысл бранчевания в моем случае: избежать перезаписи кода, взамен сразу же откатившись в нужную точку/ветку+ревизию (она будет последней).

Если у тебя один файл на проект и/или твой код-помощник никак не зависит от кол-ва используемых проектом файлов, то тебе хватит одной ветки. Когда код-помощник будет выплевывать разный код в зависимости от входных файлов, тогда стоит глянуть на концепцию с бранчами.

Еще раз, это все в общем виде. И читать мысли я пока не умею =)