我剛編完一個基本的網絡應用程序並將其上傳到我的vps。到目前爲止，我開發了本地家庭服務器上的所有內容。展望未來，我將與2人甚至3人共同開發應用程序。我沒有資金用於物理上獨立的環境。我只想在一個環境中進行開發，在該環境中進行測試並將代碼推廣到生產環境。我甚至沒有看到需要獨立的測試環境。2人團隊的簡單開發/測試/生產環境策略
我會想象他們是像我這樣的數百萬獨奏程序員，這個問題的一般解決方案是什麼？此外，我知道我應該但我不使用任何源代碼版本控制，比如GIT，對於我想要實現的目標是否有必要？
我會推薦SVN的源代碼管理。它非常簡單，易於設置，如果您使用的是Windows客戶端（Tortoise），並且對於小型開發團隊來說非常容易使用。
有一個2或3個開發人員共享的中央「開發服務器」，它將託管SVN存儲庫。開發工作將在本地機器上完成和測試，並在準備就緒時（在一天的工作範圍內的小功能，理想情況下）下載到開發服務器。
開發服務器還可以承載TeamCity的小型安裝（我認爲單個項目將是免費版本）或某種形式的持續集成服務器。這可以很容易地配置爲具有提交觸發構建（因此立即檢測構建錯誤），每晚構建和部署（用於持續集成測試目的）等。
開發服務器本身也可以託管web應用程序。由於只有極少數人訪問它，並且可以口頭協調資源佔用，所以它不需要是嚴肅的機器。
現在，您的問題似乎意味着總共只有一臺機器（缺乏單獨環境的資金，在一個環境中開發等）。沒關係。這可以全部託管在本地機器上。但通過分離不同服務（源代碼管理服務器，持續集成服務器，目標部署服務器）之間的關係，它可以更容易地將這些服務在未來的增長中卸載到其他計算機上。
當然，這可能都是爲你的需要矯枉過正。沒關係。讓TeamCity脫離等式，只需手動部署到本地機器並從那裏進行測試。沒什麼大不了，而你的團隊很小，足夠接近開放的口頭交流。但絕對不要將源控制排除在等式之外。僅僅因爲你們都在同一臺計算機上，並不意味着你不能踩到彼此的腳趾並破壞代碼。如果沒有其他的話，源代碼控制提供了一個偉大的審計日誌對代碼進行的修改。也許你想撤銷你幾個月前做過的事情，或者看看之前有什麼記住你是如何做某事的，等等。即使一個小型項目上的單個機器上的單個開發人員也應該絕對使用源代碼控制。
您應該使用版本控制任何不平凡的項目。
對於一個2人團隊，git仍然適用。一個工作流程就是擁有一個能夠反映產品的「祝福」git回購，並且一旦他測試了他的變更（在他的開發箱中），每個開發人員都會爲受祝福的存儲庫執行git push。
但是，很大程度上取決於您的VPS提供的環境。例如一些較老的CentOS版本沒有git（你將不得不自己維護一個git安裝）。
也許你應該在你的問題中提供更多的上下文？
您不想讓流程細化，否則沒有人會遵循它。把事情簡單化。
我會推薦git進行版本控制。簡單，靈活，它使分支和合並變得非常簡單。
可能的設置： 有主要的回購一切都推到。一旦你感到高興（並且已經測試過）並且你已經準備好將它移動到'tag'這個版本號的存儲庫中並且從prod環境中獲取你需要的標記版本的項目。
這使事情變得簡單，如果你喜歡它可以在一臺服務器上（儘管推薦不同的目錄）。