Я тут много предыстории написал, опциональной. Сами вопросы пониже.

....

На работе мы пользуемся SVN для контроля версий, а с Git я никогда нt работал, единственно вот сейчас начал пробовать, и потому вопросы...

Программа, которую мы разрабатываем (языки IEC), должна по заданию заиметь встроенный контроль версий (чтобы юзер эти IEC программы там хранил, ежели пожелает). Ну на подобии, как в ВисуалСтудию можно плагин вставить. Только тут попроще, никаких плагинов пока не надо, можно железно внедрить (по заданию минимум две) СистемыВерсий. Т.е. если возможно, то сделать какую-то абстракцию, но можно и без - а чисто разные имплементации. Выбор пал на Svn,Git, причем начальство решило что Git в первую очередь, а Svn ежели приспичит таки.

.....

Программа сохраняет эти IEC языки в запутанном формате, когда одна правка юзера может поменять сразу несколько файлов, причем эти файлы должны быть синхронны, т.е. нельзя один сохранить, а другому UNDO сделать. Это конечно плохо для СистемыВерсий. Да и сами файлы, если в них заглянуть сторонним вьювером - мало несут понятного юзеру, а часть из них вообще бинарная.

Потому для начала такое решение: коммитить всегда все изменённые файлы сразу и никогда по отдельности.

И еще, понятно, что с такими форматами файлов ни о каком MERGE и речи быть не может. Т.е. на первом этапе только такие операции:

Commit и откат к какой либо версии из истории коммитов, а потом либо Revert (т.е. опять на последнюю), либо Commit (т.е. сделать эту версию из истории - последней)

........

........

........

И вот собственно я и озвучил выше выделенным жирным ВОПРОС.

Как в Svn сделать я знаю. На примере TortoiseSVN это команды:

- Revert to this revision

- Commit

(пользуясь SharpSvn тоже без проблем).

Но как это сделать с помощью Git (а точнее Libgit2Sharp) ?

Причем, почему то мне хочется (может только потому что я новичек в Git) чтобы лишние ветки не плодились, а результат оказался на вершине ветки master, и ни один коммит из истории не пропал.

я не вполне понимаю предмет, но на "одна правка юзера может поменять сразу несколько файлов" напрашивается хранить не файлы, а "правки юзера". ну и какую-нибудь утилиту, способную с помощью чего-то исходного и "правки юзыря" (цепочки правок) получить актуальные файлы. иначе - геморрой, т.к. если человек имеет возможность сохранить не все файлы, он это когда-нибудь 100% сделает.

т.к. если человек имеет возможность сохранить не все файлы, он это когда-нибудь 100% сделает.

...

но вопрос то не в этом.

в самом конце темы озвучен

Для начала нужно к гиту через либу обращаться... Пока было через готовую прогу, поэтому, как через либу пока не знаю.

Вначале требуемые изменение записываются в Stage и он уже коммитится.

При этом в гите часто два репозитория - локальный и общий (bare). Локальный чисто для пользователя, общий - для связи команды.

По идее в вашем случае будет только локальный.

https://github.com/libgit2/libgit2sharp/wiki/git-commit

https://github.com/libgit2/libgit2sharp/blob/master/LibGit...

пардон, я слишком много написал и, наверное, только запутал.

Коротко задача такая:

- есть ветка Мастер в виде последовательных коммитов: Коммит1, Комми2, Коммит3, Коммит4

- Коммит4 является последним

- надо добавить в ветку новый коммит Коммит5 такой, чтобы все контролируемые файлы в точности соответствовали своему состоянию на момент Коммит2.

Те. Мастер будет как: Коммит1, Комми2, Коммит3, Коммит4, Коммит5

Причем состояние системы на моменты Коммит2 и Коммит5 - равны.

...

В Svn это делается так:

- Revert to this revision Коммит2

- Commit

А как это делается в Git?

надо различать два состояния

1. После Коммит4 есть изменения

2. После Коммит4 нет изменений

для 2 отличий от Svn по идее нет

- Revert to this revision Коммит2

- изменяем

- Commit

Для 1 вначале временно сохраняем изменения в Stash, Revert to this revision Коммит2, восстанавливаем изменения из Stash, Commit

https://stackoverflow.com/questions/3380805/checkout-old-c...

git rm -r .
git checkout Коммит2 .
git commit

Это сработает всегда. Если Коммит3 и Коммит4 не были мержами, можно сделать

git revert --no-commit Коммит3 Коммит4
git commit

Так будет быстрее, не надо все файлы стирать.

мы используем на работе графический интерфейс для работы с гит. SmartGit.

Я бы сказал что довольно таки прост в обращении.

Выделяешь файлы для коммита и переводишь их в опцию "Stage".

Потом активируешь коммит - заполняешь все описание и отсылаешь. Комми пока только локальный.

Преимущество - его можно "выловить" и подкорректировать. Как только ты его посылаешь на сервер то уже ничего поменять нельзя (только реверт).

Ветки ты можешь плодить, а можешь их потом и убирать.

У на работе

Dev / Master / Branches

Разрабатываем в Дев - после проверки софта - идёт в Мастер.

И по запросу проектов - некоторые вещи мы переводим в Бранчи.

Для этого делаешь "Cherry Peak" отдельного коммита и переводишь его в бранч, с последующим решением конфликтов.

НП.

Всем спасибо!

Я разобрался в этом вопросе (хотя еще масса не ясного).

Чтобы сделать "Revert to specific revision" в LibGit2Sharp нужно воспользоваться

LibGit2Sharp CheckoutPaths

правда придется сперва получить все измененные файлы между ревизиями (Diff)

а потом специально о добавленных и удаленных позаботится.

ну и Коммит, понятно в конце если устраивает