Все хранят. Я бы удиивлся, если бы не хранили.
Ясное дело, что для входа используется хешированный пароль, однако вполне логично хранить сильно отдельно все пароли, так как 90+% пользователей используют один и тот же пароль для многих сервисов. Ну так, просто, на всякий случай :)
> Как раз никакой замены на армаду кэбменов не произошло
Да ладно… Автобусы, метро, трамваи, троллейбусы, поезда, наконец.
Не спорю, личных авто много, но в крупных городах их постепенно законодательно вытесняют общественным транспортом.
> Я бы нет. Ибо смартфон, равно как и автомобиль – штука личная. В них могут храниться ваши документы, там мы можете ставить свои обои / кастомизировать салон. Для автомобилей так же уместен ещё и тюнинг.
150 лет назад у всех обеспеченных людей была личная лошадь. С тюнингом, обоями и прочее. Ну и где ваша личная лошадь?
Вы до сих пор используете чужое определение успеха
и далее:
Тони Роббинс говорит
Тим Феррис в своей «4-часовой рабочей неделе» («Four Hour Work Week») пишет
Спросите у Ричарда Брэнсона
Лучше всего сформулировал это писатель Джон Толкиен
А вообще общий стиль письма напоминает речи проповедников из современных протестантских церквей. Ссылки на Библию, примеры "знакомых, которые уверовали" и прочее.
У нас бывали случаи, когда в одной ветке делалось несколько фиксов. В этом случае после code review разработчик просто делал squash не всех в один, а группировал по фичам. В конечном итоге merge одного pull request давал столько коммитов в develop ветке, сколько багфиксов делалось в этой ветке.
Разработчик может забыть, забить, пропустить и в дереве коммитов окажется вот это. И дальше что? А если у нас 100 коммитов по фиче? Никакой разработчик не будет выдумывать уникальные и красивые сообщения для каждого коммита.
не смотрю коммиты в девелопе, смотрю принятые пулл реквесты в него
Вы не смотрите, а кто-то возможно смотрит. Например, я хочу посмотреть, какие таски я задеплоил между двумя тегами. Я просто делаю:
git log 2.11..2.12
И получаю красивый список тасков. А вы получите 100+ коммитов с непонятными описаниями.
Это лишь один из примеров.
тоже не вижу проблемы в 5000 ветках
репа начинает дичайше тормозить
создаю новую ветку от develop, мержу в неё две нужные фичи, выкладываю. UPD: перечитал вопрос, не понял его. Что значит имеем в dev ветке 5 фичей с n коммитами
Вы запилили 5 фич, QA проверили, все ок, зарелизились, а через недельку ваш заказчик говорит: чувак, у меня конверсии упали. Давай, пили мне A/B тест: выложи мне на один сервер 1, 3, 5 фичу, а на второй сервер — 2, 4. Отдельные релизные ветки, да, сработают, но после нахождения причины в них появятся новые коммиты с фиксами, которые нужно мерджить и мы снова получаем бардак и нечитабельную историю.
Всё же коммит должен быть более менее осмысленным набором изменений, который как минимум компилируется и сопровождается осмысленным сообщением.
Ага, именно для этого делается squash и фича заходит в develop одним коммитом с осмысленным и красивым сообщением. Но это не значит, что разработчик не может в feature-branch накоммитить 100 коммитов до этого.
А для чего вам нужна история кроме как для понимания что и почему изменял разработчик?
История мне нужна для того, чтобы понимать, что и как поменялось с принятием фичи в develop. Какие файлы поменялись, сколько всего файлов поменял разработчик на протяжении работы с данной фичей. А видеть 100 коммитов с сообщениями вроде: fixed / update / fix / 1… мне совершенно неинтересно.
Это родовая травма гита. Переезжайте на меркуриал
Пфффф, отличный совет. Также рассмотрю от вас совет переписать проект с PHP на Java, потому что у PHP тоже сплошные родовые травмы, развестись с женой, потому что нынешняя не хочет готовить мне блинчики с икрой, и, как апофигей, предложение переехать в другую страну, потому что в нынешней коррупция высокая.
Почитайте про github flow
Пафосно, но мимо. github flow никак не решает поставленную задачу. Они лишь гарантируют, что master всегда готов к деплою. Молодцы, чо. Но задачка состояла в другом.
Конечно, давно уже. А еще все, даже самая последняя бабушка и Мариночка-Кикисочка-99 используют SSH-туннель или на крайняк VPN в нейтральных водах.
Все хранят. Я бы удиивлся, если бы не хранили.
Ясное дело, что для входа используется хешированный пароль, однако вполне логично хранить сильно отдельно все пароли, так как 90+% пользователей используют один и тот же пароль для многих сервисов. Ну так, просто, на всякий случай :)
Нагуглил вот такое
Сам не пробовал
http://joxi.ru
Да ладно… Автобусы, метро, трамваи, троллейбусы, поезда, наконец.
Не спорю, личных авто много, но в крупных городах их постепенно законодательно вытесняют общественным транспортом.
150 лет назад у всех обеспеченных людей была личная лошадь. С тюнингом, обоями и прочее. Ну и где ваша личная лошадь?
"Поймай меня, если сможешь". Сюжет примерно о том же.
Ха-ха-ха! А еще люди не будут вести войн и убивать друг друга. А политики не будут врать и воровать. Из той же оперы, ага
и далее:
А вообще общий стиль письма напоминает речи проповедников из современных протестантских церквей. Ссылки на Библию, примеры "знакомых, которые уверовали" и прочее.
У нас бывали случаи, когда в одной ветке делалось несколько фиксов. В этом случае после code review разработчик просто делал squash не всех в один, а группировал по фичам. В конечном итоге merge одного pull request давал столько коммитов в develop ветке, сколько багфиксов делалось в этой ветке.
Разработчик может забыть, забить, пропустить и в дереве коммитов окажется вот это. И дальше что? А если у нас 100 коммитов по фиче? Никакой разработчик не будет выдумывать уникальные и красивые сообщения для каждого коммита.
Если вы работаете в ветке только с одной фичей, а не с десятком, то все изменения будут связаны между собой как раз этой самой фичей.
Спасибо. Попробовал оба метода. С очередью реально проще, причем использовал обычную SplQueue
Вы не смотрите, а кто-то возможно смотрит. Например, я хочу посмотреть, какие таски я задеплоил между двумя тегами. Я просто делаю:
git log 2.11..2.12
И получаю красивый список тасков. А вы получите 100+ коммитов с непонятными описаниями.
Это лишь один из примеров.
репа начинает дичайше тормозить
Вы запилили 5 фич, QA проверили, все ок, зарелизились, а через недельку ваш заказчик говорит: чувак, у меня конверсии упали. Давай, пили мне A/B тест: выложи мне на один сервер 1, 3, 5 фичу, а на второй сервер — 2, 4. Отдельные релизные ветки, да, сработают, но после нахождения причины в них появятся новые коммиты с фиксами, которые нужно мерджить и мы снова получаем бардак и нечитабельную историю.
Все заказчики одинаковы :)
https://bitbucket.org/vgryshko/git
Ага, именно для этого делается squash и фича заходит в develop одним коммитом с осмысленным и красивым сообщением. Но это не значит, что разработчик не может в feature-branch накоммитить 100 коммитов до этого.
История мне нужна для того, чтобы понимать, что и как поменялось с принятием фичи в develop. Какие файлы поменялись, сколько всего файлов поменял разработчик на протяжении работы с данной фичей. А видеть 100 коммитов с сообщениями вроде: fixed / update / fix / 1… мне совершенно неинтересно.
Пфффф, отличный совет. Также рассмотрю от вас совет переписать проект с PHP на Java, потому что у PHP тоже сплошные родовые травмы, развестись с женой, потому что нынешняя не хочет готовить мне блинчики с икрой, и, как апофигей, предложение переехать в другую страну, потому что в нынешней коррупция высокая.
Пафосно, но мимо. github flow никак не решает поставленную задачу. Они лишь гарантируют, что master всегда готов к деплою. Молодцы, чо. Но задачка состояла в другом.
Я ж говорю — тестовый случай. Накидал за 5 минут по аналогии со случаями из профессиональной практики..