Сразу скажу — хотелось бы обойтись без священных войн.

Моя работа — написание программ на C# для использования на крупном предприятии (ну, т.е., "энтерпрайз"). До недавнего времени пользовался только SVN. Уже давно — лет семь. Всё устраивало. Слышал, разумеется, про git. Знаю, что он "распределенный" в отличие от "централизованного" SVN. Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Несколько раз пытался изучить git и перейти на него, но не понял, что мне это даст. Хотя, в принципе, умом понимаю, что он лучше, что VCS развиваются в этом направлении, и все такое. Недавно предложил мне коллега перейти на git (перевести наш проект). Кстати, над проектом работаем только мы двое. Может, присоединится еще пара человек.
Перевели — создали приватный репозиторий на гитхабе. Были трудности с импортом проекта из SVN, история не хотела подтягиваться. Но справились. Ок.

Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад .
Ну ладно, в большинстве случаев он все-таки работает, и тогда работа ничем не отличается от SVN: коммиты и апдейты все те же. Только коммит разбит на две фазы — локальный коммит и пуш. В студии даже кнопочка есть — Sync, все сразу делает, чтоб два раза не нажимать. В Гиточерепахе, кстати, тоже — предлагает пушить сразу после коммита.

Теперь проблемы. Я везде читаю о том, что в гите легкий мержинг и меньше конфликтов. Практика показывает — конфликтов ровно столько же, и это неудивительно, если двое правят одно и то же, конфликт неизбежно возникнет. Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория, куда должны пушить все программисты.

Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config).
Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии. Теперь он мне пишет:

An error occurred. Detailed message: An error was raised by libgit2. Category = Tag (Error).
This transport isn't implemented. Sorry

Что я, спрашивается, должен с этим делать?

Кстати, о git --config. Пару вопросов: зачем ему мой email?? И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Плюсану, аналогичные мысли по поводу SVN/Perforce <-> Git.
Обычно успокаивают словами "вы не умеете его готовить".
Мне больше всего Gite не нравится его как раз удаленность от офиса, может канал упасть или хост, а репозитарий нужен. Не часто, но у меня есть небольшой %% сборок на билд сервере не прошедший как раз из-за недоступности репы.

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

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания.

Берите Mercurial. Там всё в разы проще, а возможностей даже больше.

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Git в картинках

Автор(ы): Игорь Ткачев
Дата: 23.05.2011
Краткое введение в Git и Git Extensions.

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

_>Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад .
_>Ну ладно, в большинстве случаев он все-таки работает, и тогда работа ничем не отличается от SVN: коммиты и апдейты все те же. Только коммит разбит на две фазы — локальный коммит и пуш. В студии даже кнопочка есть — Sync, все сразу делает, чтоб два раза не нажимать. В Гиточерепахе, кстати, тоже — предлагает пушить сразу после коммита.

Не коммит разбит на две фазы, а это просто две совершенно разные операции — коммит в локальный репозиторий и передача истории локального репозитория в удаленный.

_>Теперь проблемы. Я везде читаю о том, что в гите легкий мержинг и меньше конфликтов. Практика показывает — конфликтов ровно столько же, и это неудивительно, если двое правят одно и то же, конфликт неизбежно возникнет.

В гите в некоторый момент времени был более умный алгоритм автомерджа. Сейчас может и сравнялись, кто знает.

_>Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория, куда должны пушить все программисты.

Удобно обмениваться срочными правками мимо центрального репозитория.

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ.

В SVN можно настроить точно так же — защищенный паролем приватный ключ. Мы, собственно, так и делали — это на порядки более надежный способ, чем защита паролем. В git, кстати, можешь вообще без паролей работать, если очень хочется.

_>Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер?

Это решение разработчиков или владельцев гитхаба, к гиту в целом оно не относится.

_>Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии. Теперь он мне пишет:

_>

_>An error occurred. Detailed message: An error was raised by libgit2. Category = Tag (Error).
_>This transport isn't implemented. Sorry

_>Что я, спрашивается, должен с этим делать?

Использовать более доделанный софт не вариант?


_>Кстати, о git --config. Пару вопросов: зачем ему мой email??

Гит делался разработчиками ядра Линукс для себя. У них все общение по email. Нафиг им коммиты от людей, с которыми невозможно связаться?

_>И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

Сделай в разных репозиториях разных пользователей, если надо.

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Лично я заметил следующие плюсы (из того, что реально заметно/используется)
1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.
2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
3) В git возможен коммит не всего файла, а частей.

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Так не меняй ничего, если все устраивает

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


_>Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше.

Не совсем так. Git и svn (я говорю про свежие версии, начиная с 1.8) примерно одинаково юзабельны, но заточены под принципиально разные сценарии использования.

Svn хорош для небольших проектов, когда над репозитарием работают не больше 20-30 человек (это с аналитиками-тестерами-дизайнерами). Главные преимущества:
* концептуальная простота, для работы достаточно освоить две кнопки "Забрать изменения", "отправить на сервер".
* офигенно удобная интеграция с VisualStudio от ankhSvn. Ничего хотя бы отдалённо напоминающего по удобству PendingChanges (см первый скриншот вот тут) для других систем контроля версий нет и походу не предвидится
* Простая работа с ветками, но ровно для одного сценария: отрезали ветку, периодически забираем исправления из транка, затем сливаем свои исправления в транк. Шаг вправо-влево — лучше не пробовать.

Для более крупных проектов единственно верная схема работы с svn начинают откровенно мешать, особенно если команда распределённая и стабильного канала связи у всех участников нет.
Git позволяет организовать произвольный workflow, но за это надо платить откровенно сырыми ui-инструментами (как бы поправимо, но за два года улучшений я особо не заметил) и необходимостью обучения _всей_ команды. Если хоть один человек не читал мануал, но склонен проявлять инициативу — очень легко получить примерно такие грабли в origin/master на ровном месте.

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

_>Сразу скажу — хотелось бы обойтись без священных войн.

Боюсь что это будет непросто

_>Пишем в Visual Studio. Там есть плагин для гита. Но он, к сожалению, кривой, то есть зачастую просто падает и операции не выполняет. Да еще и пишет "Sorry", гад .
_>Ну ладно, в большинстве случаев он все-таки работает, и тогда работа ничем не отличается от SVN: коммиты и апдейты все те же. Только коммит разбит на две фазы — локальный коммит и пуш. В студии даже кнопочка есть — Sync, все сразу делает, чтоб два раза не нажимать. В Гиточерепахе, кстати, тоже — предлагает пушить сразу после коммита.

_>Теперь проблемы. Я везде читаю о том, что в гите легкий мержинг и меньше конфликтов. Практика показывает — конфликтов ровно столько же, и это неудивительно, если двое правят одно и то же, конфликт неизбежно возникнет. Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория, куда должны пушить все программисты.

Когда говорят про "легкий мержинг и меньше конфликтов" имеют в виду следующее: git позволяет переписывать историю коммитов. Это дает тебе возможность перед пушем ветки на сервер сделать rebase к текущему master, что в свою очередь приведет к тому что влитие этой ветки в master гарантированно будет fast-forward слиянием без конфликтов. Естественно при ребейзевозможны конфликты, но
1) их будешь разрешать автор кода, а не его коллеги которые без понятия что он там написал
2) Конфликты будут происходить в контексте отдельных коммитов, а не как в SVN вот у тебя ветка, вот транк и между ними тысяча изменений.

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config).

git использует существующую инфраструктуру ssh ключей. Вы в M$ мире с ней не знакомы, поэтому вам приходится заниматься нетрадиционным сексом. В Linux мире SSH ключи есть практически у каждого админа/разработчика, а то и не по одной штуке.

_>Что я, спрашивается, должен с этим делать?

Писать в саппорт автору плагина к студии, очевидно.

_>Кстати, о git --config. Пару вопросов: зачем ему мой email??

Потому что авторство коммитов никак не привязано к аутентификации/авторизации на сервере. Аутентификация на сервер обеспечивается инфраструктурой SSH. Как только ты попал внутрь, ты волен делать там что угодно. Для авторства же коммитов используется емейл.

_>И второй: если я жестко задам юзера, как я буду работать с другим проектом, каждый раз менять его?

