[ДЕЙЛ 37]

В последнее время GitHub создал проблемы при регистрации. В связи с этим решил освоить систему контроля версий Mercurial
Проштудировал данное руководство Welcome to TortoiseHg’s documentation! — TortoiseHg 4.7.0 documentation, работать можно. 

На данный момент хочу понять, как настраивать фильтрацию файлов. В руководстве есть описание, но нет примера. Допустим, мне не нужно отслеживать файлы *.o, но как сказать об этом фильтру? Как настроить фильтр для файлов без расширения?

Есть какое-то описание шаблонов https://wiki.mercurial-scm.org/.hgignore , но шаблон  *\.o$ у меня тоже не хочет работать. 

[andrew_b 30]

Какая связь между Гитхабом и использованием гита как такового? Если уж нужен внешний гит-репозиторий, то кроме Гитхаба есть и более другие хостинги.

А Ртуть уже не нужна никому.

 

[amaora 42]

4 hours ago, andrew_b said:

А Ртуть уже не нужна никому.

Почему? Пользуюсь hg везде где могу выбрать чем пользоваться.

5 hours ago, ДЕЙЛ said:

Допустим, мне не нужно отслеживать файлы *.o

syntax: glob
*.o

man hgignore

[ДЕЙЛ 37]

5 hours ago, andrew_b said:

Какая связь между Гитхабом и использованием гита как такового? Если уж нужен внешний гит-репозиторий, то кроме Гитхаба есть и более другие хостинги.

А Ртуть уже не нужна никому.

 

 

Гит встроен в VisualStudio и для нормальной работы нужен аккаунт на гитхабе. С регистрацией возникла проблема. Возможно, есть какой-то способ обойтись без регистрации и обойтись репозиторием на компе, но я решил попробовать с данной системой контроля версий, чтобы не зависеть от настроения забугорных буржуев. До этого успешно работал в Perforce несколько лет. Если с ртутью не получится, то попробую Perforce вспомнить. 

[dxp 218]

12 часов назад, ДЕЙЛ сказал:

В последнее время GitHub создал проблемы при регистрации. В связи с этим решил освоить систему контроля версий Mercurial

Это звучит наподобие: "В последнее время стало проблемно ездить по улице им. Карацупы, поэтому решил пересесть с жигулей на запорожец".

Система управления версиями и хостинг репозиториев -- вещи ортогональные. Гит -- вообще система управления версиями с локальным репозиторием, ему никакие внешние хостинги не нужны. Внешние репозитории для гита нужны только для двух целей:

1. публикация кода;
2. совместная работа -- синхронизация, обмен правками и т.п.

Некоторые считают, что это ещё и бекап, но это от непонимания темы (версионирования) и сути бекапа. Бекап преследует цель сохранить состояние всех файлов и директорий на какой-то момент, там нет ни истории, и возможности управлять этим, оно и не надо. В случае того же гита в репозитории может быть куча веток, которые просто не отправлены на удалённый реп -- потому что не надо, локальные ветки, временные. Если сломается носитель, эти данные пропадут, удалённый реп не поможет. Поэтому версионирование само по себе, а бекап сам по себе. У меня каждую ночь по расписанию вся директория с проектами архивируется и складируется на бекап-сервер, физически находящийся в другом здании, нежели рабочий комп.

Для внешних хостингов, как у уже сказали, есть полно платформ. Тот же  gitlab.com. Гитлаб, кстати, можно самому развернуть. Есть варианты попроще типа gitea. Даже Сбер вон толкает свою платформу GitVerse (хотя там есть вопросы). Т.ч. выбор велик. И жлобская политика гитхаба никак не может быть основанием отказа от такого инструмента, как гит.

7 часов назад, ДЕЙЛ сказал:

До этого успешно работал в Perforce несколько лет. Если с ртутью не получится, то попробую Perforce вспомнить. 

Perforce -- вообще не система управления версиями (как и Subversion). Это скорее система автоматизированного архивирования: сделали инкрементальную фиксацию, написали к ней коммент, на этом практически всё. С ветвлением там большие проблемы, такой техники как фичебранчи в гите, там и близко нет.

[andrew_b 30]

10 hours ago, amaora said:

Пользуюсь hg везде где могу выбрать чем пользоваться.

И сколько вас таких маргиналов?

 

10 hours ago, ДЕЙЛ said:

Гит встроен в VisualStudio и для нормальной работы нужен аккаунт на гитхабе.

Анальное рабство -- оно такое, да. Шаг влево, шаг вправо -- попытка к бегству -- расстрел.

[gridinp 11]

господа любители гита, вы что такие агрессивные?

[AlexRayne 14]

2 часа назад, gridinp сказал:

господа любители гита, вы что такие агрессивные?

