axer

Тут пишут, что стоит использовать даже одному. И это так. Но я дополню. Его использование позволяет: 1) вести историю и при необходимости вспомнить, что было закомичено; 2) при работе над текущей задачей всегда можно понят, что внесено в проект в предыдущего коммита; 3) всегда можно откатиться к прошлой версии; 4) бранчами можно вести разработку параллельного/дублирующего функционала.

Я вообще не понимаю, как можно работать без СУВ.

Может ли верстальщик и первый программист иметь 1 версию на вебсервере и пушить изменения оттуда, а второй программист работать с локалхоста.

Мне кажется, у вас смешалось все, люди, кони. Git децентрализован. Как соедините репозитории сами, так они и будут работать. Может у каждого на компе быть свое локальное репо с которым они работают, а изменения пушат на "ценральный" сервер. Может один пушить в локальное репо другого, а уже другой отправлять на "центральный" сервер/третьему участнику в его локальное репо. Главное одно. Все изменения собираются в одну кодовую базу в итоге.

Всё зависит от проекта и области применения.
В общем случае, варианты архитектуры могут выглядить вот так:

[ASP.NET MVC]  <->   [ASP.NET WebAPI]    <->   [WCF SERVER]    <->    [DATABASE]

Данная связка рекомендуется для серьезных, высоконагруженных и кроссплатформенных проектов с серьезными требованиями безопасности. WebAPI (фактически, это будет прокси для WCF SERVER'a) и MVC могут крутиться на одном и том же IIS сервере. WCF SERVER же лучше держать отдельным сервисом либо на той же машине, либо отдельно.

[ASP.NET MVC]  <->   [WCF SERVER]    <->    [DATABASE]

WebAPI слой можно убрать, если сервис больше рассчитан на внутреннее использование, где кроссплатформенность не нужна и у WCF SERVER'а ожидается много разных клиентов.

[ASP.NET MVC]  <->   [ASP.NET WebAPI]   <->    [DATABASE]

Такая архитектура годится для 99% интернет стартапов. Самая простая и быстрая в разработке, при этом не сильно уступающая более сложным вариантам, описанным выше. А с выходом MVC 6 исчезнет необходимость крутить такой сервер на IIS'e и позволит запускать его на Linux.

Скорее всего вам больше подходит последний вариант.