[kirill70674 5]

Здравствуйте, коллеги

Есть ли какие-то исследования на тему популярности различных систем контроля версий на территории РФ?

[makc 192]

41 минуту назад, kirill70674 сказал:

Есть ли какие-то исследования на тему популярности различных систем контроля версий на территории РФ?

git №1

PS: обычно выбора нет, т.к. не работник определяет маршруты и средства в организации. Поэтому и смысла в такого рода исследованиях не очень много.

[kirill70674 5]

Ок, а как насчёт ближнего и дальнего зарубежья? Слышал, что в Китае SVN предпочитают...

[makc 192]

10 минут назад, kirill70674 сказал:

Ок, а как насчёт ближнего и дальнего зарубежья? Слышал, что в Китае SVN предпочитают...

Несколько раз наблюдал, что китайцы также работают в git на github/gitlab или чём-то аналогичном. С SVN я сам много работал (начинал с cvs) и git это шаг вперёд. Тем более что репозитории svn вполне неплохо конвертируются в git.

[gridinp 2]

обычно в статистике показывают кол-во репозитариев под той или иной системой, но тут надо понимать, что в svn поддерево файловой системы можно использовать, как полноценный репозитарий, а в git так нельзя, поэтому в git наблюдается сильный рост (на каждый hello world) числа репозитариев.

За границей у кого есть деньги и кроме программистов ещё работают разные художники, конструкторы - довольно часто используют perforce

[MrYuran 16]

В 19.11.2023 в 22:37, makc сказал:

git №1

PS: обычно выбора нет, т.к. не работник определяет маршруты и средства в организации. Поэтому и смысла в такого рода исследованиях не очень много.

Зависит от организации.

Бывают такие, где у каждого разработчика все свое на флешке )

[Arlleex 131]

После SVN привыкнуть и идеологии Git-а вообще плохо выходит. Все там через ж. Обосновывать не буду - всегда бомблю в моменте, когда приходится пользоваться. Лично мне нравится SVN.

[MrYuran 16]

Как я понял, основное отличие в двухступенчатой системе commit/push, и всякое промежуточное г-но на сервере не болтается.

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

Плюс интеграция CI/CD, которая де-факто стала промышленным стандартом (внезапно)

[makc 192]

1 час назад, Arlleex сказал:

После SVN привыкнуть и идеологии Git-а вообще плохо выходит. Все там через ж. Обосновывать не буду - всегда бомблю в моменте, когда приходится пользоваться. Лично мне нравится SVN.

Как человек, перешедший с SVN на Git могу уверенно сказать, что вопрос желания. На первом этапе достаточно делать лишнюю команду (push/pull), а на втором появляется масса очень приятных возможностей. Так что ни разу не жалею о переходе с SVN на Git.

1 час назад, MrYuran сказал:

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

Да, это большой плюс и помощь работе.

[amaora 20]

5 hours ago, Arlleex said:

После SVN привыкнуть и идеологии Git-а вообще плохо выходит. Все там через ж.

У меня после mercurial такое же впечатление о git, хотя не должно было, они похожие.

[kirill70674 5]

12 часов назад, MrYuran сказал:

где у каждого разработчика все свое на флешке

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

11 часов назад, MrYuran сказал:

Плюс интеграция CI/CD

Разве это не плюшки от "концентраторов" (или как их) типа GitHub/GitLab? Для SVN таких "концентраторов" нет?

[dxp 34]

Раз такой открытый обмен мнениями, то позволю себе.

Оценка будет жёсткая (любителям svn не понравится), но зато правдивая: если сравнивать git vs svn в контексте именно управления версиями, то git является системой управления версиями как таковой, а svn нет. svn, cvs, Perforce и все подобные системы с центральным репозиторием являются скорее системами инкрементального архивирования с функциями менджмента кода (особенно Perforce).

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

