Сообщение Re[3]: Политика гитования от 12.07.2023 6:51
Изменено 12.07.2023 6:57 Qulac
Re[3]: Политика гитования
Здравствуйте, LaptevVV, Вы писали:
vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?
Логика то в чем: у нас есть в один момент времени несколько версий кода находящихся на разных этапах конвейера разработки. Веток может быть много, под каждый такой этап. Есть только общие моменты:
prod/realise — здесь код который уже работает
main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
dev — здесь происходит слияние резных версий кода, разбор конфликтов.
А все остальное вы можете под себя добавить или убрать лишнее.
vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?
Логика то в чем: у нас есть в один момент времени несколько версий кода находящихся на разных этапах конвейера разработки. Веток может быть много, под каждый такой этап. Есть только общие моменты:
prod/realise — здесь код который уже работает
main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
dev — здесь происходит слияние резных версий кода, разбор конфликтов.
А все остальное вы можете под себя добавить или убрать лишнее.
Re[3]: Политика гитования
Здравствуйте, LaptevVV, Вы писали:
vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?
Логика то в чем: у нас есть в один момент времени несколько версий кода находящихся на разных этапах конвейера разработки. Веток может быть много, под каждый такой этап. Есть только общие моменты:
prod/realise — здесь код который уже работает
main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
функциональные ветки — здесь код в стадии разработки
dev — здесь происходит слияние резных версий кода, разбор конфликтов.
А все остальное вы можете под себя добавить или убрать лишнее.
vsb>>В большинстве проектов есть ветка main, туда все пушат, оно ставится на тестовый сервер. Когда будет решение ставить на рабочий сервер, заводится тег вроде 1.123.0, и этот билд, собственно, ставится. Если нужен хотфикс — делается ветка 1.123.x, туда коммитится что надо и пушится с тегом 1.123.1 и так далее. Если разрабатывается какая-то фича, которую пока ставить не планируется — делается фич-флаг.
LVV>А кто такой процесс установил?
LVV>И когда ?
LVV>Где-то прописано?
LVV>Или новичку на словах объясняется ?
Логика то в чем: у нас есть в один момент времени несколько версий кода находящихся на разных этапах конвейера разработки. Веток может быть много, под каждый такой этап. Есть только общие моменты:
prod/realise — здесь код который уже работает
main/master — здесь код в состоянии "готово", т.е. прошедший полагающиеся этапы проверки
функциональные ветки — здесь код в стадии разработки
dev — здесь происходит слияние резных версий кода, разбор конфликтов.
А все остальное вы можете под себя добавить или убрать лишнее.