主持人 > 博客 > 管理 > 持續整合的典型情況

持續整合的典型情況

您是否學習過 Git 命令，但想想像一下持續整合 (CI) 在現實中是如何運作的？ 或者也許您想優化您的日常活動？ 本課程將為您提供使用 GitHub 儲存庫進行持續整合的實用技能。 本課程並非旨在成為您只需點擊即可完成的嚮導；相反，您將執行人們在工作中實際執行的相同操作，並以與他們相同的方式執行。 當您完成所涉及的步驟時，我將解釋該理論。

我們做什麼？

隨著我們的進步，我們將逐漸創建一個典型 CI 步驟的列表，這是記住這個列表的好方法。 換句話說，我們將創建開發人員在進行持續整合時採取的操作列表，進行持續整合。 我們還將使用一組簡單的測試來使我們的 CI 流程更接近真實的流程。

此 GIF 示意性地顯示了您學習課程時存儲庫中的提交。 正如您所看到的，這裡沒有什麼複雜的，只有最必要的。

持續整合的典型情況

您將經歷以下標準 CI 情境：

  • 致力於一項功能；
  • 應用自動化測試以確保品質；
  • 優先任務的落實；
  • 合併分支時的衝突解決（合併衝突）；
  • 生產環境出現錯誤。

你會學到什麼？

您將能夠回答以下問題：

  • 什麼是持續整合（CI）？
  • CI 中使用哪些類型的自動化測試，以及它們觸發哪些操作？
  • 什麼是拉取請求以及何時需要它們？
  • 什麼是測試驅動開發 (TDD)？它與 CI 有何關係？
  • 我應該合併或重新調整更改嗎？
  • 在下一個版本中回滾或修復？

起初我到處翻譯“pull requests”之類的東西，但結果我決定在一些地方用英文返回短語，以減少文本中的瘋狂程度。 我有時會使用“程式設計師surzhik”，就像人們在工作中實際使用它一樣美妙的動詞“commit”。

什麼是持續集成？

持續集成CI，或 CI，是一種技術實踐，其中每個團隊成員每天至少一次將他們的程式碼整合到公共儲存庫中，並且產生的程式碼必須至少沒有錯誤。

對於這個詞有不同意見

爭論的焦點是整合的頻率。 有些人認為，每天僅合併程式碼一次不足以真正持續整合。 舉一個團隊的例子，每個人早上都拿到新程式碼，晚上整合一次。 雖然這是一個合理的反對意見，但人們普遍認為每天一次的定義相當實用、具體，並且適合不同規模的團隊。

另一個反對意見是，C++ 不再是開發中使用的唯一語言，僅僅要求無錯誤彙編作為驗證方式是很弱的。 某些測試集（例如，本地執行的單元測試）也必須成功完成。 目前，社區正在努力將其作為一項要求，並且在未來「建立+單元測試」可能會成為常見的做法（如果還沒有的話）。

持續集成 不同於 持續交付 （持續交付，CD），因為它不需要在每個整合週期後發布候選版本。

我們將在整個課程中使用的步驟列表

  1. 拉取最新的程式碼。 從建立一個分支 master。 開始工作。
  2. 在新分支上建立提交。 本地建置和測試。 經過？ 轉到下一步。 失敗？ 修復錯誤或測試並重試。
  3. 推送到您的遠端儲存庫或遠端分支。
  4. 建立拉取請求。 討論更改，隨著討論的繼續添加更多提交。 使測試在功能分支上通過。
  5. 合併/變基來自 master 的提交。 使測試通過合併結果。
  6. 從功能分支部署到生產。
  7. 如果一段時間內生產環境一切正常，請將變更合併到主版本中。

持續整合的典型情況

️ 準備工作

確保您擁有正確的軟體

要學習本課程，您需要 Node.js的 и Git客戶端.

您可以使用任何 Git 用戶端，但我只會提供命令列命令。

確保您安裝了支援命令列的 Git 用戶端

如果您還沒有支援命令列的 Git 用戶端，您可以找到安裝說明 這裡.

準備儲存庫

您需要建立一個個人副本（fork） 包含課程代碼的範本儲存庫 在 GitHub 上。 我們同意將此稱為個人副本 課程庫.