Смотри файл .git/config в папке своего проекта.

_>У гита больше команд, они сложнее. Нужно выучить такие понятия как staging, index, bisect и др. На форумах часто спрашивают, как в гите сделать то-то и то-то, и в ответ получают магические заклинания. А выигрыш-то какой? Товарищ подсказывает, что в случае, когда центральный репозиторий станет недоступен, мы сможем просто по локалке пушить друг другу в частный репозитории. Да, это плюс, но как по мне, минусы он не перевешивает.

Выигрыш зависит от того как в вашей команде устроен процесс разработки. Если вы используете систему контроля версий как продвинутый аналог общей папки на сервере, никакого ощутимого выигрыша вы не получите.

В то же время есть команды которые используют git довольно эффективно для собственного процесса. Из того что применяется довольно часто:
1. Линейная история коммитов в человеко-читаемом виде
2. Code review на основе pull requests
3. Feature branches (в SVN это ужасный геморрой со слияниями)
4. Несколько серверных репозиториев (например, для команды и для заказчика) между которыми передаются строго определенные изменения (например, в репозиторий заказчика попадает только тот код за который он заплатил)

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

DO>Git в картинках

Автор(ы): Игорь Ткачев
Дата: 23.05.2011
Краткое введение в Git и Git Extensions.

> Git гораздо быстрее Subversion.
SVN достаточно быстр для меня, а на скорость скачивания из интернета, где находится центральный репо, git не влияет.

> Git репозиторий в десятки раз компактней репозиториев Subversion (примерно в 30 раз меньше на примере проекта Mozilla).
У нас свой сервер с обыкновенным (т.е. большим жестким диском), размер репо на сервере мне безразличен, а на клиенте SVN держит только чистые копии, а не все хранилище.

> Git с самого начала разрабатывался как распределённая система контроля, позволяющая каждому разработчику иметь полный локальный контроль над репозиторием.
История разработки не является фактическим аргументом ЗА или ПРОТИВ.

> Ветки (branches) в Git гораздо легче и работают значительно быстрее.
SVN тоже хранит только дельты, про скорость см. выше.

Здравствуйте, Нахлобуч, Вы писали:

Н>Берите Mercurial. Там всё в разы проще, а возможностей даже больше.
Спасибо, буду пробовать.

Н>Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.
Да, в SVN рекомендуется делать бэкап рабочей копии перед сложным апдейтом. Однако, замечу, что настолько сложные апдейты бывают редко, в основном, когда разраб забил на практики и месяцами не синхронизировался. Получается, что GIT и Hg заставляют делать как бы бэкап, а в SVN это остается на совести пользователя. И тут получаем зеркальный аргумент — конвенции, оказывается, нужно соблюдать как в GIT, так и в SVN.

Если вы не понимаете преимуществ git'a или они для вас не критичны/не актуальны и при этом svn устраивает, то и не меняйте ничего, пользуйтесь svn. Svn не умер, вполне себе развивается, новые фичи добавляются. Зачем менять инструмент, если выигрыш от нового не очевиден?

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

DO>Если вы не понимаете преимуществ git'a или они для вас не критичны/не актуальны и при этом svn устраивает, то и не меняйте ничего, пользуйтесь svn. Svn не умер, вполне себе развивается, новые фичи добавляются. Зачем менять инструмент, если выигрыш от нового не очевиден?

Меня смущает, что все в инете хвалят, теперь и коллега на работе хвалит, а я не понимаю. Не хочется казаться ретроградом или тупым.

Здравствуйте, dmitry_npi,

Я думаю, что дело в том, что Вы не используете git напрямую, а пользуетесь всякими надстройками — плагин в студии, тортуизгит, клиент гитхаба. Эти надстройки либо пытаются работать одинаково со всеми VC, сводя на нет преимущества гита, либо заточены под особенности организации процесса разработки на конкретном сервисе (github заточен под open source). Используйте git напрямую, из коммандной строки, это сильно улучшит впечатление. Это не очень сложно, для повседневной работы нужно знать пордка пяти-десяти комманд, запоминается очень быстро, сначала можно держать под рукой шпаргалку.

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

Третий момент — github все-таки заточен под опенсорс, над которым работают много независимых лруг от друга разработчиков, там много отвлекающего и не нужного, bitbucket все-таки для закрытого проекта с 2 разработчиками заметно удобнее, как мне кажется.)

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

_>Меня смущает, что все в инете хвалят,
Не надо смущаться, это всего лишь значит что, для их целей git подходит лучше.

_>теперь и коллега на работе хвалит, а я не понимаю.
Вот пусть и объяснит преимущества.

_>Не хочется казаться ретроградом или тупым.
Разумный подход к выбору инструментов не делает из вас ретрограда.

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

_>Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.

Нет, слияние производится в рабочей копии.

_>Получается, что GIT и Hg заставляют делать как бы бэкап, а в SVN это остается на совести пользователя. И тут получаем зеркальный аргумент — конвенции, оказывается, нужно соблюдать как в GIT, так и в SVN.

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

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

T>Мне больше всего Gite не нравится его как раз удаленность от офиса, может канал упасть или хост, а репозитарий нужен. Не часто, но у меня есть небольшой %% сборок на билд сервере не прошедший как раз из-за недоступности репы.

Вообще-то при сравнении централизованной системы (Subversion) и распределенной системы (Git), все с точностью до наоборот — если недоступен репозиторий централизованной системы, то ... ничего и не получится. А в распределенной системе программист, как правило, использует локальный клон удаленного репозитория, и спокойно с ним работает (просматривает историю, фиксирует изменения ит.п.). И по мере необходимости синхронизирует его с удаленным репозиторием.

Здравствуйте, Хон Гиль Дон, Вы писали:

_>>Что я, спрашивается, должен с этим делать?

ХГД>Использовать более доделанный софт не вариант?

Я предпочитаю неинтегрированные в Студию средства работы с репозиторием (хватило VSS в свое время). Для гита мне понравился SmartGit, удобно работать с несколькими разными проектами.

ХГД>Лично я заметил следующие плюсы (из того, что реально заметно/используется)
ХГД>1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.
ХГД>2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
ХГД>3) В git возможен коммит не всего файла, а частей.

ИМХО стоит упомянуть про stash — чертовски удобная штука, которой не хватало в Свине.
Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

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

_> Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Хоть я сам предпочитаю Git и согласен, что в целом он намного лучше и удобнее, всё же должен предупредить, что возможности SVN он полностью не перекрывает.
1. Если в репозитории есть регулярно меняющиеся бинарные файлы, гиту от них может стать хреново (будет тормозить, а то и отказываться клонировать репозиторий). Некие костыли есть, но работать с ними не очень комфортно. С SVN, правда, я лично не сравнивал, но слышал, что он к бинарникам относится терпимее.
2. В SVN можно на время залочить файл, внести изменения и потом разлочить. Это гарантирует, что, во-первых, никто не сможет вклиниться в серёдку рабочего процесса и вызвать необходимость мёрджа, и во-вторых (что, пожалуй, важнее), у всех будет информация, что именно этот файл в данный момент редактируется, и вместо того, чтоб начать править его "прям ща", лучше подождать, пока сотрудник не закоммитит. Особенно полезно, опять же, в случае правки бинарных файлов (например, doc/xls/odt/pdf), которые мёрджить затруднительно. У гита же, как и у любой распределённой системы, такой функциональности не может быть в принципе. У каждого свой репозиторий, и даже если бы был какой-то флажок "занятости" файла, синхронизировать этот флажок принудительно во все клоны невозможно (комп может быть банально отрезан от сети).

P.S. Да, я согласен, что второй пункт — это палка о двух концах. Сами не раз нарывались, что кто-то залочил файл и ушёл в отпуск / заболел / уволился (к счастью, есть принудительный анлок); и что для команды в 10 человек это подходит, а когда 1000 человек, будешь сто лет ждать очереди; и так далее. Важно не это, а что такая возможность в принципе имеется, а как ей пользоваться — детали организации рабочего процесса.

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

SVZ>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

Не в порядке спора

