Git

這個頁面包含了我覺得很好用但很難記住的 Git 命令列表。 合併一連串的提交並重寫提交歷史 將存在於另一個分支的提交應用到當前分支上 還原文件至最後一次提交的狀態（撤消更改） 以漂亮的圖形顯示提交歷史 獲取更好看的日誌 獲取簡潔的狀態 在本地檢查一個拉取請求 列出和特定文件相關的提交 列出和特定文件相關的提交，包括提交的內容 按提交次數排序列出貢獻者 撤回最後一次提交並推送至遠端 選擇已經提交但未合併至當前分支的所有更改並新建一個分支 停止追蹤某一文件，但仍保留在文件系統中 查詢特定提交所在的分支名稱 將一連串的提交合併為一個提交並重寫提交歷史 git rebase -i 執行後會進入交互式 Rebase 工具，輸入 s 將一個提交與前一個提交合併。需要合併多個提交時重複使用 s 指令。 將存在於另一個分支的提交應用到當前分支上 單個提交： git cherry-pick <commit> 多個提交： git cherry-pick <commit1> <commit2> <commit3> 還原文件至最後一次提交的狀態（撤消更改） git checkout -- <filename> 以漂亮的圖形顯示提交歷史 git log --pretty=format:"%h %s" --graph 獲取更好看的日誌 git log --pretty=format:"%h - %an, %ar : %s" 獲取簡潔的狀態 git status -s 在本地檢查一個拉取請求 git fetch origin pull/<id>/head:<branch> git checkout <branch> 列出和特定文件相關的提交 git log --follow -- <filename> 列出和特定文件相關的提交，包括提交的內容 git log --follow -p -- <filename> 按提交次數排序列出貢獻者 git shortlog -s -n 撤回最後一次提交並推送至遠端 git revert -n HEAD 選擇已經提交但未合併至當前分支的所有更改並新建一個分支 git checkout -b <branch> 停止追蹤某一文件，但仍保留在文件系統中 git rm -r --cached 查詢特定提交所在的分支名稱 git branch --contains <commit>

＃如何從另一個分支更新Git分支 假設有一個未與另一個分支同步的Git分支，該如何合併更改？ 我正在使用一個與我在另一個分支上進行的更改不同步的Git分支進行工作。 因此，我需要導入這些更改。假設有一個未與另一個分支同步的Git分支，該如何合併更改？ 您可以先切換到要更新的分支： git checkout my-branch 然後從要更新的分支合併： git merge another-branch 這將創建一個合併提交，其中包含兩個分支之間的所有差異-這是一個單獨的提交。 同時，您也可以參考我的Git指南。

最近，我在 Netlify 上創建了一個新的網站，希望將其中一部分公開在 GitHub 上，以便任何人都可以提交錯別字等問題的拉取請求。 我在 Hugo 倉庫中有一個名為 content 的文件夾，我想公開的部分是一個名為 handbook 的文件夾。 因此，我為此創建了一個新的倉庫，名為 handbook。 我刪除了父倉庫中的 content/handbook 文件夾（如果您從頭開始創建，則不需要此步驟，但我希望移動現有內容）： rm -rf content/handbook 然後我提交了更改，然後添加了子模組： git submodule add https://github.com/flaviocopes/handbook 我在 Netlify 上部署了網站，它自動捕獲了子模組。 但在本地上遇到了一個問題，因為並不是像子模組存儲庫文件夾上有著符號鏈接這樣。 我刪除了 content/handbook 文件夾，並從子模組的本地存儲庫添加了一個符號鏈接： ln -s ../../../dev/handbook/ 然後，我告訴 Git 停止跟踪 content/handbook 文件夾，使用以下命令： git update-index --skip-worktree content/handbook （要恢復跟踪，請使用 --no-skip-worktree） 這樣，我既有子模組，也在本地上有指向子模組的符號鏈接，兩者兼得。