完畢？ 如果您沒有更改預設設置，您的課程儲存庫很可能被稱為 continuous-integration-team-scenarios-students，它位於您的 GitHub 帳戶中，URL 如下所示 

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

我會簡單地呼叫這個地址 <URL репозитория>.

尖括號如 <тут> 意味著您必須用適當的值替換這樣的表達式。

確保 GitHub 操作 包含在本課程儲存庫中。 如果未啟用，請透過點擊頁面中間的大按鈕來啟用它們，您可以透過點擊 GitHub 介面中的動作來存取該按鈕。

如果未啟用 GitHub Actions，您將無法按照我的指示完成課程。

持續整合的典型情況

您始終可以使用 GitHub 渲染 Markdown 的功能來查看我們在此處編寫的清單的當前狀態

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

關於答案

雖然完成本課程的最佳方法是自己完成，但您可能會遇到一些困難。

如果你覺得不明白該怎麼辦，無法繼續，可以查看帖子 solution，它位於您的啟動儲存庫中。
請不要合併 solution в master 在過程中。 您可以使用此分支來弄清楚要做什麼，或使用 Git 提供給我們的所有功能將您的程式碼與作者的程式碼進行比較。 如果你完全迷失了，你可以完全更換你的分支 master 在樹枝上 solution 然後將您的工作目錄重設為您需要的課程步驟。

僅當您確實需要時才使用它

提交您的程式碼

git add .
git commit -m "Backing up my work"

這些命令

  • 改名 master в master-backup;
  • 改名 solution в master;
  • 結帳到新分行 master 並重寫工作目錄的內容；
  • 從「master」（曾經是「解決方案」）建立一個「解決方案」分支，以防將來需要「解決方案」分支。

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

完成這些步驟後，您可以使用 git log master 找出您需要哪個提交。
您可以將工作目錄重設為為此提交，如下所示： 

git reset --hard <the SHA you need>

如果您對結果感到滿意，在某些時候您將需要將儲存庫版本發佈到遠端儲存庫。 執行此操作時，請不要忘記明確指定遠端分支。 

git push --force origin master

請注意，我們使用 git push --force。 您不太可能經常這樣做，但我們這裡有一個非常具體的場景，其中有一個存儲庫用戶，此外，他還了解自己在做什麼。

開始工作

持續整合的典型情況

讓我們開始編譯 CI 步驟清單。 通常，您會從遠端儲存庫檢查最新版本的程式碼來開始此步驟，但我們尚未有本機儲存庫，因此我們從遠端儲存庫複製它。

️ 任務：更新本機儲存庫，從中建立分支 master， 開始工作

  1. 從複製課程儲存庫 <URL репозитория>.
  2. 跑 npm install 在課程儲存庫目錄中； 我們需要它來安裝 Jest，我們用它來執行測試。
  3. 建立一個分支並命名 feature。 切換到這個線程。

  4. 添加測試代碼到 ci.test.js 在要求我這樣做的評論之間。

    it('1. pull latest code', () => {
  expect(/.*pull.*/ig.test(fileContents)).toBe(true);
});

it('2. add commits', () => {
  expect(/.*commit.*/ig.test(fileContents)).toBe(true);
});

it('3. push to the remote branch with the same name', () => {
  expect(/.*push.*/ig.test(fileContents)).toBe(true);
});

it('4. create a pull request and continue working', () => {
  expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
});

  5. 將包含前 4 個步驟的文字新增至文件中 ci.md. 
    1. Pull in the latest code. Create a branch from `master`. Start working.    
2. Create commits on your new branch. Build and test locally.  
Pass? Go to the next step. Fail? Fix errors or tests and try again.  
3. Push to your remote repository or remote branch.  
4. Create a pull request. Discuss the changes, add more commits  
as discussion continues. Make tests pass on the feature branch.

    命令

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

在新分支上建立提交，在本地建置和測試

我們將在提交之前設定要執行的測試，然後提交程式碼。