В SVN для этого просто используются выборочные коммиты. Ну или changelists, если файлов много. Это чисто локальная штука, представляет из себя просто список файлов. В UI файлы отображаются группами (как пример — нижний скриншот вот тут). При коммите выбираем только нужные changelist, коммитим.

Для более-менее долгих задач удобней всё-таки полноценные ветки, тут dvcs побеждают с диким отрывом
Справедливости ради, в svn свитч с ветки на ветку не так быстр, как в git, но тоже терпимо. От полуминуты на мелком проекте до 10-15 минут на гигабайтах исходников (это вместе с поиском ветки в repository browser, он в tortoiseSvn знатно тупит).

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

ХГД>>Использовать более доделанный софт не вариант?

SVZ>Я предпочитаю неинтегрированные в Студию средства работы с репозиторием (хватило VSS в свое время). Для гита мне понравился SmartGit, удобно работать с несколькими разными проектами.

Так неинтегрированные для гита как раз обычно и есть более доделанные Мне, например, тортилы почти всегда хватает, изредка только пользуюсь Git GUI — если надо коммитить не файлы целиком, а отдельные изменения.


SVZ>ИМХО стоит упомянуть про stash — чертовски удобная штука, которой не хватало в Свине.
SVZ>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

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

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

CF>Хоть я сам предпочитаю Git и согласен, что в целом он намного лучше и удобнее, всё же должен предупредить, что возможности SVN он полностью не перекрывает.
CF>1. Если в репозитории есть регулярно меняющиеся бинарные файлы, гиту от них может стать хреново (будет тормозить, а то и отказываться клонировать репозиторий). Некие костыли есть, но работать с ними не очень комфортно. С SVN, правда, я лично не сравнивал, но слышал, что он к бинарникам относится терпимее.

С бинарниками ж вроде гит в последнее время терпимо работает. Т.е., пару лет назад вообще вилы были (мы еще с SVN'овских времен храним в репозитории собранные либы — буст и прочее), иногда коммиты обламывались по нехватке памяти и прочие чудеса творились. А сейчас, тьфу-тьфу, просто тормозит. Но, по-моему, эта скорость вполне на уровне обычной скорости SVN.

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

SVZ>>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

S>Не в порядке спора

S>В SVN для этого просто используются выборочные коммиты. Ну или changelists, если файлов много. Это чисто локальная штука, представляет из себя просто список файлов. В UI файлы отображаются группами (как пример — нижний скриншот вот тут). При коммите выбираем только нужные changelist, коммитим.

Я, кстати, никогда этой функцией не пользовался. Сейчас почитал твою статью, Stash это немного другое.

"ignore-on-commit" не дает закоммитить файл по ошибке. А Stash позволяет запомнить текущие правки, затем откатиться к исходной версии, внести в нее другие изменения, их закоммитить, а потом продолжить прерванную работу. И всё это без переключения между ветками.

Тут рядом Хон-Гиль-Дон верно сравнил его с локальными ветками. По сути то же самое, только ветку создавать не надо, этакий "синтаксический сахар".
Когда задачи небольшие, скажем, на день, то лениво выделять под задачу отдельную ветку. Хотя это вопрос организации работы.

S>Для более-менее долгих задач удобней всё-таки полноценные ветки, тут dvcs побеждают с диким отрывом
S>Справедливости ради, в svn свитч с ветки на ветку не так быстр, как в git, но тоже терпимо. От полуминуты на мелком проекте до 10-15 минут на гигабайтах исходников (это вместе с поиском ветки в repository browser, он в tortoiseSvn знатно тупит).

Это верно, особенно на разлапистых проектах с большим числом веток. У Тортиллы еще неудобно, что многие операции делаются Drag-n-drop'ом на дереве. Очень легко промахнуться.

_> Вообще-то при сравнении централизованной системы (Subversion) и распределенной системы (Git), все с точностью до наоборот — если недоступен репозиторий централизованной системы, то ... ничего и не получится. А в распределенной системе программист, как правило, использует локальный клон удаленного репозитория, и спокойно с ним работает (просматривает историю, фиксирует изменения ит.п.). И по мере необходимости синхронизирует его с удаленным репозиторием.

Я как бы в курсе про DCVS, приходится работать.
Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична.

S>* Простая работа с ветками, но ровно для одного сценария: отрезали ветку, периодически забираем исправления из транка, затем сливаем свои исправления в транк. Шаг вправо-влево — лучше не пробовать.

Обычно несколько разная схема работы с ветками.
В свн каждая ветка в локальном репозитории лежит в отдельной папке.
В гите — все в одной папке.
Может занимать много места, и в гите можно переключаться, не закрывая студии.

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

T>Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична.

Вах, а что, гит не ставится на локальном сервере?

ХГД>1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.

Если сеть быстрая, то всё вполне терпимо.
Чисто локальные операции, такие как svn st/git status сравнимы. На больших репозиториях SVN (у меня) отрабатывает быстрее.

А вот svn checkout/git clone — тут git просто в клочья рвёт svn.

ХГД>2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
Сейчас вполне возможно, но в git-е проще и удобнее.

ХГД>3) В git возможен коммит не всего файла, а частей.
В svn Такого нет, но TortoiseSVN позволяет (Restore after commit).
И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

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

_>Пишем в Visual Studio. Там есть плагин для гита.

Для начала: существует TFS, и для ВижуалСтудии он подходит идеально. Всякого рода гиты с эсвээнами для студии все же чужеродны.

_>Децентрализация. А зачем она?

Чтобы можно было работать при хреновом интернете, в отсутствии связи с интернетом. Например, на выезде у заказчика отдельная изолированная сеть. Или где-нибудь на якутских заболоченных просторах.

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https.

https существует не только для защиты пароля. Ключ SSH для SSH используется, как клиентский сертификат в SSL

_>ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ.

Не надо. Ключи SSH вообще шифровать необязательно.

_>https, а можно по ssh. Я вообще раньше думал, что это одно и то же...

Боже мой. facepalm.jpg

_>чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Для меня в гите есть такая удобная вещь, как stash. Можно засунуть туда локальные изменения для большой и долгой работы, быстренько сделать срочную работу — баги поправить, достать изменения из stash обратно и продолжить.

По сравнению с TFS у гита преимуществ я не вижу. А, еще ключ ssh можно на токен записать и ходить с ним, нет ключа — чужой не подключится. Это удобно, когда на основной работе занимаешься другими проектами.

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

Q>В свн каждая ветка в локальном репозитории лежит в отдельной папке.
Эмм, в svn вообще нет локальных репозиториев
Можно держать несколько Working Copy — по одной для каждой ветки, можно переключать одну и ту же Working Copy между разными ветками.

Q>Может занимать много места, и в гите можно переключаться, не закрывая студии.
Ну... .svn-репы обычно компактнее за счёт того, что история не хранится локально. На сервере — да, git эффективней в 2..5 раз, но кого это волнует?

Svn тоже не требует закрытия студии для свитча, AnkhSvn -> switch solution. Но по времени с гитом не сравнится конечно.

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

_>Моя работа — написание программ на C# для использования на крупном предприятии (ну, т.е., "энтерпрайз"). До недавнего времени пользовался только SVN. Уже давно — лет семь. Всё устраивало. Слышал, разумеется, про git. Знаю, что он "распределенный" в отличие от "централизованного" SVN. Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Если вам хватает возможностей SVN, вы вряд ли будете пользоваться дополнительными возможностями GIT. Скорее, они вас будут только раздражать.

Я лично предпочитаю HG. Он очень похож по командам на SVN (и на их общего "идеологического предка", CVS), но при этом распределенный. Плюсом распределенности, лично для меня, является возможность комфортной работы при (временном) отсутствии связи с сервером, и то, что многие операции делаются локально (без сервера), т.е., очень быстро.

Кроме того, мне очень не хватает в SVN нормальных бранчей. Для меня совершенно нормальный workflow, когда нужно сделать фичу, которая требует "рискованных" переделок в существующей codebase, без уверенности, что я нафиг все не наломаю, и что вообще эти переделки пойдут в дело, я создаю бранч, делаю все в нем, и когда все устаканится, вливаю его в trunk.

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

