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

[haker_fox 60]

4 minutes ago, andrew_b said:

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

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

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

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

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

[AlexRayne 7]

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

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

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

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

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

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

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

 

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

[dxp 32]

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

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

+1

[andrew_b 14]

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

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

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

[one_eight_seven 3]

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

 

[kolobok0 0]

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

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

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

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

Изменено 15 августа, 2021 пользователем kolobok0

[kolobok0 0]

19 hours ago, haker_fox said:

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

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

[Tarbal 4]

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 и под виндой ставятся.

[one_eight_seven 3]

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 - более наворочен

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

 

Изменено 16 августа, 2021 пользователем one_eight_seven

[Eddy_Em 1]

8 hours ago, kolobok0 said:

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

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

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

[haker_fox 60]

1 hour ago, Eddy_Em said:

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

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

[Eddy_Em 1]

1 hour ago, haker_fox said:

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

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

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

[one_eight_seven 3]

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.

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

Изменено 16 августа, 2021 пользователем one_eight_seven

[one_eight_seven 3]

29 minutes ago, Eddy_Em said:

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

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

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

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

 

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

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

Изменено 16 августа, 2021 пользователем one_eight_seven

[haker_fox 60]

53 minutes ago, Eddy_Em said:

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

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

40 minutes ago, one_eight_seven said:

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

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