自動執行測試時的典型場景

  • 本地：
    • 持續或回應適當的程式碼變更；
    • 儲存時（對於解釋型或 JIT 編譯型語言）；
    • 彙編期間（需要編譯時）；
    • 提交時；
    • 發佈到共享儲存庫時。

  • 在建置伺服器或建置環境上：
    • 當程式碼發佈到個人分支/儲存庫。
    • 該線程中的程式碼正在測試中。
    • 測試合併的潛在結果（通常使用 master).
    • 作為持續整合階段/持續交付管道

通常，測試套件運行得越快，您就可以更頻繁地運行它。 典型的階段分佈可能如下所示。

  • 快速單元測試 - 在建置期間、在 CI 管道中
  • 緩慢的單元測試，快速的組件和集成測試 - 提交時，在 CI 管道中
  • 緩慢的組件和整合測試 - 在 CI 管道中
  • 安全測試、負載測試和其他耗時或昂貴的測試 - 在 CI/CD 管道中，但僅限於建置的某些模式/階段/管道，例如，在準備候選版本或手動運行時。

️任務

我建議先使用命令手動執行測試 npm test。 之後，讓我們新增一個 git hook 來在提交時執行我們的測試。 有一個問題：Git 掛鉤不被視為存儲庫的一部分，因此無法與課程材料的其餘部分一起從 GitHub 克隆。 要安裝鉤子，您需要運行 install_hook.sh 或複製文件 repo/hooks/pre-commit 到本地目錄 .git/hooks/.
當您提交時，您將看到測試正在運行，並且它們會檢查清單中是否存在某些關鍵字。

  1. 透過執行命令手動執行測試 npm test 在您的課程儲存庫資料夾中。 驗證測試是否已完成。
  2. 透過運行設定提交掛鉤（預先提交掛鉤） install_hook.sh.
  3. 將您的變更提交到本機儲存庫。
  4. 確保在提交之前運行測試。

執行以下步驟後，您的儲存庫應如下所示。
持續整合的典型情況

命令

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.

將程式碼發佈到遠端儲存庫或遠端分支

一旦完成本地工作，開發人員通常會將他們的程式碼公開，以便最終可以與公眾整合。 對於 GitHub，這通常是透過將工作發佈到儲存庫的個人副本（個人分支）或個人分支來實現的。

  • 透過分叉，開發人員可以克隆遠端共用儲存庫，建立其個人遠端副本，也稱為分叉。 然後它會克隆這個個人存儲庫以在本地使用。 當工作完成並提交後，他將它們推送到他的分支中，其他人可以使用它們，並且可以將它們整合到公共儲存庫中。 這種方法常用於 GitHub 上的開源專案。 我的高級課程 [Team Work and CI with Git] 中也使用了它（http://devops.redpill.solutions/).
  • 另一種方法是僅使用一個遠端儲存庫並僅計算分支 master 共用儲存庫「受保護」。 在這種情況下，個別開發人員將他們的程式碼發佈到遠端儲存庫的分支，以便其他人可以查看此程式碼，如果一切正常，請將其與 master 共享儲存庫。

在本課程中，我們將使用使用分支的工作流程。

讓我們發布我們的程式碼。

️任務

  • 將變更發佈到與您的工作分支同名的遠端分支

命令

git push --set-upstream origin feature

建立拉取請求

建立帶有標題的拉取請求 步驟回顧... 安裝 feature 像是「頭分支」和 master 就像「基礎分支」。

確保您已經安裝 master 在他的 分叉儲存庫 作為“基地分支”，我不會回應更改課程材料存儲庫的請求。

在 GitHub 術語中，「基礎分支」是您工作所基於的分支，「頭分支」是包含建議變更的分支。

討論更改，隨著討論的繼續添加新的提交

拉取請求（PR）

拉取請求（PR） 是討論和記錄程式碼以及進行程式碼審查的一種方式。 拉取請求以將單一變更整合到整體程式碼中的一般方式命名。 通常，一個人克隆專案的遠端官方儲存庫並在本地處理程式碼。 之後，他將程式碼放在他的個人遠端儲存庫中，並要求官方儲存庫的負責人來領取（拉）將其程式碼放入本地存儲庫，在那裡他們進行審查並可能集成（合併） 他的。 這個概念還有其他名稱，例如， 合併請求.