我在项目中使用 Git 作为版本控制工具，并且经常遵循以下策略。 这个策略受到了A successful Git branching model的启发。 我有两个永久分支：master和develop。 以下是我日常开发中遵循的规则： 当我接手一个新任务或决定加入一个功能时，有两条主要路径： 如果功能较为简单，或后续提交不会破坏代码（至少我希望如此）：我可以在develop分支上提交，或者创建一个快速功能分支，然后将其合并到develop分支上。 如果功能需要进行多次提交才能完成，可能需要花费几天时间提交才能使功能恢复稳定的状态：我会创建一个功能分支，然后将其合并到develop分支上。 如果我们的生产服务器需要立即采取措施，比如需要尽快解决的 bug 修复，我会创建一个短期修复分支，解决问题后在本地和测试机上进行测试，然后将其合并到 master 和 develop 分支上。 如果我需要在生产服务器上快速推送一个功能或修改，并且 develop 分支中代码不稳定，我希望尽快得到该功能或修改：我可以跳过 develop 分支，创建一个快速功能分支并将其合并到 master 和 develop 分支上，只要这个功能或修改是快速且简单的。如果在后续过程中发现这是一个更复杂的问题，最好等待并稳定 develop 分支上的代码。 develop 分支会一直处于不稳定状态，所以在准备发布时，需要将其放入“冻结”状态。代码经过测试，所有工作流程都经过验证，准备将其合并到 master 分支上。 每次将 develop 或其他短期修复分支合并到 master 分支时，我都会使用版本号做标签，这样如果出现问题可以轻松回滚到先前的状态。

使用 Go 撰寫 Git 統計分析 CLI 工具的教程 幾年前，我使用 Electron + Meteor.js + gitlog 桌面應用程式掃描了我的本地 Git 存儲庫，並為我提供了一個漂亮的貢獻圖，就像 GitHub.com 上顯示的那樣： 那是在每個應用程序都使用 Electron 之前，由於生成的應用程序大小，我非常不喜歡這種方法，如果與基於 WebKit 的 MacGap 相比較，它的大小要大 50 倍。不管怎樣，它看起來像這樣，具有類似 GitHub 的用戶界面： 我發現它很有用，因為不是所有的項目都在 GitHub 上，一些項目位於 BitBucket 或 GitLab 上，但我所工作的所有代碼都在我的筆記本電腦上，所以這便是“事實的單一來源”。 該應用程序仍在運行，但尚未釋放給大眾使用。 今天我決定將其作為 Go 控制台命令進行移植，因為我仍認為這個概念很好。 本文中要建立的內容 🎉 一個類似下圖的CLI命令，生成類似的圖表 在哪裡可以找到這段程式碼 該程式碼在此 Gist 鏈接上： https://gist.github.com/flaviocopes/bf2f982ee8f2ae3f455b06c7b2b03695 首先的步驟 我將任務分為兩部分： 1.獲取要掃描的文件夾列表 2.生成統計信息 我將使用 Go 命令行標記解析 來讓一個單一命令執行這兩個任務。當傳遞 -add 標記時，該命令將添加新的文件夾到列表中。在沒有標記的情況下執行該命令將生成圖表。為了避免一次性為用戶輸出過多數據，我將限制數據集的時間範圍在過去的 6 個月內。 讓我們為此分層概念撰寫一個簡單的外殼： package main import ( "flag" ) // scan given a path crawls it and its subfolders // searching for Git repositories func scan(path string) { print("scan") } // stats generates a nice graph of your Git contributions func stats(email string) { print("stats") } func main() { var folder string var email string flag....

