Jump to content
    

Популярность систем контроля версий

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

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

Share this post


Link to post
Share on other sites

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

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

git №1

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

git №1

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

5 hours ago, Arlleex said:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Оценка будет жёсткая (любителям 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, т.к. там обычно никакого ветвления (и слияния, которое в случае с нетекствыми файлами очень затруднительно) не требуется, а нужно инкрементально сохранять последовательные изменения проекта.

 

 

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

32 minutes ago, dimka76 said:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...