眾所周知，版本控制系統會將所有的變更都存起來，因此我們能夠隨意回溯到任一版本，這些變更也包含你不小心提交存有機密資料的檔案，或是帳號密碼等字串。
對於版本控制不熟的使用者來說，可能會以為再提交 1 個已經刪除機敏資料的 commit 就安全了，實則不然，有心人士依然可以透過回溯版本或者在 .git 版本控制系統的資料夾內用工具撈出各種疑似帳號密碼的字串，進而入侵你的系統。
實際上也確實有數起資安事故是由於版本控制系統中含有帳號密碼等資訊所造成。
所以要從清理機敏資料，一定要連版本控制系統內的變動紀錄都要一併清理才安全！
本文將教導如何以 bfg 指令安全地清除含有密碼、金鑰等機敏資料的 commits 。
Git switch 指令是 Git 2.23 版本開始新增的一個指令，它用於切換分支(branch)。
因為以往使用 git checkout 不僅可以還原檔案，也可以用來切換分支，如果有檔案剛好跟分支名稱相同，就容易造成混淆⋯⋯。
所以 git switch 的出現，就是為了分擔 git checkout 的職責，讓切換分支的功能全權由 git switch 負責，也讓 git 的指令有明確的分工並增加易用性（不過 git checkout 依然有向下相容切換分支的功能）。
本文是關於 git switch 指令的簡單教學。
Git 可以做到 repository 中嵌入其他 git repositories, 相當於版本控制原本的 repository 之外，也把內嵌的 repositories 也納入版本控制的範圍，這功能被稱為 submodule 。
不過 submodule 並不是將內嵌 repository 的所有檔案都做額外的版本控制，而是類似於做一個指標(pointer)，將 submodule 的版本指向內嵌的 repository 的某 1 個 commit id 。
常言道「不會 rebase, 等於沒學過 Git」，由此可見 rebase在 Git 內有多重要。
在開始本文之前，請大家牢記千萬不要對已經 push 到遠端儲存庫(remote repository) 而且已經有人正在使用的提交進行 rebase ，這是很危險的！詳情請見 The Perils of Rebasing 。
Do not rebase commits that exist outside your repository and that people may have based work on.
改變歷史是很危險的！請牢記在心！
接下來，本文會說明什麼是 rebase，並且介紹 rebase 的基本用法。
程式的開發幾乎都需要所謂的「版號」或「版本號」，除了開發者之間可用以識別正在開發或維護的程式是否版本相同之外，也可以用版號來表示程式的開發狀態(例如 development, alpha, beta, production/stable 等等)，或者是標示重大版本演進(例如從 1.0 演變為 2.0)。
不同的開發者或者開發團隊，也都會有不同的版號規則。
但目前常見的 2 種版號規則如下：
更詳細的說明可以參見：http://en.wikipedia.org/wiki/Software_versioning
上版號的工作，可以利用 Git 標籤的功能達成。
本文將介紹如何使用 Git 的標籤(tag)功能 。
開發團隊在實作各種不同的功能時，版本衝突是肯定會遇到的一種情況，除了慢慢修正一個接一個的 conflict 之外，本文介紹 2 種可以省時費力的解決方法。
在本文中，我們將依據 A successful Git branching model一文，解說並示範幾種開發情境可以應用的分支策略模型，不論是大型專案或小型應用程式，皆可套用於其中，並享受分支策略模型所帶來的效益。
在文章裡有關專案(project)的任何細節將不被談論，只談論分支(branching)的策略及發佈(release)的管理。
下圖即是整個分支策略的概觀：
後續小節將敘述相關分支策略的細節。
經典的多人合作開發模式，是由 Git Server 提供中央的儲存庫(repository)儲存主線(master/main)，由其他團隊成員複製(clone)到各自的開發環境，接著從主線分出分支(branch)，在各自的環境內開發完成之後，最後將分支合併(merge)回主線。
軟體開發，就是如此重複循環作業。
Posted on Oct 23, 2022 in Git 版本控制 by Amo Chen ‐ 10 min read