我每天都使用 Git，過去我曾寫過一篇 Git 指南 和一份 Git Cheat Sheet。 我自認為是一名 Git 的愛好者，但……我不是一個 Git 專家。 提交、抓取遠程庫、拉取遠程庫、推送到遠程庫……這是我每天使用 Git 的日常事務。 儘管如此，我還是會用一些 Git 的進階功能： Git 能做的進階操作讓我感到驚訝。它可以非常複雜，但我傾向於避免複雜的操作。我幾乎從不使用命令行工具進行 Git 操作，而是使用 GitHub Desktop，這是迄今為止最簡單和最好用的 Git 客戶端。 然而，有兩個功能我有時會使用，分別是 cherry-picking 和合併提交記錄。 讓我們來談談這兩個功能。 在只有我一個開發者的項目中（也就是所有我個人的項目），我往往傾向於直接在主分支（master）上進行工作。例如，如果我只是進行一個簡單的更改，或者向博客添加一篇新文章。這些都是快速且不會破壞原有功能的工作。 但在某些情況下，我並不使用這種方式，而是為一個大的功能創建一個分支。 這在團隊或者開源項目中也是默認的方式。 你創建一個分支，並且經常提交。早期和頻繁地提交有很大的優勢，因為你可以有信心地在代碼上進行工作，知道你總能回到一個正常的狀態，或者至少回到你知道某些東西是正常的之前的狀態。 你可能會進行一系列快速的提交，其中的提交信息可能是“ok”，“試驗這個”，或者“修復愚蠢的錯誤”。 但是在某個時候，你需要收斂到一個穩定的狀態，將更改提交回主分支（master）或任何你想合併的分支。 在那之前，你需要做一件事情：合併（squashing）你的提交記錄。 在 Github 中，當你合併一個 Pull Request 時，它可以自動為你合併提交記錄。這是我過去在公開的開源項目中使用得非常多的工作流程。你只會看到一個提交，而不是在 Pull Request 中包含的所有獨立提交。在 PR 合併過程中，你可以編寫詳細的提交訊息和說明。 這將消除所有與你要合併的分支的頭部（head）不一致的前一個 Git 提交記錄，也將刪除那些可能撤消更改的提交記錄等等。 這就是 Github PR 流程中的合併（squashing）。你也可以在 Github 之外進行合併（squashing）。 一旦你在一個分支上的工作完成，你將 master（或任何你想要合併的分支）合併進來： git merge master 這樣你可以解決任何更新衝突。 然後你切換到 master 分支，並運行以下命令： git merge --squash <你的功能分支> 然後執行...

或者在GitLab或其他公共源代碼管理平台上。現在該怎麼辦？ 我偶然發現了一個網站，該網站不斷掃描GitHub、GitLab和BitBucket，這是三個最常用的公開源代碼主機地方，並展示了提交的SSH密碼、常用服務的API金鑰、數據庫等等。 這讓人很害怕，對吧？ 如果這從未發生過，請舉手。我們都會犯錯。當這種情況發生時，唯一的辦法就是迅速使公開的密碼或API金鑰失效。 對於新手來說，在Git中，你不能只是回滾提交，因為它仍然會保留在存儲庫的歷史記錄中。 你的聲譽、項目的聲譽、用戶的安全都面臨風險。 在解決緊急情況後，問題是：如何避免這個問題？答案是什麼？有什麼解決方案可以幫助我們避免將密鑰提交到公開可用的Git存儲庫中？ 答案是：工作流程和工具。 首先，永遠不要將API金鑰或密碼添加到源代碼中。它們可能悄悄地藏在那裡。相反，始終將它們添加到項目根文件夾中的.env文件中，並將.env添加到.gitignore文件中，這樣就不會被提交。使用類似dotenv的工具來訪問它們。 使用git-secrets工具，它將幫助你避免將密鑰提交到Git中。 在macOS上，你可以使用Homebrew進行安裝： brew install git-secrets 然後進入要在其上啟用它的存儲庫中，運行： git secrets --install 以安裝Git pre-commit hook。這將確保在Git提交到存儲庫之前運行該工具。 如果你使用Amazon Web Services (AWS)，運行以下命令以添加該服務的識別模式集： git secrets --register-aws 你可以立即使用以下命令掃描問題： git secrets --scan 理想情況下，該工具不應該打印任何內容。但如果有問題，它會提供詳細的信息。

我曾經有這樣的需求：有兩個GitHub存儲庫需要包含完全相同的內容。無論何時我推送更改，這些更改都必須同時發送到這兩個存儲庫，而不需要額外的工作。 以下是我所做的： 我已經有一個工作中的存儲庫，其中包含一些代碼，並在Git中設置為“origin”遠程。 我在GitHub上創建了一個新的空存儲庫，並將其設置為“origin”遠程的另一個URL： git remote set-url --add --push origin [[email protected]](/cdn-cgi/l/email-protection):flaviocopes/original.git git remote set-url --add --push origin [[email protected]](/cdn-cgi/l/email-protection):flaviocopes/clone.git 完成！現在，只需執行“git push”命令，即可將更改推送到兩個存儲庫中。

