Je recommanderais SVN pour le contrôle de la source. C'est simple, facile à configurer, a un bon client Windows (Tortoise) si c'est ce que vous utilisez, et très facile à utiliser pour les petites équipes de développement. Avoir un "serveur de dev" central que partagent les 2 ou 3 développeurs, qui hébergerait le référentiel SVN. Le développement serait fait et testé sur des machines locales et engagé sur le serveur de dev une fois prêt (de petites fonctionnalités dans la durée d'une journée de travail, idéalement).
Le serveur dev peut également héberger une petite installation de TeamCity (un seul projet serait une version gratuite, je pense) ou une forme de serveur d'intégration continue. Cela peut être facilement configuré pour avoir des builds déclenchés par commit (donc les erreurs de build sont détectées immédiatement), builds et déployements nocturnes (pour des tests d'intégration continus), etc.
Le serveur de dev lui-même peut également héberger l'application web. Puisqu'il n'y a qu'un très petit nombre de personnes qui y accèdent et que la recherche de ressources peut être coordonnée verbalement, il n'est pas nécessaire d'être une machine sérieuse. Maintenant, votre question semble impliquer qu'il ne peut y avoir qu'une seule machine (manque de fonds pour des environnements séparés, se développer dans un environnement, etc.) pour vous tous au total. C'est très bien. Cela peut être hébergé sur la machine locale. Mais en séparant les préoccupations entre différents services (serveur de contrôle de source, serveur d'intégration continue, serveur de déploiement cible), il sera plus facile de décharger ces services sur d'autres machines au cours de toute croissance future.
Accordé, cela peut être trop pour vos besoins. C'est très bien. Supprimez TeamCity de l'équation et déployez-la manuellement sur la machine locale et testez-la à partir de là. Pas de problème alors que votre équipe est petite et assez proche pour une bonne communication verbale ouverte. Mais définitivement, ne prenez pas le contrôle de la source hors de l'équation. Ce n'est pas parce que vous êtes tous sur la même machine que vous ne pouvez pas marcher sur les pieds et casser le code. Si rien d'autre, le contrôle de la source fournit un grand journal d'audit des modifications apportées au code.Peut-être que vous voulez annuler quelque chose il y a des mois que vous avez fait, ou voir ce qu'il était avant que de se rappeler comment vous avez fait quelque chose, etc. Même un seul développeur sur une seule machine sur un petit projet doit absolument employer le contrôle source.