И наконец, это не всем важно, но мне помогает. HG очень легко "натянуть" на уже имеющееся дерево исходников. Т.е., начал что-то ковырять без уверенности, в дело это пойдет или в помойку, потом осознал, что все же в дело, "натянул" на исходники HG. Потом решил, что проект заслуживает копии на сервере — добавить ее тоже не проблема.

_>Несколько раз пытался изучить git и перейти на него, но не понял, что мне это даст. Хотя, в принципе, умом понимаю, что он лучше, что VCS развиваются в этом направлении, и все такое. Недавно предложил мне коллега перейти на git (перевести наш проект). Кстати, над проектом работаем только мы двое. Может, присоединится еще пара человек.
_>Перевели — создали приватный репозиторий на гитхабе. Были трудности с импортом проекта из SVN, история не хотела подтягиваться. Но справились. Ок.

На мой взгляд, GIT очень сложный и слишком непривычный.

_>Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии. Теперь он мне пишет:

Тут, видимо, дело в настройках. Я уверен, что GIT может работать с простой парольной авторизацией.

HG я вообще использую совместо с ssh, и авторизацией занимается SSH. Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль, но использовать ее не обязательно.

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

SJA>И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

Включать/выключать можно и отдельные строки, если речь об этом.

Здравствуйте, Нахлобуч, Вы писали:

Н>Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Эта обязательность заключается лишь в том, что меркурий, совершенно искусственно, не дает после merge сделать частичный commit (т.е., закоммитить не все измененные файлы).

Это не всегда так было, и не от большого ума сделано. Я даже пытался с ними поспорить на тему необходимости этого ограничения (когда оно появилось). Но они уперлись, а у меня красноречия не хватило

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

_>Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.

Нет. В репозитории не делается ничего. Репозиторий только хранит информацию. Все остальное делается локально.

SJA>>И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

M>Включать/выключать можно и отдельные строки, если речь об этом.
Да про это. Значит не верно понял, что читал про Git.

Да, действительно на клиенте можно в рамках одной wc легко переключаться между ветками.
Будет только switch to path вместо switch to branch.

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

Pzz> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.

Ай-ай-ай!!! Пароль на ключе должен быть.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>С бинарниками ж вроде гит в последнее время терпимо работает. Т.е., пару лет назад вообще вилы были (мы еще с SVN'овских времен храним в репозитории собранные либы — буст и прочее), иногда коммиты обламывались по нехватке памяти и прочие чудеса творились. А сейчас, тьфу-тьфу, просто тормозит. Но, по-моему, эта скорость вполне на уровне обычной скорости SVN.

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

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

Pzz>Эта обязательность заключается лишь в том, что меркурий, совершенно искусственно, не дает после merge сделать частичный commit (т.е., закоммитить не все измененные файлы).
Pzz>Это не всегда так было, и не от большого ума сделано. Я даже пытался с ними поспорить на тему необходимости этого ограничения (когда оно появилось). Но они уперлись, а у меня красноречия не хватило

Не понял, какое отношение частичный коммит после мерджа имеет к обязательной "чистоте" рабочей копии.

А насчет того, почему это запрещено -- тут можно поспоритью

В связи с этим возник такой вопрос: можно ли в свн смотреть лог сразу по всем веткам?
Чтобы он показывался не в виде линейной истории, а в виде дерева.

UPD. Конечно же, есть. Например, Tortoise SVN revision graph.
А вот, например, здесь показывается информация о мерджах.

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

M>>Включать/выключать можно и отдельные строки, если речь об этом.
SJA>Да про это. Значит не верно понял, что читал про Git.

В самой консоли это конечно замороченно. Оперировать там можно только с hunk'ами, но фокус в том, что их можно разбивать вплоть до отдельных строк.

В GUI-клиентах обычно все намного проще. В общем, лучше один раз увидеть: картинка

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

Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.

AB>Ай-ай-ай!!! Пароль на ключе должен быть.

Зачем?

Здравствуйте, Нахлобуч, Вы писали:

Н>Не понял, какое отношение частичный коммит после мерджа имеет к обязательной "чистоте" рабочей копии.

Допустим, у меня есть N измененных локальных файлов, и я хочу часть изменений выложить в репозиторий, а часть пока не выкладывать.

Если репозиторий успел измениться, и мне надо делать merge, это превращается в аццкий геморрой.

Н>А насчет того, почему это запрещено -- тут можно поспоритью

У них может быть 100500 причин, почему это запрещено, и почему это правильно запрещать, а разрешать не правильно. Оставьте все свои 100500 причин себе, а мне сделайте ручку, которая выключает ваши искуственные запреты.

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

S>* офигенно удобная интеграция с VisualStudio от ankhSvn. Ничего хотя бы отдалённо напоминающего по удобству PendingChanges (см первый скриншот вот тут) для других систем контроля версий нет и походу не предвидится

А можно узнать в чем крутость?? Окно как окно. Вроде во всех гуях окно, в котором коммитят изменения, примерно такой же вид имеет.

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

_>https, а можно по ssh. Я вообще раньше думал, что это одно и то же...
сразу бы вот это написал, и мы бы всё поняли.
*тебе* гит не нужен.

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

J>А можно узнать в чем крутость?? Окно как окно. Вроде во всех гуях окно, в котором коммитят изменения, примерно такой же вид имеет.

В юзабилити У AnkhSvn реально получилось сделать пульт управления рабочей копией svn


* Во-первых, окно видно постоянно, оно аттачится как docked panel. Поле с сообщением о коммите можно скрыть, поэтому панель не занимает много места.

* Во-вторых, одним взглядом можно увидеть все сделанные изменения и тикеты, над которыми работаешь (если изменения сгруппированы по changelist). Очень удобно, если нужно восстановить контекст после переключения с задачи на задачу.

* В-третьих, даблкликом по файлу в pending changes можно посмотреть сделанные изменения. Вместе с окном TortoiseMerge — офигенно удобная штука, т.к

	tortoise merge умеет схлопывать одинаковый текст.

Для того, чтобы быстро проверить файлы перед коммитом — самое оно.

* В-четвёртых все основные действия: обновить, коммит, откатить и т.д. выполняются в один клик из контекстного меню или вообще с панели инструментов. Удобно, т.к. не надо переключаться со студии на тортойз (или вообще на консоль).


Это только то, что я активно использую.

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

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

А отключать delta compression для этих тарболлов вы не пробовали? Мне помогло в похожей ситуации, правда теоретически должен был заметно увеличится размер репо, но я не проверял, так как этот вопрос меня совсем не волновал.

Mumitroller

Здравствуйте, Нахлобуч, Вы писали:

Н>Берите Mercurial. Там всё в разы проще, а возможностей даже больше.

проще — согласен, только откуда там больше возможностей?

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

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Мои личные аргументы очень просты, их 2:
1. Возможность иметь произвольное кол-во локальных бранчей, работая в одной папке.
Это действительно большой плюс. Можно очень быстро переключаться между тасками.
Даже если проект в целом подложен под SVN, делаю в папке локальный гит репозиторий для этой цели.

2. Очень гибкая работа с бранчами. Очень удобно разрабатывать каждую отдельной ветке и автоматизировать интеграцию фичи в релиз бранч(и).

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

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

_>>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

BRA>Мои личные аргументы очень просты, их 2:
BRA>1. Возможность иметь произвольное кол-во локальных бранчей, работая в одной папке.
BRA>Это действительно большой плюс. Можно очень быстро переключаться между тасками.
BRA>Даже если проект в целом подложен под SVN, делаю в папке локальный гит репозиторий для этой цели.

BRA>2. Очень гибкая работа с бранчами. Очень удобно разрабатывать каждую отдельной ветке и автоматизировать интеграцию фичи в релиз бранч(и).

Добавлю еще такую вещь как отсутствие tree conflicts. Не знаю, есть ли эта проблема еще в последних версиях SVN, но меня она бесила конкретно. Поэтому последние пару лет с SVN работаю только через git-svn.

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

A>проще — согласен, только откуда там больше возможностей?

А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial? Если про "легковесные ветки" -- то это Bookmarks и Changeset Evolution. Если про переписывание истории, то тот же Rebase и опять Changeset Evolution.

Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".

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

CF>> <…> Тогда и нагуглили, что бинарники с гитом не очень дружат, пришлось переделывать систему на хранение тарболлов в отдельном хранилище. Не исключаю, что в последних версиях гита это улучшили, но я не проверял.

M>А отключать delta compression для этих тарболлов вы не пробовали? Мне помогло в похожей ситуации, правда теоретически должен был заметно увеличится размер репо, но я не проверял, так как этот вопрос меня совсем не волновал.

К сожалению, не в курсе, этим другие сотрудники занимались.

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

С>Для меня в гите есть такая удобная вещь, как stash. Можно засунуть туда локальные изменения для большой и долгой работы, быстренько сделать срочную работу — баги поправить, достать изменения из stash обратно и продолжить.

Другие сорс-контролы называют это shelves

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

Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.

AB>Ай-ай-ай!!! Пароль на ключе должен быть.

ssh agent же

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

Pzz> Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.
Pzz> AB>Ай-ай-ай!!! Пароль на ключе должен быть.
Pzz> Зачем?

За тем, чтобы в случае его кражи (потеря ноута например), им не смогли просто так воспользоваться (если, конечно, выше не имелся ввиду ssh-agent с небольшим таймаутом хранения).

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

_>Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория

Незачем было столько писать, достаточно вопроса выше

Децентрализация — это неправильное слово, ближе по смыслу идёт АВТОНОМНОСТЬ, т.к. "децентрализация" подразумевает распределённый по разным физическим серверам сервис (но составляющий единое целое).
DVCS (бросьте это г**но git и юзайте Hg, мой совет) позволяет иметь как бы "карманную VCS", позволяющую делать вообще ВСЁ и при этом БЕЗОПАСНО. Захотел — создал ветку, не понравилось — откатился на год назад. Все эти операции делаются автономно и не затрагивают работу других людей, т.е. вы никому не испортите день, даже если наделали чудовищных изменений в репе. И только после того, как вы наэкспериментировались и добились идеального состояния репа, можно явить миру плод своих страданий — вот в чём радость DVCS! Ну и как бонус, имеем оффлайновый режим работы, позволяющий всё так же контролировать каждую ревизию, но при этом не искать судорожно WiFi, лёжа на "канарах".

Здравствуйте, Нахлобуч, Вы писали:

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

A>>проще — согласен, только откуда там больше возможностей?

Н>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial? Если про "легковесные ветки" -- то это Bookmarks и Changeset Evolution. Если про переписывание истории, то тот же Rebase и опять Changeset Evolution.

круто, а когда я юзал hg, там еще не было rebase
но я только не понял что делать после ребейза — разве там есть push --force и reset --hard как в гите? чтобы после ребейза залить ветку на сервер и потом синхронизировать другие рабочие копии

и еще, я почитал документацию к rebase и не заметил там --interactive

ну и еще я не понял как массово переписывать историю во всех коммитах, данные автора или коммитера например менять

Н>Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".
а вот этого я не понял, и коммитов таких я никогда не видел, только "merge pull request" и обычные "merge branch" иногда
наверное я как-то не так юзаю гит

Вот тут товарищ тоже измучился с ним: https://www.linux.org.ru/forum/general/10897902

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

AB> За тем, чтобы в случае его кражи (потеря ноута например), им не смогли просто так воспользоваться (если, конечно, выше не имелся ввиду ssh-agent с небольшим таймаутом хранения).
Во-первых, если украли ноут с ключом (не так уж это и часто происходит, да и кто ж ноуты без ecryptfs держит?), можно просто отозвать (revoke) доступ по нему.
Во-вторых, что в общем-то можно сделать страшного? Запушить коммит удаления всего? Так первый же verify build зарежет. Засунуть в код бекдор? Ревьювер пошлёт. Разрешен прямой push? Ну git revert. Разрешен force push? И что, reflog 30 дней живёт. Сумели зачистить reflog? И что, gc вроде 7 дней loose commits держит. Ну ладно, в худшем случае, если все коллеги по проекту тоже сразу внезапно потеряли свои ноуты с клонами, либо в отпусках и не фетчат изменения, бэкапы забыли настроить, то как минимум останется история до последнего релизного тега, т.е. максимум потеряется изменения текущего спринта.

В общем, единственный нормальный способ удалить данные из git это "rm -rf", притом на всех клонах одновременно.

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

С>Для начала: существует TFS, и для ВижуалСтудии он подходит идеально.

У TFS куча своих проблем и особенностей.

С> Всякого рода гиты с эсвээнами для студии все же чужеродны.

Гит, по секрету тебе скажу, сейчас для студии совсем не чужеродный, доступен искаропки и используется внутри МС в том числе и теми, кто пишет студию и инструменты для нее.

С>Не надо. Ключи SSH вообще шифровать необязательно.

Приватный ключ, который на клиенте, все таки надо прятать.

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

Pzz>Нет. В репозитории не делается ничего. Репозиторий только хранит информацию. Все остальное делается локально.

Но локально у гита весь репозиторий.

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

S> Это только то, что я активно использую.
Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ.

Ну ничего, вот clion пилят... Уже можно посмотреть.

Подсветка изменений, прямо в окне редактора. Полоска слева — отмечает для текущего видимого блока, и справа на сколллбаре все изменённые места всего файла. Можно тут же из редактора посмотреть старое значение и откатить, сделать дифф, либо скопировать в буфер обмена. Плюс внизу список изменений, и в дереве проекта изменённые файлики отмечены цветом.


Дифф одного файла. С возможностью тут же поправить. Заметь, подсветка ЯП, навигация по коду, всплывающая инфа никуда не девается как в том же tortoisemerge.


Просмотр лога. В данном случае совместно отображаются коммиты из двух репозиториев (главный проект и third party library). Мержи в логе выглядят как мержи, а не хрен знает что в svn.


Управление ветками, сразу по всем репо.


Ещё суперфича — просмотр истории произвольно выделенного блока текста (с учётом переименований/переносов между файлами). Сложно продемонстрировать скриншотом, к сожалению.

Что все операции работают практически мгновенно (меньше секунды), вроде должно быть очевидно.

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

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config).
_>Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии.

