版本控制和 Git 簡介

熟悉谷歌文檔？ 好吧，如果你是的話，可以肯定地假設你知道小“版本歷史”選項卡，它允許作者和相關人員檢查和跟踪文檔中所做的所有更改。 在任何給定的時間點。 一個方便的工具，不是嗎？

現在想像一下，不是一張充滿段落的工作表，而是充滿數百行代碼的文件。 與單個文檔不同，有大量不同的文件，不斷更新。

在這樣的場景中，有數千行代碼在運行，最終結果，即移動應用程序是企業未來所依賴的，擁有一個能夠記錄所有更改的軟件變得更加重要在代碼文件中製作。

這就是版本控制軟件出現的地方。

為什麼版本控制在軟件開發中很重要

顧名思義，版本控制軟件使移動應用程序開發人員能夠跟踪軟件開發週期的不同版本並對其進行更改。 這種跟踪代碼中發生的所有更改以及撤消更改的選項的能力使得版本控製成為移動應用程序開發公司涉及多個開發人員的流程的重要組成部分。

現在談到版本控制，目前市場上有許多可用的軟件。 讓我們看看其中的一些——

可用的版本控制軟件

儘管在其 GitLab 調查中，分佈式軟件的領導者發現 98% 的用戶使用 Git 開源工具，超過 92% 的開發人員在應用程序開發過程中使用 Git 作為版本控制語言，但仍有一些開發人員可能會考慮使用 Git 替代方案的原因。 其中一些原因可能有所不同 - GitHub 定價結構和 Github 在 iOS 和 Android 上啟動的事實，對 Octocat 的厭惡，或者不是 Git 的版本控制語言的簡單舒適度。

無論您的原因是什麼，這裡都是 Git 用於版本控制的替代方案 -

現在，即使有許多可供版本控制和 Appinventiv 使用的替代方案，我們在其中的許多方面都有第一手經驗，由於客戶要求不同，我們確實偏愛 Git。 讓我來告訴你為什麼。

為什麼 Appinventiv 使用 Git 進行版本控制

1.閃電般的速度

在市場上所有的版本控制軟件中，Git 日誌和提交元素的工作速度是其他任何軟件都無法比擬的。 當你的開發團隊在一個平台上工作時，軟件的速度是絕對必要的。

2.離線工作的能力

當您使用依賴於 Internet 的軟件時，當您在移動中並且與中央存儲庫斷開連接時可能會有風險。 但是，Git 並非如此。 使用 Git，您幾乎可以在本地計算機上完成所有任務——提交、瀏覽項目歷史、創建分支或合併。

3.撤消救濟

Git 帶有一個“撤消”命令，可讓您更正和恢復整個提交。 事實上，它甚至為您提供了通過其 Reflog 選項恢復“已刪除”提交的選項。

4.對於備份

當團隊在 Git 上工作時，團隊在他們機器上的每個克隆都帶有一個可用的備份。 除此之外，幾乎每一個 Git 操作都只會添加數據而不會刪除它。

5.做出有用的提交

當我們的開發團隊提交了一組不相關的更改——從 A 中獲取一些特性，在另一個中修復一些錯誤——其他團隊成員可能很難理解發生了什麼，他們也很難回滾如果導致問題，則 A 的功能。

Git 通過創建細粒度提交來解決這個問題。 通過其“暫存區”概念，即使您只看單行，也可以輕鬆找出下一次提交中將包含哪些更改。

以上就是我們在 Appinventiv 使用 Git 的五個主要原因。 現在我們已經了解了原因，是時候看看如何了。 我們如何將 Git 納入我們的版本控制流程。

現在讓我們開始吧。

使用 Git 時的版本控製過程

存儲庫創建

Git 的目的是管理一組文件，也就是 Project。 為了做到這一點，Git 將所有信息保存在稱為存儲庫的數據結構中。 存儲庫由應用程序的源代碼、資源和數據集組成。 基本上，它具有定義應用程序項目的所有內容。

現在，有兩種方法可以在 Git 上獲取存儲庫。 您可以使用本地目錄並使用命令行將其轉換為 Git 存儲庫，也可以將已上傳的 Git 存儲庫複製到您的存儲庫中。

