Здравствуйте, ., Вы писали:
.>Здравствуйте, AlexNek, Вы писали:
AN>> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
AN>> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой 
.>Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка.
.>Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.
Сколько нужно пока не знаю, но списки команд довольно приличные.
Кстати, решил сегодня попробовать git svn. Пока ничего отрицательного, но комп пришлось оставить включенным, оказывается в хеаде почти 79 тыс. файлов.
Кому еще захочется, вот пару ссылок
An introduction to git-svn for Subversion/SVK users and deserters
Downloads — msysgit — Git for Windows Говорят, что git svn есть только 3,4 ссылках.
Git Extensions | Download Git Extensions software
AN>> Вот нашел еще один огромный минус 
AN>> AN>> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN>> * Unix-ориентированность и глубокий unixway во всём;
.>Эээ... оно не сильно отлчиается от svn.
Они вроде и есть но как то еще ни разу не попадались
AN>> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
AN>> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
.>Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.
Java IDE. Не... такое вообще не пробуем.
AN>> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты.
AN>> .>Тем, что коммиты маленькие.
AN>> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
.>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
.>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
Но получается только локально, а когда все закончил надо то в основную ветку забросить.
AN>> .>[делаем хотфикс обнаруженных багов]
AN>> .>git commit
AN>> .>git push
AN>> AN>> вносим изменения в удаленный репозитарий (удаленную ветку)
AN>> А тут обломов не бывает?
.>Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом.
.>Или что ты имеешь в виду под обломом?
Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?