У меня знакомая-гуманитарий разобралась с регистрацией на гитхабе и ключами за пять минут; мне только про https/ssh объяснить и понадобилось.

Здравствуйте, Нахлобуч, Вы писали:

Н> A>проще — согласен, только откуда там больше возможностей?

Н> А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?
Может я всего не знаю о hg, но мне кажется, что из этого точно много чего не умеет:

octopus merge — слияние больше чем двух веток сразу.
subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием
index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов.
rerere — Reuse recorded resolution of conflicted merges
notes — добавление меток, аттачей поверх иммутабельной истории.
reflog — история истории.
gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки.
orphan branch — отдельная история в том же репо. Польза: тут, тут, notes и gerrit настройки репо тоже сирот эксплуатируют.
author/committer — инфа в коммите — тот кто сделал изменение и тот кто его опубликовал — разные люди|даты.
filter-branch — хитровывернутое перелопачивание репозитория для очищения истории. Например, массово заменить табы-пробелы.
log pickaxe — массовый поиск по истории регекспами.
git annex — манипуляция массивными файлами.
tracking file permissions, symlinks
.gitattributes — кастомизация всяких свойств различных файлов. Например, указать специальный алгоритм мержа файлов в некотором каталоге или unix line endings для всех .sh файлов.
shared clone — легковесный клон, который использует данные из репо на том же диске.
grafts/replace — механизмы для рефакторинга истории.
Простой, но очень мощный и гибкий формат репозитория.

Ы?

Н> Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".
И это правильно Как оно работает в mercurial — это противоречит духу DVCS совершенно, убогое наследие SVN. Вызывает трудности если требудется мержиться из многих репозиториев.

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

SVZ> T>Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична.
SVZ> Вах, а что, гит не ставится на локальном сервере?
Так там всё SVN-ом забито.

The Mozilla CVS repository was 2.7GB, imported to Subversion it grew to 8.2GB. Under Git, it shrunk to 450MB. Given that a Mozilla checkout is around 350MB, it's fairly nice to have the whole project history (from 1998) in only slightly more space.

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

S>> Это только то, что я активно использую.
.>Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ.

Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты

Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии.
Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge).
Вот подсветка изменений.

Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.

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