您實際上不必使用 GitHub 或類似平台的拉取請求功能。 開發團隊可能會使用其他溝通方式，包括面對面溝通、語音通話或電子郵件，但仍有許多理由使用論壇式的拉取請求。 這裡是其中的一些：

  • 組織與特定程式碼變更相關的討論；
  • 作為查看自動測試人員和同行對正在進行的工作的反饋的​​地方；
  • 代碼審查的形式化；
  • 以便稍後您可以找出這段或那段程式碼背後的原因和考慮因素。

通常，當您需要討論某件事或獲得回饋時，您會建立拉取請求。 例如，如果您正在開發可以透過多種方式實現的功能，則可以在編寫第一行程式碼之前建立拉取請求，以與協作者分享您的想法並討論您的計劃。 如果工作更簡單，當某些事情已經完成、提交並且可以討論時，就會打開拉取請求。 在某些情況下，您可能只想出於品質控制原因開啟 PR：執行自動化測試或啟動程式碼審查。 無論您決定如何，都不要忘記在拉取請求中@提及您希望獲得其批准的人員。

通常，在建立 PR 時，您需要執行以下操作。

  • 指出您建議更改的內容和位置。
  • 撰寫說明，解釋更改的目的。 您可能想要：
    • 在添加程式碼中不明顯的任何重要內容，或對理解上下文有用的內容，例如相關的 #bug 和提交編號；
    • @提及您想開始合作的任何人，或者您可以稍後在評論中@提及他們；
    • 請同事幫忙做某件事或檢查某件事。

開啟 PR 後，就會執行配置為在此類情況下執行的測試。 在我們的例子中，這將是我們在本地運行的同一組測試，但在實際專案中可能會有額外的測試和檢查。

測試完成後請稍候。 您可以在 GitHub 介面中 PR 討論的底部看到測試的狀態。 測試完成後繼續。

️ 新增關於 CI 步驟清單的隨機性的註釋

本課程中使用的清單是任意且主觀的，我們應該對此添加註釋。

️ 任務：為此評論建立拉取要求

  1. 切換到分支 master.
  2. 建立一個名為 bugfix.
  3. 將註釋文字新增至文件末尾 ci.md. 
    > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
when code is deployed straight from feature branches. This list is just an interpretation  
that I use in my [DevOps courses](http://redpill.solutions).  
The official tutorial is [here](https://guides.github.com/introduction/flow/).
  4. 提交更改。
  5. 發布主題 bugfix 到遠端存儲庫。
  6. 建立一個名為的拉取請求 新增備註 有頭枝 bugfix 和基礎分支master.

確保您已經安裝 master 在他的 分叉儲存庫 作為“基地分支”，我不會回應更改課程材料存儲庫的請求。

這就是您的儲存庫應該的樣子。
持續整合的典型情況

命令

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

批准拉取請求“添加備註”

️任務

  1. 建立拉取請求。
  2. 按一下「合併拉取要求」。
  3. 按一下“確認合併”。
  4. 點擊“刪除分支”，我們不再需要它了。

這是合併後提交的圖表。
持續整合的典型情況

️ 繼續工作並添加測試

協作處理拉取請求通常會導致額外的工作。 這通常是程式碼審查或討論的結果，但在我們的課程中，我們將透過向 CI 步驟清單新增項目來對此進行建模。

持續整合通常涉及一些測試覆蓋率。 測試覆蓋率要求各不相同，通常可以在名為「貢獻指南」之類的文件中找到。 我們將保持簡單並為清單中的每一行添加測試。

執行作業時，請嘗試先提交測驗。 如果你安裝正確 pre-commit 較早掛鉤，新添加的測試將運行，將失敗，並且不會提交任何內容。 請注意，這就是我們知道我們的測試實際上正在測試某些內容的方式。 有趣的是，如果我們在測試之前開始編寫程式碼，那麼通過測試可能意味著程式碼按預期工作，或者測試實際上沒有測試任何內容。 另外，如果我們一開始就沒有寫測試，我們可能會完全忘記它們，因為沒有任何東西會提醒我們它。

測試驅動開發 (TDD)

TDD 建議在程式碼之前編寫測試。 使用 TDD 的典型工作流程如下所示。

  1. 新增一個測試。
  2. 執行所有測試並確保新測試失敗。
  3. 編寫程式碼。
  4. 運行測試，確保所有測試都通過。
  5. 重構你的程式碼。
  6. 重複。

由於失敗的測試結果通常顯示為紅色，而通過的測試結果通常顯示為綠色，因此該循環也稱為紅綠重構。

️任務

首先，嘗試提交測試並讓它們失敗，然後新增並提交 CI 步驟清單本身的文字。 您將看到測試正在通過（“綠色”）。
然後將新程式碼發佈到遠端儲存庫，並在拉取請求討論和 PR 狀態更新底部的 GitHub 介面中觀看測試運行情況。

  1. 切換到分支 feature.

  2. 將這些測試添加到 ci.test.js 最後一次通話後 it (...);.

    it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
  expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
});

