<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # 版本控制系統(VCS)如何工作? > 原文: [https://howtodoinjava.com/vcs/how-version-control-system-vcs-works/](https://howtodoinjava.com/vcs/how-version-control-system-vcs-works/) 如果您是開發人員或正在測試,則必須使用源代碼倉庫(也稱為**版本控制系統**)。 您可能使用過 **CVS**,**SVN** 和 **Perforce** 等。在本文中,我將帶您了解版本控制系統的**基礎**,這將有助于我們了解傳統版本控制系統的主要優缺點。 ## 傳統 VCS 的工作原理 傳統的 VCS 具有集中式服務器,該服務器充當源代碼倉庫。 除了存儲代碼外,這些工具還維護每次提交的修訂歷史記錄。 在下圖中,我們有 3 個文件 A,B 和 C。 項目更改以四個方面提交,即初始提交,第二,第三和第四次提交。 ![Version Control System - Delta Changes](https://img.kancloud.cn/40/5e/405e33e6c576d69c88d1a04c2215c091_580x276.png) 當在第二次提交中對文件 A 和 C 進行更改時,僅差異或增量更改將應用??于初始文件并存儲。 類似地,當在第三次提交中對 B 和 C 文件的頂部執行另一次更改時,僅將 B 和 C 的增量更改存儲為提交的一部分。 請注意,在任何給定的時間點,如果我們要獲取整個代碼庫的當前狀態,將無法獲得,因為對于給定的提交,我們只能獲得與上次文件更改相比的增量變化。 承諾。 例如,當我們比較兩個提交時,我們僅獲得具有更改的文件,并且可以看到對文件所做的實際更改,我們將其稱為增量。 您絕對可以要求一個文件的某些先前版本,但是您不能要求整個工作區在幾次提交之前是什么。 如果要查看工作區如何查看給定的提交,則必須采用基本版本和路徑,其中所有提交都已完成,直到達到所需的提交為止。 因此,您將只能獲得最新版本。 或基本修訂。 因此,VCS 僅存儲差異。 ## 傳統 VCS 的優勢 1. 所有源代碼都安全地存儲在中央服務器上的安全位置。 2. 如果由于系統或硬盤崩潰而導致本地計算機上的源代碼丟失,那么從 VCS 中獲取代碼可以還原該源代碼。 3. 可以在 VCS 上進行認證和授權。 4. VCS 負責管理版本控制,并且如果存在任何沖突,將不允許提交。 5. 維護提交日志以獲取開發人員的提交信息。 讓我們也介紹一下這種方法的一些缺點。 ## 傳統 VCS 的缺點 由于 VCS 駐留在服務器上,并且在托管代碼,對文件進行版本控制,維護提交日志信息方面承擔了所有繁重的工作,因此客戶端僅被限制為獲取代碼的最新副本并工作,最后將所做的更改提交給客戶端。 VCS。 客戶端計算機上的代碼僅僅是工作副本,而不是整個倉庫本身。 現在讓我們看看這種方法的主要缺點。 讓我借助示例進行解釋。 1. 假設有 5 個開發人員正在使用 VCS,并且他們都使用功能并將更改提交到倉庫。 不幸的是,VCS 崩潰,并且沒有備份。 我們剩下的是使用最后一次穩定的提交來還原 VCS。 現在,由于修訂歷史記錄和提交日志都保存在 VCS 服務器上,并且開發人員計算機上存在的代碼庫只是普通的工作副本,因此我們無法自信地將 VCS 置于上一個提交狀態。 2. 這是我們遇到的常見情況。 我們執行的幾乎所有操作(如檢查文件差異,提交,合并等)都只能在 VCS 啟動時執行。 由于某些原因,如果 VCS 暫時關閉,例如網絡中斷,服務器維護,則將阻止所有訪問 VCS 的用戶。 即使簡單的操作(如將文件與以前的版本進行比較)也無法完成。 3. 這種集中式倉庫的另一個缺點是與分支有關。 當我們在進行項目時,我們有主干或主分支,它們被認為是事實的來源,將被用于與諸如 Jenkins 之類的構建工具集成。 為了進行開發,我們從主干創建一個分支,在該分支上工作,然后在該分支上進行測試,最后將所做的更改合并回創建標記的主干,并最終將其推送進行部署。 請注意,分支是在服務器上創建的。 另外,如果兩個開發人員希望使用某個功能并希望彼此合作而不影響其他人的代碼,那么他們將不得不求助于分支機構,該分支機構又將位于服務器上。 因此,在一段時間內,服務器將充滿許多分支。 4. VCS 的另一個缺點是可伸縮性。 想象一下在一個開源項目中工作,在該項目中成千上萬的開發人員需要工作,并且創建了成千上萬的分支機構。 合并更改和管理分支機構是一場噩夢,而傳統的版本控制系統是無法實現的。 集中版本控制工具在軟件開發中扮演著重要的角色,并將繼續發揮作用,但是當項目發展壯大時,對于高可用性和關鍵項目,這可能不是最佳解決方案,因為還有其他更好的選擇。 了解集中式 VCS 的弊端有助于我們確定促使我們探索其他選項的因素,例如**分布式版本控制系統**,例如 **Git** , **Mercurial** 等 。 **關于作者**: 以上文章由該博客的其中一位讀者 Pradeep Kumar([**@pradeepkumarl**](https://twitter.com/pradeepkumarl))提供。 他是一位擁有 10 多年經驗的軟件開發人員,并且曾使用過各種版本控制工具,例如 SVN,Perforce,ClearCase 和 Git。 他對技術充滿熱情,并熱愛教技術。 您可以在 [**Git – 新手到專家**](http://prashdeep.usefedora.com)上查看他的在線課程之一。 **祝您學習愉快!**
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看