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

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

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

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

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

и еще

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

AN>> Ну например, изменение и переименование файла происходит почти автоматом при переименовании имени класса. Как я понял, Гит этого не любит.
.>Почему не любит? Ему пофиг — переименовывай как хочешь, чем хочешь. Он сам всё что надо подхватит.
Не знаю, здесь где то было написано.

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

AN>> Также не совсем понятно как Гиту удается минимизировать конфликты.
.>Тем, что коммиты маленькие.
Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.

AN>> Вот например работа, с SVN небольшой команды в пятницу перед сдачей этапа в понедельник.
AN>> С утра все забрали актуальную копию репозитория, до обеда неспешная работа по исправлению ошибок, кто то успел закммитить исправления, кто то еще правит. После обеда тестеры вдруг находят еще пару багов кторые нужно непременно исправить сегодня.
AN>> Кто не успел доделать нужно бросить и править срочно найденные баги (можно либо текущее состояние куда скопировать, либо поверх править)

.>git stash

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

непонятно почему это начало работы. Что все мои изменения затрутся? Хочу просто взять текущее состояние и смержить с моим.
.>[делаем хотфикс обнаруженных багов]
.>git commit
.>git push

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

А тут обломов не бывает?
.>[пусть тестеры тестят]
.>git stash pop

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

То есть имеется еще какой то локальный стек изменений?
.>[вернулись к своим изменениям, продолжаем добавлять новые баги]

AN>> Ну вот вроде все сделал, через час домой, пора коммитить. А фиг вам низзя, надо вначале забрать актуальную версию.
AN>> При взятии выясняется что в паре файлов конфликты, причем довольно много. Разбираться некогда оставляем свою версию. Идем в историю каждого конфликтного файла имена которых записали на бумажке и переносим изменения сделанные другим разработчиком. Сделали, но прога не стартует. Провидение рекомендует глянуть журнал изменений за сегодня и похоже кто то изменил сопуствующий проект, но забыл закомиттить ДЛЛ-ку. Вроде все. Пробуем опять сохранить все, и опять непонятно почему облом. Брать изменения сейчас нельзя иначе не удастся просто потестить свои исправления, я знаю, что изменения сделал сосед и теперь мне будут приходит только "правильные" данные. Ищем изменный файл "вручную", по счастью мержится на автомате. Ок все работает, теперь берем все и проверяем еще раз. Все ок, но вечер пятницы безвозвратно утерян. (Может и немного присочинил, но для сравнения пойдет)

AN>> Подозреваю что с Гитом будет по другому, но интересно как?
.>Да, там можно делать бранчи. Притом легко. Можно тупо внести исправление в утренний trunk, создав бранч с этим хотфиксом. Или тупо всё коммитить, создать бранч от последней стабильной версии и в неё сделать cherry-pick хотфикса.
.>Изменения брать можно в любой момент времени — с твоими исправлениями оно пересечётся только при мерже, который не обязателен.
Это совсем не понятно куда денутся мои изменения?
.>В svn же ты обязан замержить текущие модифицированные файлы при update. Притом, если что-то пошло не так... вешайся. В гите же обычный мерж веток — не понравилось — отменил, оставил на потом.
.>А ещё есть магический rebase...
Пока искал описание комманд попалось несколько интересных ссылок
http://githowto.com/
http://www.proft.com.ua/2010/10/17/spravochnik-po-git-i-mercurial/
http://www.freesource.info/wiki/RuslanHihin/gitusermanual
http://www.altlinux.org/Справочник_по_git.alt
http://evasive.ru/articles/git_kung-fu.html
http://habrahabr.ru/blogs/Git/60347/
http://git.or.cz/course/svn.html
http://habrahabr.ru/blogs/Git/118924/