設定 GitHub 認證，以便您可以在 VS Code 或命令列中使用它。 我通常使用 GitHub Desktop 應用程式與我的 GitHub 帳戶互動，這是我所有程式碼和網站的 Git 儲存庫。 但有時候您需要使用 git 命令列，或者使用 VS Code 中的 Git 整合功能。 如果沒有進行以下步驟，您可能會遇到認證問題。 讓我們設定它。 我假設您已經安裝了 Homebrew。 請在命令列中執行以下命令： brew install gh 然後使用 gh 工具： gh auth login 之後回答幾個問題。 選擇 HTTPS： 選擇 Y： 接著登入瀏覽器： 點擊 Authorize GitHub： 完成： 回到您的終端機或 VS Code，一切將按預期運作。

如何在GitHub上編輯項目並創建PR呢？ 關於這個主題有很多教程，但許多教程過於複雜，它們假設你必須為項目做出代碼貢獻，所以還有一些git設置。 如果你只需要編輯一個文件，比如修正項目的README中的拼寫錯誤呢？ 你不需要知道如何編程或如何使用Git來完成這個操作。但是，一旦你開始進行Pull Request，你就可以進行更多事情並與其他人協作項目！也許這會激勵你在以後貢獻代碼。 假設你已經有一個（免費）GitHub帳號。如果沒有，請訪問github.com生成一個。 讓我向你展示整個流程。 我找到了一篇可能有拼寫錯誤的文章，該文章存在於這個頁面：https://web.dev/prefers-color-scheme/ 我知道該網站是托管在GitHub上的，具體該文章位於這裡：https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme 我直接在GitHub上打開index.md文件https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md，然後按文件工具欄中的鉛筆圖標。將鼠標懸停在圖標上會顯示“Fork this project and edit the file”。 這將打開一個編輯器界面，顯示以下信息： 你正在編輯一個你沒有寫權限的項目中的文件。將提交對這個文件的更改，將它寫入你的fork flaviocopes/web.dev 的一個新分支中，然後你可以發送一個pull request。 我在文件中添加了那個句號，然後在底部的表單中解釋了我所做的更改： 我點擊了“Propose File Change”按鈕，然後顯示了一個比較視圖： 在這裡，我可以查看我所做的更改，確保一切都正常，最後我可以點擊“Create Pull Request”按鈕。目前這些更改已經發生在你fork的項目上，當你點擊鉛筆圖標時，GitHub會自動創建你的fork。 在這個視圖的頂部，你可以看到我正在將一個PR提交到GoogleChrome/web.dev項目，從我的fork flaviocopes/web.dev的分支patch-2到他們的master分支。 點擊“Create Pull Request”按鈕會顯示另一個表單，在這裡我可以為Pull Request撰寫詳細的描述。 Pull Requests可以包含多個不同的更改，理論上你可以在同一個PR中編輯許多文件，這就是為什麼你可以添加摘要。 這個倉庫有一個用於PR文本的模板，以幫助團隊管理它。我們的PR非常簡單，所以我移除了模板，只是將之前提交消息中的內容粘貼了過來。 右邊的提示看到了嗎？他們告訴我這個項目有一個CONTRIBUTING.md文件，其中解釋了如何參與貢獻和遵守的準則。非常酷。 看起來我們需要簽署一個CLA（貢獻者授權協議）來完成我們的PR。我過去已經簽署了Google的CLA，所以對我來說這一步很清楚，但你可能需要處理這個。大多數項目實際上不需要它。 我點擊“Create pull request”，PR現在已經提交！ 現在由項目維護者來接受，你只需要等待一封郵件告訴你它是否被合併，或者其他人是否有評論。 […過了幾個小時…] 我收到了一封郵件，該PR被拒絕了，因為那個句號實際上是在正確的位置上！（我不知道） 但無論如何，這是我想要添加的一個事情：如果你提交的PR不被接受，不要生氣或沮喪。項目的維護者可能花了好幾個月或幾年的時間，他們對於項目的了解比你更多。 此外，特別是對於代碼而言，觀點可能非常不同，你認為很好的PR可能不被歡迎。 最好在進行實質性PR之前先詢問，看看項目是否真的需要這樣的改變。 但這是另一個話題。