Станислав Макаров

1) все просто, не используйте git для деплоя (git pull на сервере), для этого есть другие штуки, капистрано, капифони и т.д.

Что до разграничения прав - тут тоже все просто, просто сделайте два репозитория, в один имеют право пушить все а в другой - тот который прод или еще как, только вы (или кто-то главный), и сделать его отдельным оридженом. Тогда права будут разграничены полностью и вы сможете принимать решения что идет на сервак а что нет.

2) можно в bitbucket поставить действия на push хуки, что бы например дергать вашу CI-ку, там прогонять тесты (вы же пишите тесты?) и деплоить. Тогда что бы выкатить версию надо будет всего-лишь сделать git push, а дальше магия. Ну и опять же если мы разделили репозитории на отдельыне ориджены, мы так же можем контролировать кто может деплоить а кто нет.

Вопрос философского толка, однако ;) Первое условие уже содержится в самом вопросе - данные в наборе должны быть связаны. Ну, а второе напрямую вытекает из первого и заключается в том, как же именно они связаны. Базой данных можно считать набор данных, связанных в контексте некоторой предметной области, причем связаных так, что это позволяет делать выборки данных, отвечающие на вопросы этой предметной области.

Например, в контексте поиска телефонных номеров...
Городской телефонный справочник - это база данных, т.к. данные в нем связаны таким образом, что позволяют находить номера. Если же мы перекроим его так, что каждому телефонному номеру будет поставлен в соответствие номер страницы, на которой этот номер напечатан, а каждой фамили - сумма отдельных цифр в телефонном номере, этот набор данных перестанет быть базой данных в контексте заявленной области (хотя в нем будут все данные из исходного набора, и даже больше)... зато легко может стать таковой для каких-нибудь гороскопно-нумерологических задач.

Стоит сделать так:
post: id, author, text
tag: id, tag
post_tag: post_id, tag_id

А зачем вам потоки, тем более в количестве нескольких десятков?

для простых операций можно обойтись гуями (из бесплатных: вышеупомянутый SourceTree, GitHub Desktop, SmartGit) или встроенными средствами редактора/IDE.

для сложных, имхо, только консоль.

если вы внимательно посмотрите, то окажется что эти услуги предоставляются не с нуля, а компаниями которые уже имеют построенную cdn-инфраструктуру и стригут на этом купоны.
вопрос из серии: "какой прикол гихабу хостить проекты фо фри" или "какой прикол jetbrains раздавать бесплатные лицензии для студентов и опенсорса" и т.п.

Плохо тем, что:

• тянутся лишние поля (очень редко нужна вся таблица)
  
• будет возможно на доли секунд медленнее работать при большом количестве запросов
  
• менее понятный код (нельзя будет найти, где используется какой-то столбец)
  
• если запрос сложный - может быть дублирование имён
  
• можно получить тяжелоотлавливаемый баг, когда изменилась таблица, но в запросе была * и запрос отработал, а логика отвалилась из-за неправильных данных (или просто неправильно работает). А были бы конкретные столбцы - упало бы ещё на запросе
  

Вот если указано return 0; - то программа закончиться.Я правильно понимаю?

Только если это return в main().

return это команда закончить текущую функцию (и вернуть значение вызыающей функции)

А если ничего не указать?Она будет в памяти висеть или что?

С 1998 года она выполнит return 0 (опять же, справедливо только для main() ) как только достигнет конца функции main().

Т.е. если указываешь 0, то это типа false.

Это EXIT_SUCCESS.

А если указать 1?

Implementation defined. Обычно работает так же как и EXIT_FAILURE.

Фактически это код выхода. Он возвращается в ОС. Если программа была запущена из командной строки этот код выхода можно проверить чтобы узнать как была завершена программа.