Здравствуйте, AlexNek, Вы писали:

AN> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
AN> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка.
Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.

AN> Вот нашел еще один огромный минус
AN>

AN> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN> * Unix-ориентированность и глубокий unixway во всём;

Эээ... оно не сильно отлчиается от svn.

AN> и еще
AN>

AN> Ревизии обозначаются с помощью SHA1-хэшей, с одной стороны они уникальны, с другой — возникает необходимость оперировать большими строками хэшей вместо маленьких номеров.

Оперировать с идентификаторами ревизий практически не приходится. Трудностей не вызывает. Тем более достаточно обычно первых 5-6 символов хеша. А запоминать ревизию 23723 и bd94f особой разницы нет.

AN> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
AN> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.

AN> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты.
AN> .>Тем, что коммиты маленькие.
AN> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.

AN>

AN> добавить текущие незакоммиченные изменения в стек изменений и сбросить текущую рабочую копию до HEAD'а репозитория;

AN> непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим.
Я имел в виду, сиутацию, когда ты делаешь что-то новое, поломал кучу кода, ничего пока не работает и ВНЕЗАПНО надо сделать какой-то хотфикс.

AN> .>[делаем хотфикс обнаруженных багов]
AN> .>git commit
AN> .>git push

AN>

AN> вносим изменения в удаленный репозитарий (удаленную ветку)

AN> А тут обломов не бывает?
Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом.
Или что ты имеешь в виду под обломом?

AN>

AN> применить последнее изменение из стека к текущей рабочей копии и удалить его из стека;

AN> То есть имеется еще какой то локальный стек изменений?
Тупо для удобства сделано — ветки автоматом создаются и в стек складываются, потом достаются. Автоматизация частого юзкейса.

AN> .>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса.
AN> .>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен.
AN> Это совсем не понятно куда денутся мои изменения?
В локальной ветке останутся, продолжишь работу в понедельник.
Хотя полезно ветку куда-нибудь на другой сервер запушить, чисто ради бекапа, если за выходные твой комп сломается или потеряется.