M>Когда говорят про "легкий мержинг и меньше конфликтов" имеют в виду следующее: git позволяет переписывать историю коммитов. Это дает тебе возможность перед пушем ветки на сервер сделать rebase к текущему master, что в свою очередь приведет к тому что влитие этой ветки в master гарантированно будет fast-forward слиянием без конфликтов. Естественно при ребейзевозможны конфликты, но
M>1) их будешь разрешать автор кода, а не его коллеги которые без понятия что он там написал
Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.

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

GIV>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.
И в результате получается неудобоваримая история.

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

.>>Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ.
S>Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты
Именно так.

S>Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии.
Неа.

S>Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge).
S>Вот подсветка изменений.
Ужас. IntelliJ понимает именно семантику кода — используемые типы, может делать рефакторинг и т.д. Тут просто подсветка блоков по matching'у скобок + простая подсветка синтаксиса.

Разница как между VIM и MSVS.

S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.
ЩИТО?

Ну хоть на IntelliJ посмотри. Или на гитхабовский клиент.

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

GIV>>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.
C>И в результате получается неудобоваримая история.

Где? Я как бы каждый день этим пользуюсь?

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

.>octopus merge — слияние больше чем двух веток сразу.

Этого нет by design.

.>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием

Не совсем понял, что это.

.>index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов.

Есть hg record, который так же позволят коммитить файлы по частям. Индекса нет, верно.

.>rerere — Reuse recorded resolution of conflicted merges
.>notes — добавление меток, аттачей поверх иммутабельной истории.

Этого нет.

.>reflog — история истории.

Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)

.>gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки.

Это не совсем Git.

.>orphan branch — отдельная история в том же репо. Польза: тут, тут, notes и gerrit настройки репо тоже сирот эксплуатируют.

Такое может.

.>author/committer — инфа в коммите — тот кто сделал изменение и тот кто его опубликовал — разные люди|даты.

Такое нет.

.>filter-branch — хитровывернутое перелопачивание репозитория для очищения истории. Например, массово заменить табы-пробелы.

hg convert

.>log pickaxe — массовый поиск по истории регекспами.

hg revsets в разы мощнее.

.>git annex — манипуляция массивными файлами.

hg largefiles

.>tracking file permissions, symlinks

Этого не знаю.

.>.gitattributes — кастомизация всяких свойств различных файлов. Например, указать специальный алгоритм мержа файлов в некотором каталоге или unix line endings для всех .sh файлов.
.>shared clone — легковесный клон, который использует данные из репо на том же диске.

Mercurial использует симлинки.

.>grafts/replace — механизмы для рефакторинга истории.

Всё это есть.

.>Простой, но очень мощный и гибкий формат репозитория.

Тут да.

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

GIV>>>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.
C>>И в результате получается неудобоваримая история.
GIV>Где? Я как бы каждый день этим пользуюсь?
Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?

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

AVK>Гит, по секрету тебе скажу, сейчас для студии совсем не чужеродный, доступен искаропки и используется внутри МС в том числе и теми, кто пишет студию и инструменты для нее.

Эта интерграция какая-то малоюзабельная. Проще работать с гитом из Тортисы или вообще из консоли

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

ZEN>Вот тут товарищ тоже измучился с ним: https://www.linux.org.ru/forum/general/10897902

товарищ не чтит доки.
более того, он не чтит даже то, что git ему прямым текстом написал.

Здравствуйте, Нахлобуч, Вы писали:


.>>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием

Н>Не совсем понял, что это.

На практике это значит, что можно импортировать другой репозиторй/каталог репозитория как подкаталог своего репозитория.
В дальнейшем с этим каталогом можно работать как со снапшотом исходного репозитория: git subtree pull, git subtree push, git subtree merge.
В остальном этот каталог ничем не отличается от других, в этом преимущество перед субмодулями.

.>>reflog — история истории.

Н>Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)

Пришлось перейти на гит как раз когда эта штука появилась. На данный момент её уже используют?

.>>git annex — манипуляция массивными файлами.

Н>hg largefiles

Annex по сути отдельная программа. Умеет всё вплоть до работы с амазоновским хранилищем.
largefiles это костыль. Официально не рекомендован.

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

S>Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты
Так поделаешь-то, если оно так и получается. Вот допилят clion, и плюсовики со Студии соскочат. Зачем микрософту стараться, ведь у них родной шарп, и куда денешься с подводной лодки?

S>Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии.
S>Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge).
Если оно и правда работает и юзабельно, то уже хорошо, становится похоже на IDEA9 или 10 (версия <2010 года). Сейчас пилят IDEA14.

S>Вот подсветка изменений.
И что характерно — только для git (и вообще специфичный софт для каждой vcs). SVN как всегда, лесом.

S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.
В IntelliJ вшита обобщённая поддержка vcs, так что таких бед нет.

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

F>товарищ не чтит доки.
F>более того, он не чтит даже то, что git ему прямым текстом написал.
Надо признать, у git-а таки отвратительные доки.

Здравствуйте, Нахлобуч, Вы писали:

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

.>>octopus merge — слияние больше чем двух веток сразу.
Н>Этого нет by design.
Почему? В смысле специально запрещено? Или неудачно выбранный формат репозитория?

.>>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием
Н>Не совсем понял, что это.
Когда ты включаешь исходники 3rd party репо как обычный подкаталог в твой репо. Так можно делать и возможность обмена изменениями туда-сюда остаётся.
http://git-scm.com/book/en/Git-Tools-Subtree-Merging

.>>index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов.
Н>Есть hg record, который так же позволят коммитить файлы по частям. Индекса нет, верно.
Тут не просто по частям коммитить, а выбрать точно что ты хочешь закоммитить и закоммитить. Скажем, "добавить пятый кусок файла qer/asdf.txt, добавить каталог abc, исключить подкаталоги abc/de, abc/fe/xy, смотрим получившийся дифф, добавить девятый блок, коммитим". И всё быстро, а не бешенно кликая мышкой по чекбоксам и деревьям, или сочиняя длиннющуу commandline которая пытается всё сделать одним махом. При конфликтах — неконфликтные файлы уже добавлены в индекс, видны конфликты, которые после разрешения можно ещё раз просмотреть, отфильтровав неконфликтные.

.>>reflog — история истории.
Н>Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)
Это не то. reflog показывает историю того, что ты делал — вот ты переключился на бранч, вот ты сделал cherry-pick, вот замержил, вот заребейзил, вот reset, вот stash и т.п.

.>>gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки.
Н>Это не совсем Git.
Однако архитектура git хорошо способствует этой тулзе. На hg такое реализовать было бы сложнее.

.>>log pickaxe — массовый поиск по истории регекспами.
Н>hg revsets в разы мощнее.
Чем? git log, git rev-list тоже не лыком шиты.

.>>git annex — манипуляция массивными файлами.
Н>hg largefiles
Может я что-то не понял, но оно какое-то примитивное, вроде. Например, подразумевает "The central store". Какой же это DVCS? annex поддерживает реальные distributed workflow для больших файлов.

.>>grafts/replace — механизмы для рефакторинга истории.
Н>Всё это есть.
А подробнее? Поменять родителей коммита? Соединить две независимые истории в одну линию?

.>>Простой, но очень мощный и гибкий формат репозитория.
Н>Тут да.
И благодаря этому получается много плюшек и при этом всё очень просто.

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

F>>товарищ не чтит доки.
F>>более того, он не чтит даже то, что git ему прямым текстом написал.
BRA>Надо признать, у git-а таки отвратительные доки.

хз, ProGit обычно хватает.
а в man я лезу только за флажками.

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

F>хз, ProGit обычно хватает.
F>а в man я лезу только за флажками.
Я, в основном. тоже. Но попервах очень трудно пользоваться их доками.
К примеру вот дока по push:
git push
Имеется минимум познаний гита и требуется удалить ремоутный бранч. Найти для этого способ будет непросто, хотя операция должна быть элементарной.

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

