Еще раз:
Коммит - это снапшот (слепок) всех файлов, добавленных в репозиторий (идентифицируется однозначно хешом).
Репозиторий состоит из последовательности коммитов.
Ветка или тег - всего лишь указатель на конкретный коммит.
Всё, это вся идея.
Таким образом, используя checkout, Вы просто переключаетесь на определенный слепок файлов, идентифицируя его по хешу коммита/ветке/тегу. Если Вы что-то не закоммитили и переходите в другую ветку, изменения потеряются, но git должен об этом предупредить.
Вообще, если уж Вы имеете дело с PHP, для наглядности советую воспользоваться PHPStorm'ом. Там примитивная, но достаточно неплохая поддержка git внутри IDE. Например, файл проекта будут выделен зеленым, если это новый файл, добавленный в проект, но еще не закоммичен, синим, если уже существующий файл изменен, но изменения не закоммичены, просто белым, если файл закоммичен и не изменялся с момента последнего коммита (или игнорируется репозиторием, например через .gitignore) и красным, если файл в папке есть но не добавлен в репозиторий вообще. Таким образом Вы больше не допустите ситуаций, что у Вас что-то не закоммичено или не добавлено в репозиторий перед тем как Вы хотите переключится на другую ветку, так как Вам будет наглядно видно что у Вас есть и в каком состоянии без дополнительных комманд с Вашей стороны. К тому же PHPStorm предлагает дополнительные возможности, например, запомнить сделанные в ветке изменения при переключении в другую, а потом при переключении обратно в первую, он их восстановит. Также PHPStorm имеет очень наглядный, понятный и удобный git log, который не позволит запутаться в коммитах. И самое главное - очень удобный diff для решения конфликтов.
Касательно Вашего момента:
Да, git checkout test1, разработка и мерджить с dev. Если Вы уже вливали test2 в dev, до этого, то ничего страшного в этом нет, это вполне штатная ситуация, git все сольет как надо, а что не сможет, выдаст Вам в виде конфликта, который нужно решить.
@DDanya Серебренной пули нет. Все зависит от ситуации. Если у Вас 3 с половиной странице на сайте, то нет смысла заморачиваться на какой-то крутой мега-роутер. Если все же хочется что-то поудобнее http.HandeFunc(), то можно все сделать так, как Вы и указали. И можно даже комбинировать эти подходы.
Также советую посмотреть как сделано у других, например Gorilla Mux (www.gorillatoolkit.org/pkg/mux) или в том же Martini (https://github.com/go-martini/martini). Это позволит Вам задаст возможное разнообразие подходов и вариантов и даст понять что в Вашем случае подойдет лучше. Как бы там ни было, любой из этих вариантов реализуется достаточно быстро и легко, в чем и вижу прелесть Go.
По умолчанию - нет. Потому что компилируется под ту ОС, где компилите, Вы на Windows получите просто exe-шник и все на этом. Но, по-моему, есть средства для кросс-компиляции. То-есть Вы на Win по идее сможете скомпилить под Linux. Но я не уверен, так как пока не приходилось заниматься таким лично. Добавьте это в вопрос, возможно, более опытные расскажут шире. Ну и главное - почитайте официальную документацию, там должно быть по этому поводу, ну и гугл не оставит в беде, уверен.
То есть в худшем случае прийдется пробежать весь массив, вместо того, чтобы делать это в каждом случае. Худшие случаи случаются не в подавляющем большинстве ситуаций.
Тем, что если LIMIT выпадет 93423, то ждать Вы будете ещё дольше, нежели в моём варианте, пока MySQL пролистает все предыдущие 93422 записи и выберет Вашу единственную.
А вот у @tyzhnenko всё выполнится быстро, ибо опирается он на условие по индексному полю.
@nazarpc хорошо, когда такая функция лежит в каком-нибудь utils.php и не нужно каждый раз заново писать лямбду, так как задача достаточно типовая.
Все зависит от ситуации.
Часто функция с такой логикой встречается в стандартных библиотеках языков. Отсюда и стандартное для неё название - zip.
Да и ещё много зависит от требований. У меня, как видите, могут ключи немного в другом порядке пойти. Если надо сохранять порядок, функцию надо допилить, если нет - это лишний оверхед и вполне себе так идет.
По сути - ничем. Это одно и то же. Просто websockets - это обвязка в стиле http поверх tcp сокетов для того, чтобы пользователь через браузер мог выполнять полнодуплексную связь с сервером. Flash - не браузер, и у него таких ограничений нет.
Если планируется html5 версия приложения, то тогда лучше выбрать websockets, так как приложение будет крутиться средствами браузера, а браузер не умеет просто так взять и сделать любое tcp соединение куда угодно, умеет только по http-подобным протоколам.
2) 0,06 сек. это на самом деле медленно =(
Быстро выполняется, потому что по индексу напрямую данные тянутся. Это мускулу никогда не сложно. Медленно, потому что результат выборки достаточно нехилый и всё это нужно передать по сети.
@Acuna нет...это ж как Вы собрались с нескольких серверов одновременно одним запросом тянуть данные? Мускул так не умеет...тут надо писать нехилую обвязку для работы со всем этим делом. И никогда нет единого бест-подхода/фреймворка для разработки масштабируемой системы, тут надо под каждую задачу своё и умело это комбинировать вместе.
В общем это не сильно сложнее, если в Вы в теме. Просто для масштабирования нужно мыслить немного иначе, чем принято. Когда привычка так мыслить появляется, то становится не сложно закладывать архитектуру проекта так, чтобы в будущем его можно было отмасштабировать без переписывания с нуля.
Не согласен. Горизонтальное масштабирование бывает дешевле вертикального....ведь 4 слабеньких сервера (с 4-8 Гб оперативки) обойдутся дешевле чем один мощный-мощный с 128 Гб оперативки и прочими плюшками, а держать смогут больше и будут более отказоустойчивыми.
1) С текстовыми файлами скорее надо отводить один файл под один ключ, а не под юзера. Ведь желательно, чтобы было меньше блокировок, а то пока Вы будете писать значение по одному ключу в файл, кто-то будет пытаться прочесть значение по другому, и ему придется подождать, так как файл заблокирован на запись, а это есть не хорошо. Хорошо будет написать класс-оберточку, и в нем скрыть детали работы с файлами, потому что файлы - это в любом случае на первое время, когда у Вас будет больше одного веб-сервера со скриптами, встанет вопрос сброса кешей, и пробегать все веб-серверы чтобы почистить файлы - явно не вариант, а так - нужно будет всего лишь перепилить класс под мемкеш. Плюс и здесь все неоднозначно...данные, они то разные...есть достаточно иммутабельные, которые не требуют delete, а живут, пока не станут expired, их же можно и в файлах оставить, остальное загнать в memcache/redis.
2) Тысяча ещё норм...но в целом ход мыслей правильный - у этого решения есть свой потолок, как и указывалось раньше. При больших объемах нужно применять другие пути решения.
3) WHERE `user_id` IN (SELECT `id` FROM...) - те же яйца, что и join, только значительно, значительно хуже, потому что мускул будет этот под-запрос выполнять для каждой проверяемой строки, что катастрофически бьет по времени выполнения на больших объемах. Но особенность это конкретно мускула, в оракле/постгресе с этим вроде как лады, не в курсе точно.
Средствами php - что мешает сделать WHERE `id` IN (".implode(',', $ids).")?...или я не понял вопрос.
