Если подключить немного фантазии, то в исходном комментарии можно найти такой посыл: "Голосовать бессмысленно и не нужно, потому что все партии одинаковы". И вот в этом господин @Hector76 не прав. Голосовать нужно. Обязательно. Всегда.
Прошу прощения, что не привожу аргументов, всё-таки Хабр не для политики.
Например так. Решили откатить все недавние изменения, связанные с паролями. Грепом нашли нужные коммиты и откатили только их. Коммит с фиксом не найдётся.
И хорошо ещё, если откатить не получится из-за конфликтов. Хуже - если откатится только часть и никто об этом не узнает.
Там был эпичный абзац про изготовление сосисок, который запал мне в душу:
The process of developing software, similar to the process of making sausage, is a messy messy business; all sorts of stuff happens in the process of developing software. Bugs are inserted into the code, uncovered, patched over. The end result may be a tasty program, but anyone looking at the process of how it was created (through inspection of the commits) may end up with a sour taste in their mouth. If you hide the sausage making, you can create a beautiful looking history where each step looks as delicious as the end-product.
В целом, мне эти ценности близки, поэтому и я сам стараюсь по-возможности придерживаться подхода "часто комитить — причёсывать — публиковать".
А как быть, если токен выдаёт некий SSO-сервис и с ним клиенту нужно ходить на разные сервисы, расположенные на разных доменах? Например, те же микросервисы могут не иметь единой точки входа. Cookie с токеном на сторонние домены просто так отправить не получится.
Случай конечно немного экзотический, но всё же на облачных платформах иногда встречается.
rebase, особенно интерактивный, — это способ переписать историю: перенести коммиты, убрать, добавить, переименовать. С историей можно сделать всё что угодно.
Зачем переписывать историю — большой вопрос.
Кто-то считает, что история коммитов должна оставаться неизменной, потому что она показывает как развивался проект.
Кто-то (я, например) считает, что в публичный репозиторий должен попадать "причёсанный" код, где каждый коммит приносит какаю-то ценность проекту.
Я делаю по несколько десятков коммитов ежедневно просто, чтобы не потерять прогресс. Большая часть из них — это черновая работа, проверка версий и гипотез. Я считаю, что подобные вещи не приносят ценности проекту, поэтому из множества черновых коммитов в итоге я рибейсом собираю 1-2 осмысленных чистовых. По ним можно адекватно проследить историю развития проекта, а самое главное — их можно легко откатить.
По-моему, эта проблема характерна для любых приложений в Docker.
Всегда есть версия самого приложения, которая постепенно растёт, и есть версия базового образа, которая может вырасти неожиданно при закрытии какой-то уязвимости. Ситуация станет многократно хуже, если базовых образов несколько А их почти всегда несколько.
Не знаю, есть ли здесь универсальное решение. Мне кажется, для каждого проекта надо решать отдельно, сколько версий приложения держать с актуальными зависимостями и каким образом их обновлять.
Так можно сделать там, где нужен полноценный nginx, хотя может возникнуть вопрос бинарной совместимости модуля и nginx. В данном же случае задача была сделать nginx как можно меньше, поэтому пришлось его пересобрать убрав всё, что мне показалось ненужным.
Про dockerize я просто не знал. Спасибо за наводку!
По умолчанию envsubst заменяет в файле всё, что начинается на $. Чтобы он заменял только реально существующие переменные окружения, ему надо передать их список, который я и получаю с awk.
Использование S3 мне не нравится с точки зрения атомарности релиза и версионирования. Хотя, наверняка, я просто не умею его правильно готовить.
Если подключить немного фантазии, то в исходном комментарии можно найти такой посыл: "Голосовать бессмысленно и не нужно, потому что все партии одинаковы". И вот в этом господин @Hector76 не прав. Голосовать нужно. Обязательно. Всегда.
Прошу прощения, что не привожу аргументов, всё-таки Хабр не для политики.
Например так. Решили откатить все недавние изменения, связанные с паролями. Грепом нашли нужные коммиты и откатили только их. Коммит с фиксом не найдётся.
И хорошо ещё, если откатить не получится из-за конфликтов. Хуже - если откатится только часть и никто об этом не узнает.
В поддержку автора комментария хочу привести ссылку на статью, где я сам впервые прочитал про подобный процесс: Commit Often, Perfect Later, Publish Once: Git Best Practices.
Там был эпичный абзац про изготовление сосисок, который запал мне в душу:
В целом, мне эти ценности близки, поэтому и я сам стараюсь по-возможности придерживаться подхода "часто комитить — причёсывать — публиковать".
Правильно я понимаю, что мы наконец-то получим простой способ определять длину строки не в байтах, а в символах?
Я некоторые свои проекты "архивировал" таким кустарным способом:
Для обычных сайтов без навигации через JavaScript работает нормально.
Вы такой способ не рассматривали?
А как быть, если токен выдаёт некий SSO-сервис и с ним клиенту нужно ходить на разные сервисы, расположенные на разных доменах? Например, те же микросервисы могут не иметь единой точки входа. Cookie с токеном на сторонние домены просто так отправить не получится.
Случай конечно немного экзотический, но всё же на облачных платформах иногда встречается.
rebase, особенно интерактивный, — это способ переписать историю: перенести коммиты, убрать, добавить, переименовать. С историей можно сделать всё что угодно.
Зачем переписывать историю — большой вопрос.
Кто-то считает, что история коммитов должна оставаться неизменной, потому что она показывает как развивался проект.
Кто-то (я, например) считает, что в публичный репозиторий должен попадать "причёсанный" код, где каждый коммит приносит какаю-то ценность проекту.
Я делаю по несколько десятков коммитов ежедневно просто, чтобы не потерять прогресс. Большая часть из них — это черновая работа, проверка версий и гипотез. Я считаю, что подобные вещи не приносят ценности проекту, поэтому из множества черновых коммитов в итоге я рибейсом собираю 1-2 осмысленных чистовых. По ним можно адекватно проследить историю развития проекта, а самое главное — их можно легко откатить.
По-моему, эта проблема характерна для любых приложений в Docker.
Всегда есть версия самого приложения, которая постепенно растёт, и есть версия базового образа, которая может вырасти неожиданно при закрытии какой-то уязвимости. Ситуация станет многократно хуже, если базовых образов несколько А их почти всегда несколько.
Не знаю, есть ли здесь универсальное решение. Мне кажется, для каждого проекта надо решать отдельно, сколько версий приложения держать с актуальными зависимостями и каким образом их обновлять.