Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
|
|
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA Речь видимо про то, что чем дольше живёт большая фича в своей ветке, тем чаще надо подмёрживать develop в неё. А в чем проблема время от времени делать "rebase develop"? Лично я так всегда и делаю. Да и в gitlab-flow тоже ведь коммитить напрямую в master это моветон и обычно просто-напросто заблокировано, поэтому в чем разница-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2020, 17:36 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat skyANA Речь видимо про то, что чем дольше живёт большая фича в своей ветке, тем чаще надо подмёрживать develop в неё. А в чем проблема время от времени делать "rebase develop"? Лично я так всегда и делаю. Нет проблемы. Просто по началу многие так не делают. Сидят себе и пилят фичи каждый в своей ветке, а потом начинается веселуха, потому как по началу они ещё и права имеют вливать просто так, без проверки билда и тестов :) Со временем, наевшись, люди приходят к автоматизации, когда на любой пул (мёрж) реквест поднимается среда, где выполняются тесты, и более жёсткому flow. Если что пошло не так, то твои изменения просто не попадут в develop и тем самым ничего не сломают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2020, 18:08 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Ещё была такая проблема больших фич до распила монолита. Две команды пилят месяцами каждая свою фичу, затрагивая при этом одни и теже куски монолита. Одна выпускает свою фичу первой, вторая ловит туеву хучу мёрж конфликтов. Только вот git-flow тут не при чём. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2020, 18:18 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA, Очень часто проблемы мержа возникают из-за того, что в рамках фичи делают какие-то изменения к самой фиче не относящиеся. В принципе, с благими целями - улучшить что-нибудь между делом. Еще тот подарок ревьюеру. Сидишь такой и репу чешешь - WTF, какого лешего для переделок CSS понадобились еще изменения в Startup.cs ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2020, 21:26 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin Если посмотреть реальные отличия gitlab-glow от gitflow, то аналогом ветки develop - фичивая ветка. Так фичивая ветка не является аналогом develop. Alexey Tomin Аналог release - master Аналогично, release не является аналогом master. Alexey Tomin 1. Непонятно как тестировать большую фичу без пересечением с другими фичами. 1. feature toggle 2. большая фича зачастую состоит из реализации разных тасков разными разработчиками и в разных компонентах 3. для этого собственно и существует dev Alexey Tomin 2. Если надо поправить "позапрошлый" релиз то это сделать проще в gitlab-flow. Там всегда релиз имеет свою ветку. релизные ветки есть в gitflow изначально Alexey Tomin В чём плюс gitflow? 1. Когда развернуть серверную часть дорого, то наличие 3х веток и не больше- это намного дешевле. 2. Когда клиентских приложений 5 разных - то это позволяет синхронизировать весь это зоопарк. Собственно эти оба пункта про текущий проект, так что gitflow оправдан. В чём плюс github-flow? Хорошо на старте разработки, пока все постоянно рефакторинг фигачат - с мержем проблем нет. Если поглядеть на различия, то github-flow это тупо сильно покоцанный gitflow. Всё что можно делать в github-flow, можно делать в gitflow, но не наоборот. Стабилизация -- это понятный, осмысленный процесс в разработке серьёзных проектов. Подход, основанный на вылизывания фиче-ветки до идеала просто смешной :) Да, он хорошо ложится на опен-сорс проекты, так как в ОС одна фича = один человек. Но в боевых коммерческих проектах это зачастую абсолютно не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 01:30 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat Alexey Tomin 1. Непонятно как тестировать большую фичу без пересечением с другими фичами. Так фича живет в отдельной ветке, какие пересечения? Речь про то, что когда тестирование идёт с общей ветки, то и ногда сложно понять "чей туфля", т.е. чья бага. Так что первое тестирование лучше делать с "именно" ветки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 06:57 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
hVostt релизные ветки есть в gitflow изначально Ветки release/*, они ведь не для этого. Это pre-release ветки, куда уже никакие фичи не добавляются. Аналог release-ветки gitlab-flow, как я уже выше писал, это support/*. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:05 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin fkthat пропущено... Так фича живет в отдельной ветке, какие пересечения? Речь про то, что когда тестирование идёт с общей ветки, то и ногда сложно понять "чей туфля", т.е. чья бага. Так что первое тестирование лучше делать с "именно" ветки. Дык так и делается. Пушите изменения в свою ветку, создаёте пул (мёрж) реквест в develop. Запускается автоматический пайплайн интеграции: сборка артефакта из вашей ветки, поднятие среды, выкатка туда артефакта, выполнение тестов. Если всё прошло удачно, то мёрж в develop разрешён. Также при желании на ветку можно натравить полный прогон всех существующих тестов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:11 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Также против develop ежедневного выполняются тесты. Они так и называются daily tests. Если вдруг develop "покраснел", то понять "чей туфля" не сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:15 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin Речь про то, что когда тестирование идёт с общей ветки, то и ногда сложно понять "чей туфля", т.е. чья бага. При кошерных настройках CI то, что ломает тесты в ветку develop вообще не попадет. CI он не для того чтобы просто запускать тесты на сервере (свою feature ветку каждый может и у себя локально оттестировать), а чтобы быть уверенным что тесты проходит все вместе собранное до кучи и изменения Васи не ломают изменения Пети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:16 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat skyANA, Очень часто проблемы мержа возникают из-за того, что в рамках фичи делают какие-то изменения к самой фиче не относящиеся. В принципе, с благими целями - улучшить что-нибудь между делом. Еще тот подарок ревьюеру. Сидишь такой и репу чешешь - WTF, какого лешего для переделок CSS понадобились еще изменения в Startup.cs Это не проблемы мёржа, это проблемы ревью. Решаются договорённостью делать отдельные коммиты с комментариями о том, что это вот к фиче не относится, это улучшения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:22 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA Это не проблемы мёржа, это проблемы ревью. Решаются договорённостью делать отдельные коммиты с комментариями о том, что это вот к фиче не относится, это улучшения. Мне все-таки больше по душе, чтобы это отдельной веткой от develop оформлялось, а то разбираться еще со всякими левыми коммитами и комментариями - нафиг, например, мне оно при ревью надо. К тому же мне больше нравится squash до ревью, а не перед merge. Мне на ревью удобней видеть все изменения по таску сразу, а не прокручивать простыню коммитов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 10:45 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat skyANA Это не проблемы мёржа, это проблемы ревью. Решаются договорённостью делать отдельные коммиты с комментариями о том, что это вот к фиче не относится, это улучшения. Мне все-таки больше по душе, чтобы это отдельной веткой от develop оформлялось, а то разбираться еще со всякими левыми коммитами и комментариями - нафиг, например, мне оно при ревью надо. К тому же мне больше нравится squash до ревью, а не перед merge. Мне на ревью удобней видеть все изменения по таску сразу, а не прокручивать простыню коммитов. А откуда простыня-то? Один коммит с изменениями в Startup.cs ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 14:16 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA А откуда простыня-то? Один коммит с изменениями в Startup.cs Я не то имел в виду. Я говорил о том, что мне нравится делать squash еще до ревью, чтобы вместо простыни с кучей небольших изменений видеть все изменения сразу. Но если я делаю squash до ревью, то изменения в Startup.cs будут слиты с остальными в один коммит и весь смысл как-то их метить и комментировать пропадает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 15:00 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat Мне все-таки больше по душе, чтобы это отдельной веткой от develop оформлялось, а то разбираться еще со всякими левыми коммитами и комментариями - нафиг, например, мне оно при ревью надо. К тому же мне больше нравится squash до ревью, а не перед merge. Мне на ревью удобней видеть все изменения по таску сразу, а не прокручивать простыню коммитов. так это.. на ревью не важно сколько коммитов, пулл-реквест это разница между целевой веткой и набором изменений. если в результате ревью будут замечания, устранение замечаний происходит в том же пулл-реквесте доп. коммитами. ты же не на коммит ревью делаешь :) насчёт скваша, это уже способ вливать изменения из реквеста, хочешь скваш, хочешь ребейз (если это возможно), хочешь мердж. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 15:07 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA Также против develop ежедневного выполняются тесты. Они так и называются daily tests. Если вдруг develop "покраснел", то понять "чей туфля" не сложно. если пайплайн сборки разбит на ряд сборок, то можно триггер повесить, любое изменение, влитое в дев, собирает альфу и прогоняет все тесты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 15:10 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat В общем случае такого быть не должно. На каждый таск заводится отдельная фича-ветка и девелопер один в ней работает ни с кем не конфликтуя. Когда работа полностью закончена тогда его ветка мержится в общую develop-ветку. Напрямую писать что-то в develop-ветку нельзя, все изменения только через мерж (или через rebase + fast-forward). Обычно делают вторым способом, чтобы не устраивать хитросплетения из веток и мержей. Опционально, если детальная история изменений не так критична, то делают еще stash ("схлопывают" все коммиты в один большой). Почему у меня возник вопрос желательности блокирования: потому что, если редактируемый файлик - это вордовский файл, то разрешение конфликтов мёржа - это просто ад. Вордовский файл - это конечно условно, для примера. Но у меня куча похожих файлов отчетной системы + есть файлы кубов OLAP. И либо мы имеем большущий геморрой при мёрже, либо нужна возможность блочить файлы (чтобы разрабы знали кто-что правит и смогли договориться). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 15:33 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Критик fkthat В общем случае такого быть не должно. На каждый таск заводится отдельная фича-ветка и девелопер один в ней работает ни с кем не конфликтуя. Когда работа полностью закончена тогда его ветка мержится в общую develop-ветку. Напрямую писать что-то в develop-ветку нельзя, все изменения только через мерж (или через rebase + fast-forward). Обычно делают вторым способом, чтобы не устраивать хитросплетения из веток и мержей. Опционально, если детальная история изменений не так критична, то делают еще stash ("схлопывают" все коммиты в один большой). Почему у меня возник вопрос желательности блокирования: потому что, если редактируемый файлик - это вордовский файл, то разрешение конфликтов мёржа - это просто ад. Вордовский файл - это конечно условно, для примера. Но у меня куча похожих файлов отчетной системы + есть файлы кубов OLAP. И либо мы имеем большущий геморрой при мёрже, либо нужна возможность блочить файлы (чтобы разрабы знали кто-что правит и смогли договориться). Странно, что другим способом они договориться не могут. Типа вот если файл залочен, то я без проблем найду себе другую задачу. А вот если иначе, то обязательно будем толкаться жопами и создавать друг другу геморрой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2020, 16:12 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat Alexey Tomin Речь про то, что когда тестирование идёт с общей ветки, то и ногда сложно понять "чей туфля", т.е. чья бага. При кошерных настройках CI то, что ломает тесты в ветку develop вообще не попадет. CI он не для того чтобы просто запускать тесты на сервере (свою feature ветку каждый может и у себя локально оттестировать), а чтобы быть уверенным что тесты проходит все вместе собранное до кучи и изменения Васи не ломают изменения Пети. Замечательно, когда всё можно выполнить автоматически. А бывают случаи разные - например нужно проверить взаимодействие с внешним API, которое одно и ставит блокировку на количество одновременных запросов- кроме продакшна можно выделить время на тестирование ровно одного экземпляра сервера и в строго определённое время. И тестировать надо долго- API неспешное, а данных много. Второй вариант- некоторые вещи приходится тестировать на копии данных клиента, а данных- очень много, тоже надо стоять в очереди :) Ну и изменения UI требуют ручного просмотра- выявить некрасивость иначе нельзя- значит надо разворачивать нужную версию сервера, брать JSник нужный и смотреть всё. fkthat Мне все-таки больше по душе, чтобы это отдельной веткой от develop оформлялось, а то разбираться еще со всякими левыми коммитами и комментариями - нафиг, например, мне оно при ревью надо. К тому же мне больше нравится squash до ревью, а не перед merge. Мне на ревью удобней видеть все изменения по таску сразу, а не прокручивать простыню коммитов. Это когда как. В хорошем ревью коммиты сделаны именно для удобства читателя- сначала добавили сервис с тестами, потом его использование, потом в UI что-то поменяли. А когда в куче - сложно понять. Критик Почему у меня возник вопрос желательности блокирования: потому что, если редактируемый файлик - это вордовский файл, то разрешение конфликтов мёржа - это просто ад. Вордовский файл - это конечно условно, для примера. Но у меня куча похожих файлов отчетной системы + есть файлы кубов OLAP. И либо мы имеем большущий геморрой при мёрже, либо нужна возможность блочить файлы (чтобы разрабы знали кто-что правит и смогли договориться). Да, когда большинство файлов бинарные- то надо блокировать их. Или не работать с такими средствами разработки, которые не способны хранить всё в текстовых файлах. Вот сейчас у нас только файлик лицензионного соглашения (для виндовых/макосевых дистрибутивов) и иконки/картинки всякие в бинарниках- и хорошо, и нет проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2020, 08:13 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin нужно проверить взаимодействие с внешним API Alexey Tomin на копии данных клиента Alexey Tomin изменения UI требуют ручного просмотра Это уже E2E тестирование и оно лежит вне scope-а CI. Alexey Tomin сначала добавили сервис с тестами, потом его использование, потом в UI что-то поменяли Это только в идеальном мире. В реальности чаще всего дорога от создания feature-branch к pull-request напоминает путь броуновской частицы, где все что только можно по 100500 раз переделывается и рефакторится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2020, 09:03 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat Alexey Tomin нужно проверить взаимодействие с внешним API Alexey Tomin на копии данных клиента Alexey Tomin изменения UI требуют ручного просмотра Это уже E2E тестирование и оно лежит вне scope-а CI. Но внутри этой темы. fkthat Alexey Tomin сначала добавили сервис с тестами, потом его использование, потом в UI что-то поменяли Это только в идеальном мире. В реальности чаще всего дорога от создания feature-branch к pull-request напоминает путь броуновской частицы, где все что только можно по 100500 раз переделывается и рефакторится. И что? Перед отправкой не ревью надо всё слить и разбить на логические коммиты. Некоторые так не делают- ну так уровень у всех разных, не всех можно подпускать к разработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2020, 10:31 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Alexey Tomin И что? Перед отправкой не ревью надо всё слить и разбить на логические коммиты. Некоторые так не делают- ну так уровень у всех разных, не всех можно подпускать к разработке. И как ты это собрался делать, интересно? Удалять целиком ветку и по-новой накатывать руками все отдельные "логические коммиты"? Это что-то напоминает историю про то, как дурака научили богу молиться и чем это закончилось :)) И, потом, я уже писал - каждому удобней делать ревью по-своему. Лично мне при ревью feature удобней и интересней видеть просто изменения по этой feature в целом, а не поток мысли её автора за время её разработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2020, 10:59 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
fkthat Alexey Tomin И что? Перед отправкой не ревью надо всё слить и разбить на логические коммиты. Некоторые так не делают- ну так уровень у всех разных, не всех можно подпускать к разработке. И как ты это собрался делать, интересно? Удалять целиком ветку и по-новой накатывать руками все отдельные "логические коммиты"? Это что-то напоминает историю про то, как дурака научили богу молиться и чем это закончилось :)) И, потом, я уже писал - каждому удобней делать ревью по-своему. Лично мне при ревью feature удобней и интересней видеть просто изменения по этой feature в целом, а не поток мысли её автора за время её разработки. Моя твоя не понимать. Пилю я фичу и вижу в куске кода явный косяк и простую возможность для небольшого улучшения. Я не делаю масштабный рефакторинг, а только небольшое улучшение. Тебе прям будет сильно неудобно от такого отдельного коммита? Ты не поймёшь, что это именно улучшение? Даже прочитав комментарии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2020, 11:14 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
skyANA Тебе прям будет сильно неудобно от такого отдельного коммита? Да. skyANA Ты не поймёшь, что это именно улучшение? Да. skyANA Даже прочитав комментарии? Да. Я же выше уже писал - мне больше нравится делать ревью уже отсквошенной фичи. Т.е. это улучшение будет уже смешано с остальными неулучшениями и коммент потеряется. В чем проблема-то переключится на время на develop, оформить улучшение как bugfix/*, вмержить и сделать rebase своей ветки? Лень? Ну так лично мне вообще лень со всеми этими ветками работать - мне легче было бы сразу в master все фигачить, но я же терплю :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2020, 13:01 |
|
||
|
GIT и DEV-TEST-PROD
|
|||
|---|---|---|---|
|
#18+
Мда, а мне вот наоборот неудобно, когда фичу декомпозируют на таски по 2sp, а потом как прилетает мёрж реквест где они все :) Сделал таску - мёрж рекветс, сделал таску - мёрж реквест. И когда в маленьком таком реквесте будет ещё и какое-то мелкое улучшение отдельным коммитом, меня это нисколько не смутит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2020, 14:40 |
|
||
|
|
Start [/forum/topic.php?fid=37&msg=40011774&tid=1555236]: |
0ms |
get settings: |
2ms |
get forum list: |
8ms |
check forum access: |
0ms |
check topic access: |
0ms |
track hit: |
15ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
31ms |
get tp. blocked users: |
0ms |
| others: | 95ms |
| total: | 158ms |
| 0 / 0 |
