|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Как в GIT осуществляется работа по веткам DEV-TEST-PROD? (работа ведется в VS) Как мы это делали в TFS: - Сначала создали DEV-ветку, из нее клонируются TEST, PROD. - В DEV работают разработчики, по завершению разработки они делают merge своих изменений в DEV->TEST - Тестировщики работают TEST-ветке и могут как откатить changeset обратно, так и сделать merge в TEST->PROD - В релизный день содержимое PROD-ветки билдится и накатывается на продуктив 1) В GIT же у меня какой-то локальный репозиторий master + репозиторий master на сервере. Я могу переименовать локальный репозиторий master в DEV, но в скобках там остается origin/master, что это? см картинка 2) Я могу создать локальную ветку, но мне не понятно, как создать серверную ветку TEST, которая потом будет собираться и выкладываться на тестовый сервер и ветку PROD? 3) Как в GIT решаются конфликты? В TFS (в той схеме, что я использовал ранее) только 1 разработчик мог брать объект на редактирование в DEV-ветке и конфликты возникали, только если он делал большую паузу перед отправкой DEV->TEST, и при этом в TEST-ветке уже лежала чья-то более свежая версия кода. А тут как? Может разрабочик как-то увидеть, что его сосед правит "его" объекты, которые ему нужны для данной задачи? Или это выявится только на этапе синхронизации репозиториев? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 12:48 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Вдогонку - чтобы на win-компе выполнять команды git`а что нужно установить? Какие есть удобные GUI-средства? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 12:51 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Критик, Посмотрите в сторону git-flow . Переименование веток нужно запретить. Продуктовые master-ветки должны быть заблокированы для внесения изменений, только через pull-request. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 13:19 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
hVostt, вот так? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 13:53 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Как оно работает
Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 14:06 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
А кто такой Code owner в git? Первый добавивший, или Maintainer, или owner со вкладки "Group members" web-интерфейса? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 14:50 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Критик Какие есть удобные GUI-средства? Не так давно вышел удобный Windows Terminal ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2020, 16:29 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Критик Как в GIT осуществляется работа по веткам DEV-TEST-PROD? (работа ведется в VS) Как мы это делали в TFS: - Сначала создали DEV-ветку, из нее клонируются TEST, PROD. - В DEV работают разработчики, по завершению разработки они делают merge своих изменений в DEV->TEST - Тестировщики работают TEST-ветке и могут как откатить changeset обратно, так и сделать merge в TEST->PROD - В релизный день содержимое PROD-ветки билдится и накатывается на продуктив Вы хотите git-flow. Например описана тут: https://habr.com/ru/post/106912/ Моё мнение- штука не слишком удобная. Лучше использовать gitlab-flow, например вот описание: https://habr.com/ru/company/softmart/blog/316686/ Критик В GIT же у меня какой-то локальный репозиторий master + репозиторий master на сервере. Я могу переименовать локальный репозиторий master в DEV, но в скобках там остается origin/master, что это? см картинка Не стоит. Совсем не стоит. Это запутывает. Вы хотите что-то сделать. Создаётелокальную ветку на основе DEV, пишите туда коммиты, пушите а потом делаете pull request (github) или merge request (gitlab) - суть почти так же. Критик Я могу создать локальную ветку, но мне не понятно, как создать серверную ветку TEST, которая потом будет собираться и выкладываться на тестовый сервер и ветку PROD? Например создать локально, а потом сделать push Критик Как в GIT решаются конфликты? Двое меняют одну строку локально- никак. Двое сделали push веток, создали merge/pull request - никак. Один из request'ов замержили - второй видит, что есть конфликт- правит его. Критик Вдогонку - чтобы на win-компе выполнять команды git`а что нужно установить? https://git-scm.com/download/win Он даже SSH настраивает (хотя в целом с ssh в винде плохо всё). Критик А кто такой Code owner в git? Первый добавивший, или Maintainer, или owner со вкладки "Group members" web-интерфейса? Вообще git сейчас используется не так, как задумывался. Изначально предполагалось, что "главного" сервера нет, есть только некоторый выделенный компьютер, а все обмениваются кодом делая pull-request - предлождение забрать с твоего компьютера код и вмержить его в репозиторий на компьютере "владельца". Но сейчас все используют сервера для хранения информации - https://github.com/ https://gitlab.com/ https://bitbucket.org/ Первый теперь принадлежит Микрософту и поддерживает сборку кода в том числе для windows (и хорошо поддерживает- и java кучи версий есть, и innosetup и msys2). Причём на всех есть бесплатные планы, а есть платные на разных вкус (а можно и локально сервер поставить- у гитлаба бесплатно даже). Без сервера нынче никто не работает, а там настройка прав широкая- кто owner, кто master, и прочее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 07:45 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin Лучше использовать gitlab-flow Пробовали - не понравилось. Git-flow он более, как бы сказать, регламентированный, и, что самое главное, он из коробки поддержиается самим Git (git flow ****). Для гитлаб-флоу все пляски с мержами, удалениями веток, пушами приходится делать руками. С гитфлоу я набирая в консоли: 'git flow feature finish -r -S -D --push' и все , сколько раз мне надо будет в бубен ударить для того же в случае гитлаб-флоу? Впрочем, у гитфлоу есть неудобство когда мы релизим новые версии, но при этом надо подерживать и старые - он лучше рассчитан на просто последовательный выпуск все более новых версий. Хотя в крайних версиях для этого, кажется, уже ввели специальные "support branches" - я, правда, не пробовал, у нас продукты все заказные, поэтому пока что нужды не возникало. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 08:43 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
hVostt Переименование веток нужно запретить. Так на самом деле переименования веток и не существует, если я не ошибаюсь. Хочешь переименовать - создавай новую а старую прибивай. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 08:52 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin Вообще git сейчас используется не так, как задумывался. Изначально предполагалось, что "главного" сервера нет, есть только некоторый выделенный компьютер Ну так гитхаб это и есть этот самый "выделенный компьютер". И, на самом деле, гит задумывался вообще без "выделенного компьютера", на то он и распределенный. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 10:31 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
fkthat Alexey Tomin Лучше использовать gitlab-flow Пробовали - не понравилось. Git-flow он более, как бы сказать, регламентированный, и, что самое главное, он из коробки поддержиается самим Git (git flow ****). Для гитлаб-флоу все пляски с мержами, удалениями веток, пушами приходится делать руками. С гитфлоу я набирая в консоли: 'git flow feature finish -r -S -D --push' и все , сколько раз мне надо будет в бубен ударить для того же в случае гитлаб-флоу? Создать pull/merge-request с галочкой "удалить ветку после мержа" и после ревью нажать кнопочку "merge" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 12:03 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin Создать pull/merge-request с галочкой "удалить ветку после мержа" и после ревью нажать кнопочку "merge" Ну да, без "галочек" и "кнопочек" нынешнему разработчику никуда. Гребанный стыд, даже в убунтушных туториалах уже повсюду "редактор nano" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 12:29 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Если разработчик начинает редактировать код, то он редактирует его в локальном репозитории. А если этот код уже кто-то поменял и отправил 3 новых версии в удаленный репозиторий? Насколько я понимаю, локальные репозитории ведь не обновляются сами? У разработчика будет сообщение об устаревшей версии до момента начала редактирования? Или он об этом узнает лишь постфактум? (когда он попробует сам зафиксировать код в удаленном репозитории и, наверное, получит merge-конфликт). Разработчик по приходу на работу обязательно должен нажать кнопку получения последней версии? Это чтобы свести такие ситуации к минимуму. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 16:30 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Критик, В общем случае такого быть не должно. На каждый таск заводится отдельная фича-ветка и девелопер один в ней работает ни с кем не конфликтуя. Когда работа полностью закончена тогда его ветка мержится в общую develop-ветку. Напрямую писать что-то в develop-ветку нельзя, все изменения только через мерж (или через rebase + fast-forward). Обычно делают вторым способом, чтобы не устраивать хитросплетения из веток и мержей. Опционально, если детальная история изменений не так критична, то делают еще stash ("схлопывают" все коммиты в один большой). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 17:09 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Критик Если разработчик начинает редактировать код, то он редактирует его в локальном репозитории. А если этот код уже кто-то поменял и отправил 3 новых версии в удаленный репозиторий? Насколько я понимаю, локальные репозитории ведь не обновляются сами? Вам надо читать основы git - про pull/push/fetch/merge и прочее. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 17:52 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
fkthat Alexey Tomin Создать pull/merge-request с галочкой "удалить ветку после мержа" и после ревью нажать кнопочку "merge" Ну да, без "галочек" и "кнопочек" нынешнему разработчику никуда. Я ревью смотрю либо в UI gitlab/github, либо в IDEA. Вот настолько к галочкам привык. fkthat Гребанный стыд, даже в убунтушных туториалах уже повсюду "редактор nano" Я вообще mcedit использую ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 17:54 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin Вам надо читать основы git - про pull/push/fetch/merge и прочее. Тем более совершенно бесплатная книжка даже в русском переводе доступна. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 19:36 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin хотя в целом с ssh в винде плохо всё А что там с ssh не так? В десятке и клиент и сервер из коробки. Про сервер не скажу, но клиентом пользуюсь каждый день и все абсолютно ок. Гит, правда, кажется, своего собственного клиента использует, но с ним тоже все ок. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 00:15 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin Я ревью смотрю либо в UI gitlab/github, либо в IDEA. Вот настолько к галочкам привык. Да это я прикалываюсь. Хотя я сам в ГУИ (вижуал студия) только смотрю хистори, когда надо и конфликты резолвью, все остальное как-то исторически привык делать в командной строке. Alexey Tomin Я вообще mcedit использую Не. Тут я непреклонен и категоричен. Только vim Под студию и VS Code стоят вимовские расширения, если что по-мелкому быстро поправить, типа как в ноутпаде для этого стоит виндовая версия консольного, капслок специально переназначен на ескейп :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 01:00 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
fkthat hVostt Переименование веток нужно запретить. Так на самом деле переименования веток и не существует, если я не ошибаюсь. Хочешь переименовать - создавай новую а старую прибивай. Ну я имею в виду вообще такое понятие как факт, как бы оно не выполнялось :) fkthat Пробовали - не понравилось. Git-flow он более, как бы сказать, регламентированный Гит-флоу чёткий, гибкий и кастомизируется под процессы. А вот это стремление всё "упрощать", зачастую приводит на деле к обыкновенной банальной деградации. При чём проявляется везде -- в искусстве, в дизайне, в работе. На примере gitlab-flow, типа есть фичи ветки и мастер. Всё. А чё дальше не пошли? В топку ветки. Только master, только хардкор, lean просто зашкаливающий. Упрощение понимают крайне искажённо. Не понимают, что простые в использовании вещи внутри сложные, а вовсе не наоборот. Чтобы процесс разработки был простым, значит он должен быть достаточно гибким и понятным, а не примитивным на подобие палки с мордой коня вместо сложного мотоцикла. Прям на ржач пробивает глядя на упрощателей всего и вся :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 01:52 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
hVostt На примере gitlab-flow, типа есть фичи ветки и мастер. Всё. А чё дальше не пошли? Справедливости ради, там все же есть релизные ветки. Когда выпускается очередная версия, то для неё делаеься ветка от мастера и туда уже вносятся только фиксы. Но вообще с гитлабфлоу я видел бардак, т.к. в нем нет даже какого-то общепринятого стандарта именования веток - каждый точит, как он хочет. hVostt Прям на ржач пробивает глядя на упрощателей всего и вся :)) Меня приколол такой аргумент в их мануалах, что, дескать, большой недостаток git-flow это то что там основная рабочая ветка это не master, как, типа, все привыкли, а develop. Кто эти "все привыкли", я не знаю. Гитхаб, например, изначально при создании репо назначает веткой по-умолчанию именно develop. И вообще я нелюбитель гитлаба в целом. У них этакий комбайн, в котором, вроде бы все есть, но любое отдельное из этого "все" на порядок хуже существующих альтернатив. Если уж сравнивать "комбайны", то тот же Azure DevOps по удобству и фичам кроет гитлаб как бык овцу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 06:02 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
hVostt На примере gitlab-flow, типа есть фичи ветки и мастер. Всё. А чё дальше не пошли? В топку ветки. Только master, только хардкор, lean просто зашкаливающий. Это github-flow hVostt Упрощение понимают крайне искажённо. Не понимают, что простые в использовании вещи внутри сложные, а вовсе не наоборот. Чтобы процесс разработки был простым, значит он должен быть достаточно гибким и понятным, а не примитивным на подобие палки с мордой коня вместо сложного мотоцикла. Прям на ржач пробивает глядя на упрощателей всего и вся :)) Дело, собственно, не в упрощении. Если посмотреть реальные отличия gitlab-glow от gitflow, то аналогом ветки develop - фичивая ветка. Аналог release - master Аналог master - v1.0 и прочие ветки конкретных версий. Я сейчас вот в основном своём проекте работаю по gitflow, а в "побочных" - gitlab-flow и github-flow, так что сравнить могу. Раньше был на основном, где gitlab-flow. В чём лично мне видится минус gitflow и плюс gitlab-flow? 1. Непонятно как тестировать большую фичу без пересечением с другими фичами. 2. Если надо поправить "позапрошлый" релиз то это сделать проще в gitlab-flow. Там всегда релиз имеет свою ветку. В чём плюс gitflow? 1. Когда развернуть серверную часть дорого, то наличие 3х веток и не больше- это намного дешевле. 2. Когда клиентских приложений 5 разных - то это позволяет синхронизировать весь это зоопарк. Собственно эти оба пункта про текущий проект, так что gitflow оправдан. В чём плюс github-flow? Хорошо на старте разработки, пока все постоянно рефакторинг фигачат - с мержем проблем нет. fkthat Но вообще с гитлабфлоу я видел бардак, т.к. в нем нет даже какого-то общепринятого стандарта именования веток - каждый точит, как он хочет. Уровень бардака определяется квалификацией участников, а не процессом. Попытки заменить квалифицированных разработчиков процессами всегда приводит к провалу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 09:10 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
Alexey Tomin 1. Непонятно как тестировать большую фичу без пересечением с другими фичами. Так фича живет в отдельной ветке, какие пересечения? Alexey Tomin 2. Если надо поправить "позапрошлый" релиз то это сделать проще в gitlab-flow. Там всегда релиз имеет свою ветку. Это да, я об этом ранее тут писал. Но для этого, как я упоминал, уже достаточно давно ввели "support branches" которые полный аналог релизных веток гитлаб-флоу. Alexey Tomin Уровень бардака определяется квалификацией участников, а не процессом. Попытки заменить квалифицированных разработчиков процессами всегда приводит к провалу. Очень сильно сомневаюсь. За свою карьеру насмотрелся уже всевозможных квалифицированных поделий. По мне так даже команда макак, но делающих все по учебникам, гайдам и процессам представляет куда меньшую опасность. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 09:54 |
|
GIT и DEV-TEST-PROD
|
|||
---|---|---|---|
#18+
fkthat Alexey Tomin 1. Непонятно как тестировать большую фичу без пересечением с другими фичами. Так фича живет в отдельной ветке, какие пересечения? Речь видимо про то, что чем дольше живёт большая фича в своей ветке, тем чаще надо подмёрживать develop в неё. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.10.2020, 15:49 |
|
|
Start [/forum/topic.php?fid=37&tid=1555236]: |
0ms |
get settings: |
28ms |
get forum list: |
10ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
183ms |
get topic data: |
70ms |
get forum data: |
3ms |
get page messages: |
863ms |
get tp. blocked users: |
2ms |
others: | 188ms |
total: | 1355ms |
0 / 0 |