Sly_tom_cat .

Делить строку на строку - нельзя

Если проект простой, то конечно удобнее из клиентского приложения вызывать SELECT, UPDATE и INSERT.
Но как только проект становится достаточно большим, или накладываются дополнительные ограничения на безопасность, то удобнее вынести часть бизнес-логики на сервер. В данном случае - на хранимые процедуры.
Плюсы следующие:
1. Хранимые процедуры и клиентское приложения могут писать разные люди (команды), с разной подготовкой. Хранимые процедуры - боле опытные, клиентское приложение - более неопытные.
2. Хранимые процедуры могут обеспечить дополнительный уровень безопасности. Часть проверочной логики может быть реализовано на сервере. И клиентское ПО даже изменив или подделав вызовы не получит не принадлежащие им данные. Если вся логика приложения реализована на клиенте, то злоумышленник может переписать запросы и получить не принадлежащие ему данные. Помимо этого от клиентского ПО скрывается структура БД.
3. Хранимые процедуры, как неинтерактивные модули, проще отлаживать и тестировать в автоматическом режиме.
4. Написанные хранимки меньше, чем клиентское ПО, подвержены изменениям в ходе эволюции и активно повторно используются в разных клиентских модулях.

Нет, если редактировались разные файлы, то конфликтов не будет.

Когда вы работаете в ветке, обязательно поддерживайте ее в актуальном состоянии мастера. Т.е. в данном случае после пуша в master (167) переключайтесь на ветку staging (104) и делайте merge мастера в нее. Если даже будут конфликты - разруливаете их в этой отдельной ветке, не трогая master.

мёржить всё и делов. в чем проблема-то?

есть еще git-filter-branch для совсем запущенных случаев.