創建存儲庫時，通常有兩個選項——公共和私有。 公共存儲庫是其他開發人員使用 Git 可以查看的存儲庫，而私有存儲庫是只能由少數人查看的存儲庫。

分枝

存儲庫創建旁邊是分支。 在像 Appinventiv 這樣的公司中，在任何給定的時間點都有超過 15 到 20 名開發人員在開發一個項目，開發人員共享相同的源代碼並進行工作的情況並不少見。 發生的情況是，當一些開發人員忙於解決問題時，其他開發人員可能正在實施某些功能。

在這種情況下，我們需要一個可以輕鬆處理同一代碼庫中不同代碼版本的系統。

這就是 Gitflow 發揮作用的地方。 Gitflow是一個用於系統高效地分支的框架。

在我們繼續討論分支過程如何在 Gitflow 上工作之前，讓我用一個例子來解釋這個概念。

假設您的團隊中有 5 名開發人員，他們正在開發類似 Instagram 的應用程序。 現在，假設 Feed 和 Notifications 等單個應用程序功能被表示為模塊 1、模塊 2 等等。 現在這些不同的模塊是開發分支，經過處理後與父分支或主分支合併。

開發人員添加分支的那一刻，他們創建了一個獨立的開發線，將他們的工作與團隊成員的工作隔離開來。 然後將不同的分支合併到父分支中。

分支是一種允許團隊成員識別他們應該期望的所有更改並且使回溯變得容易的方法。

在我們的項目中，我們通常會保留這些分支——

• 主分支
• 發展分部
• 功能分支
• 發布分支
• 熱修復和錯誤修復

犯罪

開發人員在單個文件中所做的更改稱為提交。 更改或提交將添加到本地存儲庫中，而不是添加到服務器中。 接下來，我們的開發人員會按照編寫提交消息的習慣，在其中發布提交的描述（文件中所做的更改），以便其他開發人員也知道文件中所做的更改的詳細信息。

推

當您在本地 Git 存儲庫中提交時，接下來發生的事情是將更改發送到服務器，這稱為Push 。

當您是唯一一個處理文件的人時，將提交歷史記錄推送到服務器相當容易，但如果有其他開發人員也參與該過程，您必須先拉動更改，然後才能推送您的一組提交給 Git。

接下來，我們將研究在 Pull Change 步驟中做了什麼。

拉取請求

當多個開發人員在處理同一個文件時，會發生一些提交可能會在您推送之前由其他開發人員推送到服務器上。 當這種情況發生時，就會發生衝突（稍後會詳細介紹）。

為了避免在服務器上兩次上傳相同的代碼庫，開發人員首先從存儲庫中拉取更改並確保代碼不同。 現在，通常，當兩個或多個開發人員處理同一個文件並將他們的提交推送到服務器時，“合併”選項就會出現。

接下來我們來談談Merge。

合併

合併是開發人員首先將所有分支相互合併，然後與主分支或父分支合併的步驟。

每次交付輸入推送命令時，他們都會獲得一個合併選項，然後會詢問他們想要合併提交的分支。

現在在Merge階段，Conflict的發生非常普遍。 當您計劃合併的兩個分支在同一文件的同一部分中發生更改時，通常會發生衝突。 這裡發生的是 Git 無法確定應該使用哪個版本。

當這個衝突問題出現時，Git 提供了兩種解決方案——自動和手動。

顧名思義，一個是 Git 自己發現問題的地方，而在後者中，開發人員必須手動完成。 在 Appinventiv，我們專注於手動解決衝突，因為即使是微小的錯誤發生機會也能消除。

當我們使用 Git 對我們的應用程序開發過程進行版本控制時，同時發生的是問題跟踪。

由於我們是敏捷的忠實追隨者，並且相信敏捷用於我們的移動應用程序開發流程，因此我們了解同時處理多個開發流程的重要性。 借助問題跟踪功能，測試人員可以更輕鬆地實時查看在 Git 服務器上編寫和推送的代碼。

我們利用 ZenHub 板來監控每個存儲庫中的工作流程。 該板允許我們跟踪建議更改的優先級，並幫助開發人員實時更新他們在板上的評論。