Это тебе еще за слово "вопрос" в названии не предъявили

2 часа назад, andrew_b сказал:

И сколько вас таких маргиналов?

+ я

[AlexRayne 14]

16 часов назад, ДЕЙЛ сказал:

В связи с этим решил освоить систему контроля версий Mercurial

для нормальной работы в этом суровом мире конешно сразу ставьте расширение hggit - с git-репами свзываться. 

(Раньше у них работало расширение git - оно позволяло непосредственно на git-репе работать, так удобно было, но забросили его)

 

и сразу включайте расширения:

1) mq - стек патчей. оч удобно. хотя сейчас патчами немодно работать, но может перестраивать локальную историю как угодно. другие инструменты либо сломаны, либо непонятны, либо неудобны. А эта машинка надежная как швейцарские часы.

2) record - у вас появится галочки на комит конкретного изменения в файлах. офигенная вещ, такого я пока не видел нигде (у комерческих может есть)

3) rebase, transplant - сможете переносить ветки на текущий хед, такая удобная перестроялка локальной истории

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

5) sparce - позволит вытакскивать из репа только часть каталогов

6) narrow - похоже на спарс, только в глубину работает - вытаскивает подкаталог.

7) convert - это если надо глобально перестраивать репы, удалять/переименовывать каталоги. Пробовал, вродь работает, но на моей задаче оказалось с багами.

 

И сейчас активно они для совместной интенсивной работы развиввают topic/evolve - альтернатива патчам, агрессиная пестройка истории но у же в удаленном репе. Я так и не научился с ней работать, да и нужды небыло, но их сообщество только им и тащит пул-реквесты. 

 

ЗЫ) Еще в тортиле на самом незаметном месте - в икнках над окном изменений файла, иконкой с "Z" они спрятали самое ходовое расширение Полка (в гите они обозвали это stash) - нажмите на эту кнопочку обязательно. она позволяет произвольно работать с изменениями текущего каталога - перекладывать их между патчами, по файлам/по изменениям. совместно с mq и record - онно позволяет перестраивать историю как угодно, какие угодно правки переносить  в какой надо комит

Edited December 7, 2024 by AlexRayne

[Leopoldius 0]

On 12/7/2024 at 4:44 AM, dxp said:

Perforce -- вообще не система управления версиями (как и Subversion). Это скорее система автоматизированного архивирования: сделали инкрементальную фиксацию, написали к ней коммент, на этом практически всё. С ветвлением там большие проблемы, такой техники как фичебранчи в гите, там и близко нет.

Это конечно сильное заявление, чо уж. Perforce отлично выступает в роли система контроля версий и все у него есть для этого. Называется немного по другому, но те же stream и branches различных типов отлично решают все те же самые задачи.

Работаю с перфорсом уже 6 лет (паралельно с гит) и могу сказать, что единственное отличие — тип системы контроля версий. Централизованное и распределенное. Все остальное — вопрос чтения документации, не более.

 

 

[dxp 218]

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

Работаю с перфорсом уже 6 лет (паралельно с гит) и могу сказать, что единственное отличие — тип системы контроля версий. Централизованное и распределенное. Все остальное — вопрос чтения документации, не более.

Аналогично, пришлось 6 лет терпеть Perforce -- в конторе главный специалист не любил гит (не осилил его), выдавил, пользуясь влиянием на директора. Правда, счас там опять вернулся гит (влияние специалиста ослабло).

 

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

Централизованное и распределенное.

Централизованное и локальное. Не распределённое. Кто считает, что распределённое, не понимает сути. И центральный реп или локальный -- это ключевое отличие, пожалуй, самое главное, определяющее всё остальное.

С локальным репом я могу управлять историей -- исправлять её, делать такой, которая удобна для ретроспективы. Хорошая, удобная история проекта -- это сильное подспорье в работе. И Git позволяет это получить благодаря индексу (stage), merge --no-ff, rebase. Perforce сливает уже на том, что не позволяет (не помогает) делать т.н. "атомарные" комиты, когда все правки комита относятся только к одному функциональному изменению -- логически связаны между собой. При подготовке такого комита как правило приходится брать отдельные правки из разных файлов, не затрагивая другие правки в этих же файлах. Благодаря индексу и  git add -i в Git это достигается штатными средствами. Это средство каждодневной работы, одно из самых востребованных.

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

Ещё одно ключевое отличие perforce/svn от git состоит в том, что в первых единицей слежения является файл, а во втором -- набор правок (т.н. changeset). Perforce следит за историей единичного файла, а регулярные файлы связываются между собой с помощью директорий, которые тоже есть файлы. В Git же единицей слежения является набор изменений. Да, там тоже можно посмотреть правки какого-то файла, но это частность. Главное -- в Git  все правки всех файлов и составляют суть комита, в то время как в Perforce суть самбита -- это перечень файлов, каждый из которых тянет собственную индивидуальную историю. Её, кстати, очень удобно смотреть, двигая бегунок: при этом в окне программа показывает меняющийся код как на ускоренной перемотке. Это прикольно.

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