git позволяет делать реально атомарные комиты -- т.е. когда в комит входят изменения, касающиеся только чего-то одного. Это очень важная штука: такие комиты можно легко таскать между ветками, их можно отменять, не ломая других фич. Вот эта схема с индексом (stage) именно для этого и предназначена (когда в начале не понимал этого, тоже раздражало, что вместо просто commit надо ещё в add в индекс делать, хорошо, что хоть опция -a там была 🙂) : нередко бывает, что изменения кода в одном файле относятся к разным по смыслу фичам/фиксам, и пихать это в один комит неправильно -- потом его ни отменить (нечасто это надо, но бывает), ни перетащить изменения в другую ветку, где они актуальны уже сейчас (а другие изменения и этой ветки, где комит, пока не нужны, они ждут своего слияния в общую ветку). Так вот, git позволяет добавить в индекс выборочно правки из файла, не трогая другие. И так, накидав в индекс, изменения, связанные по смыслу, из разных файлов, можно получить, закомитив, тот самый атомарный комит. Делается это командой git add -i. Существует вполне удобный GUI инструмент для этого -- git-cola, в ней можно прямо выделять в файле нужные строки изменений и добавлять в индекс (или удалять из индекса добавленное по ошибке). 

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

К сожалению, тот же svn не позволяет ничего из вышеперечисленного. Ветвление в нём -- это боль. Поэтому типовая история проекта в svn (cvs или Perforce) --  это ровная цепочка комитов, глядя на которую, не понятно, где когда что делалось -- нужно ползать по всем звеньям цепочки и искать, вчитвываясь в комментарии. И комиты там редко бывают атомарными, обычно комит в svn -- это целый список несвязанных между собой изменений. Да, конечно, и в svn можно стараться делать короткие атомарные комиты, но это технически непросто делать, когда разные по смыслу изменения присутствуют в одном файле.

Есть пара моментов, где системы svn/Perfoce сильнее, чем git:

1. связь с внешними репозиториями;
2. работа с нетекстовыми файлами большого размера.

Оба преимущества проистекают из того, что svn/Perforce основаны на нативной файловой системе: единицы слежения за изменениями -- это файлы, ветки -- это директории. Это позволяет легко цеплять сторонние репозитории как директории (хоть целиком, хоть фрагменты) через svn:externals в svn или mapping в Perforce (этот в этом вопросе вообще очень крут). 

В git же единицей слежения является не файл, а слепок проекта, т.к. совокупность файлов. Директории в нём вообще ничего не значат и учитываются просто в путях файлов, за счёт чего и поддерживается файловая структура с директорими (но закомитить пустую директорию не получится, т.к. для git директория не является ценностной единицей). А submodules в git -- это не самая приятная штука, особенно, когда дело доходит до того, чтобы их удалять/переносить.

Уже не впервые высказываюсь на эту тему. Вот тут подробнее про использование: 

 

Исходя из вышесказанного, можно сделать определённый вывод: если требуется гибкое и удобное версионирование, то git тут вне конкуренции. Это относится в первую очередь к разработке кода. А вот, например, для схематики/PCB отлично подходит svn, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

 

 

 

[MrYuran 16]

Просто оставлю это здесь )

https://git-scm.com/book/ru/v2

Вчера обновил резюме на hh.ru и вдруг обнаружил, что по тегу Git можно пройти тестирование. Так что переходить на Git или нет - пойми, даже вопрос так не стоит )) Это маст хэв скилл

[dimka76 42]

On 11/21/2023 at 7:41 AM, dxp said:

Push после каждого комита тоже делать совершенно не нужно. git -- это система с локальным репозиторием, самый главный реп -- это тот, с которым вы работаете, который лежит у вас рабочем проекте. Push -- это просто способ опубликовать ваши изменения (серверов для публикации может быть сильно больше, чем один 🙂 ). Публиковать надо тогда, когда это необходимо, и не ранее.

А если ваш рабочий комп накроется, а вы Push два месяца не делали ?
Все заново делать ?

[tonyk_av 31]

32 minutes ago, dimka76 said:

А если ваш рабочий комп накроется, а вы Push два месяца не делали ?
Все заново делать ?

Для этого у меня включена синхронизация с Облаком. Удобно, когда на всех рабочих компах последние версии файлов.