Jump to content

    

Какой системой контроля версий вы пользуетесь?

Какой системой контроля версий вы пользуетесь?  

43 members have voted

  1. 1. Какой системой контроля версий вы пользуетесь?

    • Git
      32
    • CVS
      0
    • SVN
      15
    • Mercurial
      7
    • Monotone
      0
    • Team foundation server (TFS)
      0
    • Visual Studio Team Services
      0
    • Perforce Helix Core
      0
    • IBM Rational ClearCase
      0
    • Revision Control system (RCS)
      0
    • Visual SourceSafe (VSS)
      1
    • Bazaar
      0


Recommended Posts

haker_fox
4 minutes ago, andrew_b said:

Зачем что-то смотреть на сервере? Есть же gitk.

1. Дело привычки. Пользуюсь уже лет восемь.

2. Помимо самих коммитов, веток, можно смотреть ещё и Issue.

3. Допольнительно наша система пользоволят делать Merge Request с комментариями к коду и голосованием за принятие "реквеста".

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

Share this post


Link to post
Share on other sites

AlexRayne
8 часов назад, haker_fox сказал:

А что значит "достойный"?

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

имеющий инструменты:

для разбора диффов - выборочный комит кусков дифа.

для работы с патчами 

для редактирования истории

 

для гита я видел более менее качественное - smartgit, пока они совсем платные не стали.

Share this post


Link to post
Share on other sites

andrew_b
8 часов назад, haker_fox сказал:

ВозможнО, что gitk всё это тоже может. Но я, на самом деле, редко пользуюсь графическим интерфейсом по отношению к тому, сколькко времени провожу в командной строке.

Я gitk использую только для просмотра дерева коммитов (ну и текущего git diff). Всё остальное делаю в комстроке.

Share this post


Link to post
Share on other sites

2 hours ago, andrew_b said:

Я gitk использую только для просмотра дерева коммитов (ну и текущего git diff). Всё остальное делаю в комстроке.

[alias]
    lg = !"git lg-specific --all"
    lg1 = !"git lg1-specific --all"
    lg2 = !"git lg2-specific --all"
    lg3 = !"git lg3-specific --all"

    lg-specific = log --graph --abbrev-commit --decorate --pretty=format:'%C(bold blue)%h%C(reset) %C(bold green)[%cd]%C(reset)%C(dim white): %an %C(reset)- %s %C(auto)%d%C(reset)' --date=format:%c
    lg1-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(auto)%d%C(reset)'
    lg2-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(auto)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'
    lg3-specific = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset) %C(bold cyan)(committed: %cD)%C(reset) %C(auto)%d%C(reset)%n''          %C(white)%s%C(reset)%n''          %C(dim white)- %an <%ae> %C(reset) %C(dim white)(committer: %cn <%ce>)%C(reset)'

Я себе вот это добавил в .gitconfig, и дерево коммитов тоже смотрю в коммандной строке.

diff тоже смотрю vim'oм:

[alias]
    ...
	d = difftool
      

...
[diff]
	tool = vimdiff

пользоваться ещё проще:

git lg
git d

 

Share this post


Link to post
Share on other sites

kolobok0
On 8/14/2021 at 5:02 PM, one_eight_seven said:

Для CI/CD не нужна никакая навороченность СКВ. Все коммитят в мастер.

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

И если продолжать в русле CI/CD - то по уму надо (в зависимости от таргет целей) изолировано, в отдельных песочницах собирать то, за что собственно и платят денюжку. Только после этого можно говорить о пром. разработке. Всё остальное - баловство.

Edited by kolobok0

Share this post


Link to post
Share on other sites

kolobok0
19 hours ago, haker_fox said:

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

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

Share this post


Link to post
Share on other sites

Tarbal
On 8/14/2021 at 4:11 PM, AlexRayne said:

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

 

Дык gitk и git gui. Они друг друга могут вызывать.

On 8/14/2021 at 10:17 PM, haker_fox said:

А что значит "достойный"? Под винду с дистрибутивом гита что-то ставится графическое, мои некоторые коллеги используют и довольны. Мне же хватает командной строки.  При необходимости что-то посмотреть в графическом виде, я иду на наш сервер гита, на котором крутится gitlab.

gitk и git gui и под виндой ставятся.

Share this post


Link to post
Share on other sites

7 hours ago, kolobok0 said:

коммит в мастер - это плохая практика, от слова совсем. если по уму, а не хейлохты ворд. и Ваше упоминание о "всех" - показывает отсутствие профессионалов на рынке, что собственно беда текущих времён.

Вы устарели. Это лучшая практика из имеющихся (для CI/CD) на сегодня. Вообще, если немного приложить логику, то это очевидно. Если ваша работа не должна попасть в мастер, то она не нужна. Значит, тянуть с решением возможных проблем мерджа не стоит - дальше их будет только больше.

7 hours ago, kolobok0 said:

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

Да, а это кто?

On 8/14/2021 at 3:18 PM, kolobok0 said:

имхо явно флагманы SVN, GIT но git - более наворочен

Дальнейшее словоблудие даже читать после такого не стоит. Чего я и не стал делать.

 

Edited by one_eight_seven

Share this post


Link to post
Share on other sites

Eddy_Em
8 hours ago, kolobok0 said:

коммит в мастер - это плохая практика

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

Ветки нужны лишь в качестве "тренировки": например, при разработке новой версии ПО (как все фичи будут реализованы, а очевидные баги - отлажены, можно сделать мерж). Но так разрабатывают очень-очень жирный софт, вроде тех же либры или firefox. А если в софте всего-то навсего тысяч 150-300 строк, то не имеет смысла вообще никаких веток делать! Наделал изменений - инкрементировал минорный номер версии - сделал коммит; если изменений наделал "почти радикальных" - инкрементировал средний номер версии; а если натворил "глобальную революцию" в коде, так мажорный номер можно инкрементировать.