it('6. Deploy from the feature branch to production.', () => {
  expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
});

it('7. If everything is good in production for some period of time, merge changes to master.', () => {
  expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
});

  3. 嘗試提交測試。 如果 pre-commit 安裝鉤子後，提交嘗試將失敗。
  4. 然後將此文字新增至 ci.md. 
    5. Merge/rebase commits from master. Make tests pass on the merge result.  
6. Deploy from the feature branch with a sneaky bug to production.
7. If everything is good in production for some period of time, merge changes to master.
  5. 在本地進行並提交更改。
  6. 將變更發佈到分支 feature.

你現在應該有這樣的東西
持續整合的典型情況

命令


# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

合併衝突

轉到更改請求 步驟回顧.

即使我們沒有做錯任何事情並且程式碼測試通過了，我們仍然無法合併分支 feature и master。 這是因為另一個線程 bugfix 被合併於 master 當我們在做這個公關的時候。
這會造成遠端分支的情況 master 有一個比我們分支所基於的版本更新的版本 feature。 因此我們不能只是倒帶 HEAD master 到線程的末尾 feature。 在這種情況下，我們需要合併或應用提交 feature 變基 master。 如果沒有衝突，GitHub 實際上可以執行自動合併。 唉，在我們的情況下，兩個分支在文件中都有競爭性的更改 ci.md。 這種情況稱為合併衝突，我們需要手動解決。

合併或變基

合併

  • 建立額外的合併提交並保存工作歷史記錄。
    • 保留分支的原始提交及其原始時間戳和作者。
    • 儲存提交的 SHA 並在更改請求討論中連結到它們。
  • 需要一次性解決衝突。
  • 使故事變得非線性。
    • 由於存在大量分支（讓人想起 IDE 電纜），該故事可能難以閱讀。
    • 使自動調試變得更加困難，例如 git bisect 不太有用 - 它只會找到合併提交。

變基

  • 在基本分支之上逐一重播目前分支的提交。
    • 產生具有新 SHA 的新提交，導致 GitHub 中的提交與原始拉取請求匹配，但與相應的註釋不匹配。
    • 提交可以在此過程中重新組合和修改，甚至合併為一個。
  • 可能需要解決多個衝突。
  • 允許您保持線性故事。
    • 只要不是無緣無故太長，故事可能會比較容易閱讀。
    • 自動調試和故障排除變得更容易：使其成為可能 git bisect，可以讓自動回滾更清晰、更可預測。
  • 需要發布帶有標記的已遷移提交的分支 --force 與拉取請求一起使用時。

通常，團隊同意在需要合併變更時始終使用相同的策略。 這可能是「純」合併或頂部「純」提交，或介於兩者之間，例如互動式地在頂部進行提交（git rebase -i) 本機用於未發佈到公用儲存庫的分支，但合併「公用」分支。

這裡我們將使用合併。

️任務

  1. 確保程式碼位於本地分支中 master 從遠端存儲庫更新。
  2. 切換到分支 feature.
  3. 啟動與分支的合併 master。 由於競爭性變更而導致合併衝突 ci.md.
  4. 解決衝突，以便我們的 CI 步驟清單和相關註釋保留在文字中。
  5. 將合併提交發佈到遠端分支 feature.
  6. 在 GitHub UI 中檢查拉取請求的狀態並等待合併解決。

