Подскажите, чем он лучше? Я смотрю многие вот рекомендуют. Я, например, опасаюсь того, что мне будет не найти под него какой-нибудь готовый рецепт установщика например Oracle XE, или jdk ораклового, или там даже redis'а, который не проприетарен, как те что я выше перечислил. Плюс меня смущает, что там еще один язык, yaml.
По текущим тарифам, смысла переходить по-моему нету. Интересно помониторить изменения тарифов, введение контрактов и изменения качества услуг. А супер преложения «безлимитный интернет», под котторым подразумевается замануха в 50-100 мб в сутки, а потом «ограничение скорости до 64» уже поддостало.
На самом деле, настройка гита на рабочей машине девелопера в команде тоже должна происходить централизованно.
Проблема в том, что, во-первых, каждый будет тратить свое время на настройку одного и тогоже. В команде зачастую 80% настроек одинково (почти все пользуются одним ide и т.п.)
Во-вторых, если централизованно этого не делать, то обязательно что-нибудь забудется и протечет в репозиторий. Человеческий фактор он есть.
Вы не думали как можно настройку гита положить тоже под vcs или сделать командный дистрибутив?
Большой плюс для puppet — существует Pro Puppet книга :) Chef по их документации, вообщем-то как и puppet, сложен для старта, имхо.
А не имеет проблем с установкой — вы что имеете ввижу? Puppet apply или просто puppet все равно надо как-то устанавливать на изначально лысую машину, и по-моему делать это все равно придется через .sh
Отличная вещь, я тоже много думал об именно таком подходе (без chef сервера и чтобы одинаковый сценарий для vargrant/prod).
Жаль, что у вас install.sh заточен под Debian. Вообще, разве opscode не поставляет .sh скрипт для платформо-независимой установки? Я где-то что-то подобное видел, только не могу вспомнить про puppet или про chef это было.
Почему они создаются я понимаю в этом случае, а почему они пустые я не понимаю. При no-ff я хочу видеть этот комит со всеми diff которые составляют дельту между предыдущим комитом:
Они «пустые» в случае отсутствия конфликтов при мерже.
По-моему они пустые всегда при git checkout develop && git merge --no-ff feature_branch && git push.
Ваш вопрос, к сожалению, обычно приводит к холивору «merge vs. rebase»
Я не думаю что rebase тут при чем. Проблема эта локального репозитория, соответственно, можно обойтись наверняка каким-нибудь no-commit при мердже и т.п.
Вообщем, я сам до конца не понимаю механизма получения таких мутных комитов, поэтому я и написал, что я хотел бы почитать про них.
Я бы очень хотел услышать в тонкостях про причины появления и, соответственно, избегания наличия пустых комитов в истории Merge branch 'feature_branch' into develop
Сейчас подорожало, теперь 25 стоит. А это вообще в виме-то самом помогает? А то по тексту шарится конечно прикольно, но не этим единым обычно работаешь, постоянно надо выходить из insert'а в командный режим и т.п.
Проблема в том, что, во-первых, каждый будет тратить свое время на настройку одного и тогоже. В команде зачастую 80% настроек одинково (почти все пользуются одним ide и т.п.)
Во-вторых, если централизованно этого не делать, то обязательно что-нибудь забудется и протечет в репозиторий. Человеческий фактор он есть.
Вы не думали как можно настройку гита положить тоже под vcs или сделать командный дистрибутив?
А не имеет проблем с установкой — вы что имеете ввижу? Puppet apply или просто puppet все равно надо как-то устанавливать на изначально лысую машину, и по-моему делать это все равно придется через .sh
Жаль, что у вас install.sh заточен под Debian. Вообще, разве opscode не поставляет .sh скрипт для платформо-независимой установки? Я где-то что-то подобное видел, только не могу вспомнить про puppet или про chef это было.
A->B->C-->(E) \ / ->D->где (E) = diff(C, D)
По-моему они пустые всегда при
git checkout develop && git merge --no-ff feature_branch && git push.Я не думаю что rebase тут при чем. Проблема эта локального репозитория, соответственно, можно обойтись наверняка каким-нибудь no-commit при мердже и т.п.
Вообщем, я сам до конца не понимаю механизма получения таких мутных комитов, поэтому я и написал, что я хотел бы почитать про них.
Merge branch 'feature_branch' into develop