F>>товарищ не чтит доки.
F>>более того, он не чтит даже то, что git ему прямым текстом написал.
BRA>Надо признать, у git-а таки отвратительные доки.
Они своеобразные (git help я имею в виду, книги и прочее обычно гораздо дружелюбнее). Они подразумевают понимание происходящего. А новички лезут со своим привычным пониманием, вот я делал "svn add", давай-ка посмотрю ключики "git add" — ой а что это??!
Когда вникаешь в суть, то доки воспринимаются очень хорошо — точно, аккуратно, всё по делу. Просто справочник. Для обучения есть другие материалы.
steep learning curve, как говорится.

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

Pzz>>Нет. В репозитории не делается ничего. Репозиторий только хранит информацию. Все остальное делается локально.

AVK>Но локально у гита весь репозиторий.

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

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

C>>>И в результате получается неудобоваримая история.
GIV>>Где? Я как бы каждый день этим пользуюсь?
C>Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?

Никак не пойму твоих проблем. Что такое нелинейная история?

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

GIV>>>Где? Я как бы каждый день этим пользуюсь?
C>>Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?
GIV>Никак не пойму твоих проблем. Что такое нелинейная история?

Вот такая конструкция:

| commit1
| commit2
|---------------
|              |
| commit3      |
| commit4      commit_a
|              commit_b
|              |
|              |
|---------------
|
somecommit

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

S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.

Ты про какую студию? 2008? Потому что в более свежих давным давно такие окошки искаропки:
Ченджсет:

Дифф:


P.S. AnkhSVN — убогая подделка. VisualSVN намного лучше, хоть и небольших денег стоит.

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

GIV>Далее мерж этой ветки в мастер совершенно механическая операция.

Если бы.

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

IO>Эта интерграция какая-то малоюзабельная. Проще работать с гитом из Тортисы или вообще из консоли

Черепашка для гита безобразна, а из консоли диффы и дерево коммитов сложновато смотреть. Есть же нормальные клиенты — Git Extensions, SourceTree.

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

GIV>>Далее мерж этой ветки в мастер совершенно механическая операция.

AVK>Если бы.

А что за проблемы? reintegrate merge это тупое копирование одной ветки в другую. Вроде как конфликты там возникнуть не могут.

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

GIV>>Далее мерж этой ветки в мастер совершенно механическая операция.

AVK>Если бы.

Когда то давно, да все было грустно но последние несколько лет не помню проблем с этим.

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

BRA>К примеру вот дока по push:
BRA>git push
BRA>Имеется минимум познаний гита и требуется удалить ремоутный бранч. Найти для этого способ будет непросто, хотя операция должна быть элементарной.
Не понял. Вторая страница:

--delete

All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.

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

SJA>А что за проблемы?

Конфликты иногда вылазят, хотя казалось бы.

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

GIV>Когда то давно, да все было грустно но последние несколько лет не помню проблем с этим.

С год назад в текущей версии проблемы точно были. С тех пор SVN почти не пользовался.

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

AVK>Ченджсет:
Так он не заточен под горизонтальный лэйаут, слишком высокий. А при вертикальном в список не влазит полный путь к файлу. Выглядит конечно симпатичнее, но по удобству мне нравится меньше.

AVK>Дифф:
И их я практически всех щупал, года два назад правда. Для быстрого диффа тортойзмерж вне конкуренции — он сразу при открытии схлопывает блоки без различий, не надо скроллить, чтобы увидеть все изменения.

AVK>P.S. AnkhSVN — убогая подделка. VisualSVN намного лучше, хоть и небольших денег стоит.
У меня ровно противоположные впечатления, но VisualSvn я в прошлый раз года три назад видел, могли и исправиться.

А вообще это всё спор про вкус фломастеров, всем разные нравятся

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, Abyx, Вы писали:
A>>проще — согласен, только откуда там больше возможностей?

Н>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?

А ещё в каждое обсуждение git'а обязательно приходит тролль, описывающий насколько mercurial мощней и удобней чем git

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

_>Сразу скажу — хотелось бы обойтись без священных войн.


Думаю, что проблема в том, что вы перешли на Git не потому, что почувствовали внутреннюю необходимость, а потому, что это "модно". И коллега вас, видимо "кинул". Раз он инициатор перехода, то и отвечать, и помогать остальным нужно ему.

Попробую описать несколько сценариев, когда git удобен. Если никогда не было внутренней потребности в сценариях такого типа, то git, bla-bla-bla ... вам не нужен

1. Я делаю изменение, которое естественно дробится на несколько логических частей
— Во время работы делается несколько локальных коммитов
— Пока не сделан push, я царь и бог: эти коммиты можно поменять (и даже удалить, поменять местами слить вместе, раздробить), если локальное тестирование нашло ошибку
— Перед push'ем ещё раз просматриваю коммиты, причёсываю (текст, мелочи) и делаю push

2. Я работаю над несколькими небольшими фичами / небольшими экспериментами / hotfix'ами в одной рабочей копии
— Делаю checkout фиче-ветки. Для небольших фич это почти мгновенно. Поработал, закоммитил. Отложил на время, или за-push'ил, если всё ok
— Переключился на основную ветку (или другую фиче-ветку)

Это 2 сценария, под которые git заточен блестяще. Основные идеи простые, и становятся понятными после прочтения вменяемого tutorial/книги.
Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

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

К>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.

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

К>Здравствуйте, Нахлобуч, Вы писали:

Н>>Здравствуйте, Abyx, Вы писали:
A>>>проще — согласен, только откуда там больше возможностей?

Н>>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?

К>А ещё в каждое обсуждение git'а обязательно приходит тролль, описывающий насколько mercurial мощней и удобней чем git

Mercurial не мощней (это технологии одного порядка мощности), а просто удобнее и проще. У Git много "ручек" и "кнопочек", как у пульта управления космическим кораблём на все случаи жизни, они даются в руки сразу и неосознанно тому, КТО будет ими пользоваться, с какими знаниями и способностями. Без чтения документации и досконального знания особенностей не обойтись. Результат: разрушение центрального репозитория при неосторожном применении ключа команды.

У Mercurial несколько простых запоминающихся команд, а под капотом есть эти самые "кнопочки" и "ручки", которые запрятаны, чтобы их только сознательно могли использовать, а не тыкать всё подряд, как это бывает с новичками. Результат: центральный репозиторий не может быть разрушен случайно.

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

AVK>>Ченджсет:
S>Так он не заточен под горизонтальный лэйаут

Это все принципиально меняет

AVK>>Дифф:
S>И их я практически всех щупал, года два назад правда.

Что значит "практически всех"? Это не "все", это родной студийный дифф.

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

ZEN>У Git много "ручек" и "кнопочек", как у пульта управления космическим кораблём на все случаи жизни

Бэкенд и должен таким быть. А простые и запоминающиеся должен фронтенд обеспечивать.

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

.>Во-вторых, что в общем-то можно сделать страшного? Запушить коммит удаления всего? Так первый же verify build зарежет. Засунуть в код бекдор? Ревьювер пошлёт. Разрешен прямой push? Ну git revert. Разрешен force push? И что, reflog 30 дней живёт. Сумели зачистить reflog? И что, gc вроде 7 дней loose commits держит. Ну ладно, в худшем случае, если все коллеги по проекту тоже сразу внезапно потеряли свои ноуты с клонами, либо в отпусках и не фетчат изменения, бэкапы забыли настроить, то как минимум останется история до последнего релизного тега, т.е. максимум потеряется изменения текущего спринта.

А как тебе сценарий с KDE?

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

N> А как тебе сценарий с KDE?
Над ними там уже поржали, почитай комменты.
В худшем случае, на компах разрабов бы остались бэкапы, можно было бы по частям восстановить. Что, конечно, сложно при таких объёмах данных, но возможно. В случае svn/etc потеря репо из-за проблем fs возможна так же, но восстановление истории было бы нереально, скорее всего.

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

К>>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.
ZEN>Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.

Нет смысла изучать тонкости ни Гита, ни Меркуриала, пока нет необходимости. При устоявшемся workflow обе системы простые, и задача людей, обеспечивающих миграцию, чтобы workflow был всем понятен.

