як
"коммит: добавил комментарий. Коммит: добавил IF. Коммит: добавил первую строку для ифа из прошлого коммита"
Нет. Какую решал задачу. Что ты добавил IF видно по diff
Size: a a a
2020 February 07
D
коммитить в пределах 1 бранча можно сколь угодно много, если есть смысл в этом
D
Нет. Какую решал задачу. Что ты добавил IF видно по diff
индусский подход, оплата по коммитам.. Кстати, в особо запущенных случаях бывает и так.
GG
коммитить в пределах 1 бранча можно сколь угодно много, если есть смысл в этом
А потом схлопывать в один говорящий коммит
як
вообще, там уместнее было "бранч", поправил
Тут опять всё к ворфлоу сводится - найти самый похожий среди 3..4 распространённых, изучить его (почитать) и следовать советам
D
А потом схлопывать в один говорящий коммит
или не схлопывать ))
GG
Чтоб не было этих "Wip:", "fix", "fix to fix"
V🦆
И юзать conventionalcommits.org
як
коммитить в пределах 1 бранча можно сколь угодно много, если есть смысл в этом
Зависит от выбранного workflow. Git ради git (щоб було) - это тоже воркфлоу. Плохой
як
И юзать conventionalcommits.org
Братан, дай селезня погонять!
D
То что одна задача/ветка блокирует другую - это недостаток архитектуры/организации(management-а)
часто блокировка это норма, если есть условно "реализовать законченное апи" - могут быть ветки которые используют это апи, но мержить их в мастер недопустимо, пока апи не стабилизировали и вмержили. Вот и блокировка. И у нас бывало что надо именно параллельно - когда у 2 команд разные части кода но 1 задача, банально фронт-бэк, код нужен фронту и по его хотелкам, но апи делает бэк
як
часто блокировка это норма, если есть условно "реализовать законченное апи" - могут быть ветки которые используют это апи, но мержить их в мастер недопустимо, пока апи не стабилизировали и вмержили. Вот и блокировка. И у нас бывало что надо именно параллельно - когда у 2 команд разные части кода но 1 задача, банально фронт-бэк, код нужен фронту и по его хотелкам, но апи делает бэк
Develop или теги. Feature-ветки
як
Братан, дай селезня погонять!
як
"кто что делал" - есть в названии тикет? смотрим статус тикета, можно скриптом, удалять ветки где таска закрыта и прошёл месяц. Нет тасок - есть коммиты - есть авторы, нет - просто удаляем.
Хардкорное, но вполне себе автоматизированное ОБХОДНОЕ решение
як
Alexander
Ну, если в команде консенсуса про воркфлоу нет, то тут коммит в девелоп - не самое страшное. Особо отличившихся можно отлучать от девелопа.
+
як
Я не спрашивал зачем нужны отдельные ветки и чем это лучше. Я это итак прекрасно знаю. Но вы упускаете другой подводный камень. Если веток слишком много и мы не успеваем все ветки замерджить, закрывать и потом и вовсе удалять, то потом возникает такие путаницы, кто что делал и возникает такой клубок из спутавшихся ниток. Поэтому я и говорю, что иногда ветку можно делать обобщённой для ряда коммитов, если фичи делаются для одной и той же проблемы.
Это решается coding conventions - пишите единообразные commit message и потом пользуетесь git-ом из консоли, в т.ч. через конвейеры/pipelines или из скриптов. Самый простейший способ - теги и feature-бранчи. Если у вас тикеты так же плодятся - #тикета-бранчи. Главное чтобы ticket/issue/bug автоматически закрывался как только ветка прошла интеграцию (сбилдилась и не сломала тесты) - со ссылкой на хэш git-а. Т.е. хук запустил pipeline, если результат успешный - скрипт всё сделал сам. Чем конкретно (слиянием, закрытием и т.д.) будет заканчивать дёргаемый коммитом pipeline - зависит от workflow
як
В awesome shell/bash есть в том числе и фрэймворки, НО IMHO не тратьте свое время. Bash-скрипт длиннее трёх строк - это антипаттерн - write-only-language
A
Привет. Посоветуйте плиз, есть корпоративный почтовик SMTP на the Host. Сайт находится на Hezner. Почта отправляемая с Hezner идет через SMTP the Hosta. Он не верифицирован и это не есть гуд.
Задача: нужно чтобы почта проходила через другой почтовый сервис. Какие могут быть варианты?
Задача: нужно чтобы почта проходила через другой почтовый сервис. Какие могут быть варианты?
ВИ
Anton
Привет. Посоветуйте плиз, есть корпоративный почтовик SMTP на the Host. Сайт находится на Hezner. Почта отправляемая с Hezner идет через SMTP the Hosta. Он не верифицирован и это не есть гуд.
Задача: нужно чтобы почта проходила через другой почтовый сервис. Какие могут быть варианты?
Задача: нужно чтобы почта проходила через другой почтовый сервис. Какие могут быть варианты?
отправлять через Amazon SES, отправлять через smtp, который ты можешь верифицировать