Share this post


Link to post
Share on other sites

haker_fox
1 hour ago, Eddy_Em said:

Нормальная практика.

А где это критерий? Вот где плохая, а где хорошая практика? Вот, допустим, 1000 строе проекта и не более, то коммитим сразу в мастер (или теперь в main). А 1001 строка, то уже в feature-develop-xxx.

Share this post


Link to post
Share on other sites

Eddy_Em
1 hour ago, haker_fox said:

А где это критерий?

Да просто здравый смысл: если проект разрабатывает толпа, то коммит в main делает только один (после слияния других веток). Если разработчик один, то ему смело можно вообще без веток работать.

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

Share this post


Link to post
Share on other sites

1 hour ago, haker_fox said:

А где это критерий?

Да нет такого критерия - по строкам кода. Коммитами в мастер пишут кое-что посложнее, чем firefox, и наличие бренчей в той же либре или линуксе - это производственная необходимость - их нельзя перевести на ci/cd, потому что нет контроля над разработчиками (да и не только - над всеми contributor'ами там нет контроля). Там, если построить CI/CD, то каждая уникальная снежинка свои хотелки в основной код будет отправлять, а запретить такой снежинке этим заниматься - нелья: нет рычагов влияния. Поэтому и нужна дополнительная модерация, и feature-branch, и системы лейтенантов, и т.п.

CI/CD же, наоборот, перекладывает эту модерацию на менеджмент, который назначает задачи, а разработчики коммитят код, который эти задачи решает. Вместо модерации - проверка на собираемость и прохождение базовых тестов. А перед развёртыванием - автоматическое же прохождение регрессий. Поэтому внутри компании, где есть контроль над разработчиками, CI/CD построить можно, и люди знают, над чем кто работает, да и за метриками следят, ненужные фичи не должны попадать в итоговый код,. Понятно, что необычные люди-снежинки с руками из задницы найдут способ - но это не системная ошибка, а эксцесс. Они так же и в feature-branch найдут способ самовыражения. И, ещё раз, поскольку любой код должен попасть в мастер (как, кстати, и удаление кусков кода - тоже должно попасть в мастер), то какой смысл тянуть feature branch? Да, когда у себя локально работаешь над кучей задач, экспериментируешь - да хоть тремя слоями веток обмазывайся, никто не запретит. Но дальше - обновляешь мастер, мерджишь в него свои изменения, прогоняешь код через локальные тесты (опционально, но крайне полезно, особенно если локально тесты бегут быстрее, чем проходят через конвейер ci/cd), и пушишь в мастер. Т.е. я не призываю работать без веток, я говорю о том, что CI/CD не накладывает ограничений на СКВ, и работать будет одинаково и в GIT, и в HG, и в SVN.

И да, коммит в мастер - это термин сам по себе, в отрыве от гита. В случае конкретно гита это будет "пуш в мастер"

Edited by one_eight_seven

Share this post


Link to post
Share on other sites

29 minutes ago, Eddy_Em said:

Да просто здравый смысл: если проект разрабатывает толпа, то коммит в main делает только один (после слияния других веток). Если разработчик один, то ему смело можно вообще без веток работать.

И что здесь здравого? Это не может быть здравым, пока оно в отрыве от модели разработки и от задачи.

Здравый случай модерации человеком при приёмке работ:

Когда работает толпа, то сваливать это на одного - не получится. (поэтому, и изобрели pull request'ы между форками, когда вся работа ведётся в частном репозитории (условный origin, если говорим про git), а для апстримов - другой, уже публичный, репозиторий (условный upstream). На несколько апстримов назначается интегратор (лейтенант, мейнтейнер - куча ему названий), который мерджит код себе в частный репозиторий, там разбирается с конфликтами, и отправляет уже в свой upstream. Где над всем этим - диктатор, который, в итоге и предоставляет всем продукт. Так, например, разрабатывается ядро линукса. Тут нет CI/CD, и она невозможна.

 

Здравый случай модерации человеком при назначении задач, и автоматической приёмки работ:

Второй случай, когда тоже куча людей работает, но они под контролем большого брата, своей горячо любимой корпорации (например, Netflix), где огромная куча народу пушат прямо в мастер. Тут есть CI/CD.

Edited by one_eight_seven

Share this post


Link to post
Share on other sites

haker_fox
53 minutes ago, Eddy_Em said:

Хотя, если разработчик один, но требуется достаточно глубоко с кодом поработать, имеет смысл сделать отдельную ветку, в ней баловаться

Вот мне такой подход больше нравится. Чтобы в master была актуальная рабочая версия, а не какой-то эксперимент. Ну и необходимо учитывать, что во время работы есть же куча промежуточных коммитов, которые необходимо сохранять. Держать их в локальном репозитарии не стоит. Это и делается в промежуточноую ветку.

40 minutes ago, one_eight_seven said:

И, ещё раз, поскольку любой код должен попасть в мастер

А если ведётся эксперимент с какими-то особенностями оборудования или программного обеспечения? Его тоже пушить в мастер? Я считаю, что в таком случае удобно завести отдельную ветку, в ней играться, а потом принимать решение о мёрдже с мастером. Или едем в командировку эксперементировать с прибором. В командировке с ноутбуком точно следует иметь отбранченную ветку, где и вести все наработки. Это страхует от потери ноутбука, что в командировке легко может происходить, плюс в головном офисе коллеги могут оперативно посмотреть, что происходит с кодом...

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.