Я пользовался обеими системами (VSS/StarTeam/SVN, потом Mercurial, потом Git), и Mercurial мне не кажется проще. Например, для DVCS удобная работа с ветками одно из главных преимуществ по сравнению с централизованными VCS. Я понимаю, как одной фразой описать, что такое ветка в git, но не понимаю, как это сделать в случае mercurial:
— в git — это указатель на позицию в графе коммитов. Это легко понять и рассказать.
— в mercurial — это что: clone, bookmark (похоже это аналог ветки git), named branch, ...?

В своё время наша компания переезжала на git, и я занимался переносом истории и консультацией коллег. Ожидалось, что первые несколько недель будут достаточно напряженными. На практике этого не случилось. Много вопросов было в первые пару дней, и сейчас возникают с периодичностью 1-2 раза в квартал.

Здравствуйте, dmitry_npi
Я использовал в продакшене и svn, и Git.
Вначале о svn.
есть клиенты для window, есть плагин для студии, есть клиенты и для других OS.
из минусов — постоянная необходимость наличия сервера, использование бранчей не очень удобное, так как опять же их нужно хранить на сервере.
в остальном все было ок.

Теперь немножко о git. Его в продакшене использую только пол года. Из плюсов — удобные бранчи, отвязаность от сервера.
Бранчи на самом деле даже мега-удобные, особенно если фича делается несколько дней. В конце можно взять все комиты, причесать и либо вмержить, лобо перенести в основную ветку как патч.
Gui так же есть — для windows есть TourtiseGit (его использовал только на личных проектах).
В продакшене использую SourceTree (OSX, Win), еще из годных знаю SmartGitHg. Из минусов для меня — пришлось поучиться этим пользоваться, workflow немного другой, но мне нравится больше. Опять же из минусов — на моем проекте работает с одним репозиторием порядка 15 человек, и как следствие иногда не успеваешь забрать все с сервера (pull), смержить со своими изменениями, как уже перед твоим комитом кто-то закомитил. Но такое у меня и на svn встречалось.

и как итог — я бы рекомендовал попробовать git на чем-нибудь простом, и если понравится — то пробовать переходить.
Как говорится лучшее враг хорошего.

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

К>В своё время наша компания переезжала на git, и я занимался переносом истории и консультацией коллег.
та же фигня.

К>Ожидалось, что первые несколько недель будут достаточно напряженными. На практике этого не случилось. Много вопросов было в первые пару дней, и сейчас возникают с периодичностью 1-2 раза в квартал.
О, завидую.
Я был несколько удивлён некоторыми особенностями гита при работе 10 людей одновременно.


Особенно когда касается правки чужих косяков — запушили в центральный репозиторий "не то".
Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
При этом те, кто успел сделать pull, находятся в странном положении — push от них приводит к возврату "косяка" — у них develop указывает уже на ошибочный коммит, и гит это разруливает как новые коммиты в develop, несмотря на то, что на ориджине они уже унесены вбок.

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

D> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.

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

D>> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
.>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.

Всё так, когда история прямая.
А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно.

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

D> .>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.
D> Всё так, когда история прямая.
D> А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно.
Да он же самый. Просто надо -m указывать, до которого родителя откатываться.
А если ошибочных коммитов у вас многовато в команде, то попробуйте Gerrit.

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

D>> А если ошибочными были пара мерждей? Revert, как показала практика, делает иногда странно.
.>Да он же самый. Просто надо -m указывать, до которого родителя откатываться.
.>А если ошибочных коммитов у вас многовато в команде, то попробуйте Gerrit.

Ошибочных коммитов случается примерно один пуш (может быть из трёх коммитов) в два-три месяца, не катастрофа.
Спасибо, попробую.

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

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

D>> Я откатываю ветку develop в центральном репозитории до нормального коммита, пара ошибочных коммитов становится тупиковой ветвью репо-эволюции.
.>В "центральном" репозитории force push должен быть запрещён. Откатывать публичную историю надо с помощью git revert, а не reset/push force.

+1 У нас право разработчики не могут делать "force push" в центральный репозиторий. Обычно используется revert.
Как-то было, переписывали историю из-за коммита с лишними бинарниками. Добавили hook с ограничением на объём коммита

Обычно проблемы у людей возникают при merge кофликте во время rebase — приходилось иногда искать "потерянные" коммиты.
Ещё приходилось помогать с переименованием серии не запушенных коммитов, у нас есть ограничение на формат сообщения, и сервер не пускает коммиты без отсылок к bug tracking system.

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

_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Это очередной топик из разряда "убедите меня".
CVS — первое поколение, SVN — второе поколение, GIT — третье поколение репозиториев.
1. В гите можно делать коммиты без связи с неким общим сервером.
2. Каждый репозиторий это сервер, не так критично, если какие-то из них будут уничтожены.
3. Некоторые люди таскают SVN репозитории на флешке, для других программистов это не лучше, чем если бы они его совсем не вели.
4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
5. Можно долго говорить, но мне за это не заплатят.

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

V>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!

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

V>>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
SJA>Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!

Кстати, автор топика пошёл лёгким путём. А я поставил gitolite на свой сервер в интернете. Причём мне нужно было чтобы это работало совместно с chiliproject и jenkins, которые тоже крутятся на том сервере. И вот этот самый gitolite с его хаками действительно надо уметь готовить. Мне очень долго не удавалось настроить ничего, кроме парольного доступа по логинам юзеров. И только потом я дошёл до идентификации по ключу с парольной фразой для него.

Недостатки всегда можно придумать. Можно ещё преимущества выдавать за недостатки. Плюс удобным обычно кажется не то, что удобнее при параллельном изучении, а то, чем пользуешься несколько лет, а другое только начал изучать. В новых процессах часто срабатывает инерционность мышления. К примеру, тем кто не ведёт репозиторий это удобнее, чем пользоваться репозиторием. Но если научиться, то всё оказывается наоборот.

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

_>>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

V>Это очередной топик из разряда "убедите меня".
V>CVS — первое поколение, SVN — второе поколение, GIT — третье поколение репозиториев.
V>1. В гите можно делать коммиты без связи с неким общим сервером.
Не работать пока лежит сервер святое. Именно SVN кстати очень редко недоступен есть еще 100500 серверов без которых не поработаешь.

V>2. Каждый репозиторий это сервер, не так критично, если какие-то из них будут уничтожены.
Да, тут пробегала ссылка как это все на практике происходит. Делайте бекапы господа.

V>3. Некоторые люди таскают SVN репозитории на флешке, для других программистов это не лучше, чем если бы они его совсем не вели.
Не распарсил.

V>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
SVN намного проще. Причем как как CVSа так и GITа.

V>5. Можно долго говорить, но мне за это не заплатят.
Черт, и мне тоже.

V>CVS — первое поколение, SVN — второе поколение, GIT — третье поколение репозиториев.

ты кого сейчас нулем назвал?
http://netbsd.gw.com/cgi-bin/man-cgi?rcsintro+1+NetBSD-current

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

V>>>4. У SVN нет ни одного преимущества перед GIT, это не просто разные репозитории, это репозитории разных поколений.
SJA>>Тут главное умело жонглировать словами. Ах, гит не умеет X? Ну так вам это и не надо!

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

Преимущества и недостатки — они возникают применительно к конкретной ситуации. Для сантехника у git нет никаких преимуществ перед svn-ом и наоборот.

Если нужно работать с картинками (или другими немержащимеся сущностями) то возможность локов в SVN вполне себе будет преимуществом перед GIT-ом.

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

SJA> Преимущества и недостатки — они возникают применительно к конкретной ситуации. Для сантехника у git нет никаких преимуществ перед svn-ом и наоборот.

SJA> Если нужно работать с картинками (или другими немержащимеся сущностями) то возможность локов в SVN вполне себе будет преимуществом перед GIT-ом.
Локи — типичный антипаттерн. Это если проект тривиальный и всего один trunk-бранч. А когда проект усложнится чуток, и появятся release бранчи, поддержка пользователей чуть более старых версий, или feature-бранчи, то без мержей будет не обойтись, а мержи и локи не совместимы принципиально.
Т.е. это "преимущество" с локами лишь позволяет отложить проблему с бинарниками на потом, но не решает её. Хотя если рассчитвыать на то, что проект сдохнет быстрее, чем разрастётся, тогда использование локов может быть оправдано.