Perforce отлично выступает в роли система контроля версий и все у него есть для этого.

Perforce отлично выступает как система... менеджмента кода: встроенная система контроля (ограничения) доступа, мощный backend, позволяющий держать огромного размера репозитории -- собственно, это не супердостижение, это получается "из коробки" благодаря "File-system like" организации/реализации. Бесплатная Subversion в принципе не особо уступает -- бакенд попроще, гибкости поменьше, но в целом все плюшки CVS с центральным репозиторием там присутствуют.

Но вот с версионированием в Perforce/SVN так себе. Ветки в виде копий (ссылок на уровне репа) директорий -- тяжёлая, неповоротливая штука. Сам механизм не поощряет к этому. В отличие от Git. В упомянутой конторе ветки использовались только для подготовки релизов, в разработке (фичебранчи) использование веток было запрещено -- наелись гна на слиянии и борьбе с конфликтами. В итоге, флоу был такой: все самбитят в одну рабочую ветку, после каждого сабмита на CI (Jankins) запускается сборка, если кто-то накосячил, эта сборка выявит проблемы.

Но этот приём -- попытка закостылить исходно негодный подход. При правильной организации работы проверочная сборка запускается до вливания правок в общую ветку. Цель: всегда держать общий код в рабочем состоянии, чтобы любой участник проекта мог взять его как отправную точку для работы над своей фичей или фиксом. А если он берёт сорцы, которые ломают сборку, то он сам работать не может.

Правильный подход реализован в Git в виде фичебранчей и merge- (pull-) request'ов. В этом подходе фичи и фиксы в общую ветку попадают только после проверочной сборки, которая делается после git rebase <common-branch> -- эта команда сливает код общей ветки с локальной рабочей, не смешивая цепочки комитов каждой из веток, при этом разрешаются возможные конфликты, запускается сборка, тесты -- всё, что нужно, и только если всё это завершается успешно, код сливается в общую ветку:

git checkout <common-branch>
git merge --no-ff -e <feature-branch>
git branch -d <feature-branch>  # опционально

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

Что касается стримов в Perforce, то с ними тоже не поехало -- оказалось мутно и непонятно. Даже сам тот специалист не осилил их использование. Для себя он делал так: при работе над фичей он делал shelve, чтобы фиксировать какие-то промежуточные состояния работы, чтобы можно было откатиться на предыдущие правки автоматом, не откатывая вручную. Но потом всё это самбитилось, и, разумеется, эти шелвы сливались в единый самбит -- это как аналог git merge squash, когда все комиты ветки сливаются в один. И это совсем не то, что хочется получить (как в примере выше).

По факту, если просто тупо комитить/самбитить в одну ветку, не разделяя ветки, то особой разницы между Perforce/Subversion и Git нет. В этом сценарии Git даже проигрывает на больших репозиториях за счёт более сложной внутренней организации. К сожалению, чуть ли не большинство проектов так и ведётся -- история выглядит просто как линейная цепочка комитов: по сути система управления версиями используется не в качестве таковой, а в качестве системы инкрементального архивирования. В этом сценарии Perforce на высоте.

В заключение хочется отметить тот факт, что Perforce -- весьма древняя и архаичная система -- она появилась в 1995-м году, на заре всей этой темы, и на тот момент это была революционная система. Git появился в 2005-м, при его создании были учтены многие особенности работы при разработке софта и колоссальный опыт использования различных систем, заимствуя от них лучшее и устраняя недостатки, поэтому его сделали таким. Это намного более современная, удобная и продвинутая система именно управления версиями, позволяющая вести версионирование с почти нулевым порогом трудозатрат и сложности. Поэтому не случайно что именно как система управления версиями Git на две головы выше Perforce, который такой по своей сути на сегодняшний день не является (о чём весь текст выше).

 

[Leopoldius 0]

On 12/15/2024 at 5:46 AM, dxp said:

В итоге, флоу был такой: все самбитят в одну рабочую ветку, после каждого сабмита на CI (Jankins) запускается сборка, если кто-то накосячил, эта сборка выявит проблемы.

Так себе решение. У нас вот принуждают создавать ветки под задачи и потом из них делать "Copy Up" в девелопмент, откуда делают релизы под нужного кастомера. Да, получается тяжеловесно, если держать в голове что, каждое такое - срез репозитория считай. Но меня как разработчика это не особо заботит, т.к. это дела DevOPS. Из отличных вещей, которые в гите с натяжкой можно реализовать через механизм патчей - shelved change list. Очень удобно делится чем-то промежуточным с коллегами или сохранить на будущее. Такой себе микс stash + patch. Но сам клиент P4V, если говорить о графической его части, местами очень странный и глючный. Проблема решалась выбором "правильной версии" клиента

 