命令

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

做得好！

您已完成列表，現在您需要批准拉取請求 master.

️ 任務：批准拉取請求“步驟審核”

  1. 打開拉取請求。
  2. 按一下「合併拉取要求」。
  3. 按一下“確認合併”。
  4. 點擊“刪除分支”，因為我們不再需要它。

這是您目前的儲存庫
持續整合的典型情況

產品錯誤

據說「測試可以用來顯示錯誤的存在，但永遠不能顯示錯誤的不存在」。 儘管我們進行了測試並且沒有顯示任何錯誤，但一個陰險的錯誤卻悄悄進入了生產環境。

在這樣的場景中，我們需要注意：

  • 生產中部署了什麼；
  • 線程中的程式碼 master 出現錯誤，開發人員可以從中開始新的工作。

我應該在下一個版本中回滾或修復它嗎？

回滾是將已知良好的早期版本部署到生產並恢復包含錯誤的提交的過程。 「向前修復」是在 master 並儘快部署新版本。 由於 API 和資料庫架構會隨著程式碼部署到生產環境而變化，並且具有持續交付和良好的測試覆蓋率，因此回滾通常比在下一版本中修復它要困難得多，風險也更大。

由於回滾在我們的案例中不會帶來任何風險，因此我們將走這條路，因為它允許我們

  • 盡快修復產品上的錯誤；
  • 編寫程式碼 master 立即適合開始新工作。

️任務

  1. 切換到分支 master 本地
  2. 從遠端儲存庫更新本機儲存庫。
  3. 恢復 PR 合併提交 步驟回顧 в master.
  4. 將變更發佈到遠端儲存庫。

這是已恢復合併提交的儲存庫的歷史記錄
持續整合的典型情況

命令

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ 自測

確保 ci.md 恢復合併提交後不再包含文字「sneaky bug」。

修復 CI 步驟清單並將其傳回給 master

我們已經完全恢復了分支的合併提交。 feature。 好消息是我們現在沒有錯誤 master。 壞消息是，我們寶貴的持續整合步驟清單也消失了。 因此，理想情況下，我們需要將修復應用於來自 feature 並將它們返回到 master 以及修復。

我們可以透過不同的方式來解決這個問題：

  • 恢復撤銷合併的提交 feature с master;
  • 從前者移動提交 feature.

在這種情況下，不同的開發團隊使用不同的方法，但我們會將有用的提交移至單獨的分支，並為這個新分支建立單獨的拉取請求。

️任務

  1. 建立一個名為 feature-fix 並切換到它。

  2. 遷移前一個分支的所有提交 feature 到一個新線程。 解決遷移過程中發生的合併衝突。

    持續整合的典型情況

  3. 新增回歸測試 ci.test.js:

    it('does not contain the sneaky bug', () => {
expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
});

  4. 在本地運行測試以確保它們不會失敗。
  5. 刪除文字“有一個偷偷摸摸的錯誤” ci.md.
  6. 將測試變更和步驟清單變更新增至索引並提交。
  7. 將分支發佈到遠端儲存庫。

你最終應該得到類似這樣的結果：
持續整合的典型情況

命令

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

建立拉取請求。

建立帶有標題的拉取請求 修復該功能... 安裝 feature-fix 像是「頭分支」和 master 就像「基礎分支」。
測試完成後請稍候。 您可以在 PR 討論的底部查看測試的狀態。

確保您已經安裝 master 在他的 分叉儲存庫 作為“基地分支”，我不會回應更改課程材料存儲庫的請求。

批准拉取請求“修復功能”

感謝指正！ 請批准更改 master 來自拉取請求。

️任務

  1. 按一下「合併拉取要求」。
  2. 按一下“確認合併”。
  3. 點擊“刪除分支”，因為我們不再需要它。

這就是你現在應該擁有的。
持續整合的典型情況

恭喜！

您已經完成了人們在持續整合過程中通常採取的所有步驟。

如果您發現課程有任何問題或知道如何改進，請在 包含課程材料的儲存庫。 本課程還有 互動版 使用 GitHub 學習實驗室作為平台。

來源： www.habr.com

添加評論