Еще очень радует, что автоматом решается проблема с отрывом головы и разрушения связей между коммитами (понятно, что в гите тоже можно это решить путем различных колдунств, но риск потерять кусок истории в гите, на мой скромный взгляд гораздо выше). У нас перфорс с Atlassian Bamboo радостно работал и жил — вплоть до автоматической сборки нужной фирмвари и отправки ее на тестовую ферму где прошивало ssd-диск и гоняло тесты. Для код-ревью, отлично сея показал code collaborator. 

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

Резюмируя, что перфорс, что гит — просто инструменты с отличающейся парадигмой внутри. Оба выполняют свои задачи, а также имеют ценителей. Через 6 лет работы, нет разницы в чем работаешь. Но у гита есть безусловный плюс - клиенты бесплатные и сервер. А перфорс — то для больших контор, типа Sk hynix, Samsung, etc.  Для частных лиц и небольших компаний - гит или меркуриал, как мне кажется — гораздо более оправданный выбор.

 

Основной минус и отличие перфорса, на мой взгляд, если упал сервер и реплики его - ничего не работает. А в гите, хотя бы локально, но будут работать все эти штуки для версионирования 😁

 

 

 

On 12/15/2024 at 5:46 AM, dxp said:

Правильный подход реализован в Git в виде фичебранчей и merge- (pull-) request'ов. В этом подходе фичи и фиксы в общую ветку попадают только после проверочной сборки, которая делается после git rebase <common-branch>

Это если не поленились настроить права так, чтобы не давать программистам валить все в development 😀 В противном случае - все будут крошить и ломать не хуже, чем при описанном вами подходе в перфорсе.

[one_eight_seven 7]

1 hour ago, Leopoldius said:

Так себе решение

Лучшее в индустрии

[dxp 218]

2 часа назад, Leopoldius сказал:

Так себе решение.

Ужасное решение. Однажды там так классно сломали, что пару месяцев не могли починить, и все два месяца команде приходилось использовать как базу какие-то старые сабмиты.

2 часа назад, Leopoldius сказал:

Из отличных вещей, которые в гите с натяжкой можно реализовать через механизм патчей - shelved change list. Очень удобно делится чем-то промежуточным с коллегами или сохранить на будущее.

Чем не подходит просто временные ветки использовать? Создал ветку, запушил её. Когда (если) не нужна -- удалил. Ветки в гите -- это ж просто перемещаемые метки, это бесплатно.

 

2 часа назад, Leopoldius сказал:

Это если не поленились настроить права так, чтобы не давать программистам валить все в development 😀 

Это решается элементарной дисциплиной. В нашем случае в общую ветку мог пушить только один человек, остальные метали ему merge request'ы. Он пинал сборку (куда входили и тесты), если был успех, реквест сливался в общую ветку, если облом, то автор реквеста разбирался с ним. Поскольку реквесты выставлялись всеми членами команды только после проверки, такие случае были редки -- как правило, когда было два реквеста одновременно, второй приходилось рибейзить, вот тут могло что-то вылезать, чаще всего конфликты -- это отправлялось автору для устранения. Технически это можно вообще автоматизировать, чтобы эту работу делали скрипты на сервере. Но это работа девопсов, нам на тот момент было необременительно руками пинать сборку на проверку.

2 часа назад, Leopoldius сказал:

Через 6 лет работы, нет разницы в чем работаешь.

Вот тут не согласен. Я хочу видеть историю вот в таком виде:

где (1) -- комиты слияния -- фичи/фиксы, (2) история фичи, можно посмотреть, если нужны подробности, как фича развивалась. При этом каждый комит -- "атомарный", любой из них можно утащить в другую ветку или откатить (git revert), не сломав функциональность других правок (это достигается, выше писал, путём компонования комита из частных правок разных файлов). Может такое Perforce? Ответ мы знаем. Причём, Git это позволяет делать вообще без усилий.

 

[Leopoldius 0]

On 12/15/2024 at 12:13 PM, dxp said:

где (1) -- комиты слияния -- фичи/фиксы, (2) история фичи, можно посмотреть, если нужны подробности, как фича развивалась.

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

 

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

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

 

К слову, в перфорсе есть даже аналог того же git blame, называется timeline, если верно помню.

 

On 12/15/2024 at 12:13 PM, dxp said:

Чем не подходит просто временные ветки использовать? Создал ветку, запушил её. Когда (если) не нужна -- удалил. Ветки в гите -- это ж просто перемещаемые метки, это бесплатно.

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