本文為windows下git的下載安裝和使用。
git下載和安裝
參考：
windows安裝git（全網最詳細，保姆教程）-CSDN博客
【學了就忘】Git介紹 — 4.Git的安裝 - 簡書
先解決下載時的一些疑惑：
選擇哪個架構？
電腦ARM64和X64的區別
在計算機科學和硬件設計領域，ARM64和X64是兩種重要的處理器架構。它們在設計理念、應用場景、性能和能效方面有著顯著的區別。
架構設計哲學
X64架構，也被稱為AMD64或Intel 64，是對經典的32位x86指令集架構（ISA）的擴展。它遵循**復雜指令集計算（CISC）**設計原則，設計有復雜的指令，可以執行多步操作。這種設計初衷是為了減少編譯器的工作量，直接在硬件層面實現復雜的操作。然而，這也使得X64處理器的設計和實現更加復雜，消耗更多的電力，并且在某些情況下降低了處理速度(1)。
ARM64，亦稱為AArch64，是ARM架構的64位版本，由ARM Holdings設計。它遵循**精簡指令集計算（RISC）**原則，強調使用較少、更簡單的指令集來執行操作。這種方法旨在通過提高指令的執行速度來提升性能，同時降低處理器的能耗和成本(2)。
應用和生態系統
X64架構長期以來一直是桌面計算機和服務器的主導架構，得益于其與舊x86應用程序的兼容性，以及其在處理高性能計算任務方面的能力。這意味著，對于運行復雜的桌面操作系統、大型數據庫和高端游戲等，X64提供了強大的支持(1)。
ARM64由于其出色的能效比和對低功耗的優化，主要用于智能手機、平板電腦、嵌入式系統和輕薄筆記本電腦。近年來，隨著Apple推出基于ARM64的M1芯片，以及微軟和Qualcomm合作開發的Windows on ARM項目，ARM64架構開始進入高性能計算和桌面計算領域，挑戰X64的主導地位(2)。
性能與能效
由于設計哲學和應用場景的不同，X64和ARM64在性能與能效方面存在顯著差異。X64處理器通常提供更高的計算性能，特別是在需要大量數據處理和復雜計算的任務中，如圖形渲染、科學計算和服務器應用。然而，這種性能是以更高的能耗為代價的(2)。
相比之下，ARM64架構的處理器在保持合理性能的同時，顯著降低了能耗。這不僅使得ARM64設備在續航方面表現更好，而且還減少了散熱需求，允許制造更輕薄的設備(2)。
結論
盡管X64和ARM64都是現代計算設備中極為重要的處理器架構，但它們在設計理念、應用場景、性能和能效方面有著根本的區別。X64優于處理復雜的計算任務和高性能需求，而ARM64在移動設備和高能效要求的場景中占據優勢。隨著技術的發展和市場需求的變化，這兩種架構都在不斷進化，以滿足不斷擴大的應用領域和性能需求。
怎么查看自己的電腦是什么架構的？
其實很簡單，只需要一個命令即可。
在cmd命令窗中輸入systeminfo即可，如下圖：
x64為主流
目前主流的桌面電腦（包括臺式機和筆記本電腦）絕大多數都采用x86-64（簡稱 x64）架構。以下是詳細說明：
x64 架構的普及背景
x64 是 x86 架構的 64 位擴展：由英特爾和 AMD 在 2000 年代初推出，兼容 32 位 x86 程序，同時支持更大的內存尋址（突破 32 位的 4GB 限制）和更高的性能。
取代 32 位架構的趨勢：隨著操作系統（如 Windows 7 及以上、macOS、Linux）和軟件逐漸轉向 64 位，x64 架構成為桌面電腦的主流選擇，目前幾乎所有新出廠的桌面處理器都基于 x64。
其他可能的架構（極少用于桌面）
ARM 架構：主要用于移動設備（手機、平板）和部分低功耗設備（如 Surface Pro X、蘋果 M 系列芯片的 Mac）。雖然蘋果 M 系列（基于 ARM）的 Mac 屬于桌面 / 筆記本范疇，但占比仍低于 x64 設備，且更多被視為 “特例”。
其他架構：如 PowerPC、RISC-V 等，極少用于普通桌面電腦，主要應用于服務器、嵌入式設備或特定領域。
總結
對于絕大多數用戶日常使用的桌面電腦（Windows PC、傳統 x86 架構的 Mac 等），x64 是當前的主流架構。只有少數特殊設備（如蘋果 M 系列 Mac、部分 ARM 架構的輕薄本）采用其他架構，但整體占比不高。
X86和X64是什么關系，誰更先進？
看起來86>64，X86更先進？
x86 和 x64 并非完全獨立的架構，而是繼承與擴展的關系，兩者的核心關聯及技術先進性可從以下角度理解：
一、x86 與 x64 的關系
x86 是基礎架構 x86 起源于 1978 年英特爾的 8086 處理器，是一系列 32 位及以下架構的統稱（包括早期的 16 位處理器）。它通過復雜指令集（CISC）設計，支持多任務、內存管理等功能，成為個人電腦和服務器的主流架構，我們熟悉的 Intel Pentium、AMD Athlon 等早期處理器都基于 x86。
x64 是 x86 的 64 位擴展 隨著硬件性能需求提升，32 位 x86 架構的局限性逐漸顯現（如最大內存尋址僅 4GB）。2000 年代初，AMD 率先推出 x86-64（簡稱 x64）架構，對 x86 進行了 64 位擴展：
兼容 x86：x64 處理器可直接運行 32 位 x86 程序，無需額外模擬；
突破限制：支持 64 位地址空間（理論最大尋址 16EB，遠超 32 位的 4GB），并優化了指令集，提升了多線程和浮點運算性能。 此后英特爾也采納了這一標準，因此 x64 成為 x86 架構的 “升級版”，而非全新架構。
二、誰更先進？
x64 更先進，原因如下：
硬件能力的躍升
內存尋址：x64 支持遠超 4GB 的內存（如 64 位系統可識別 128GB 甚至更大內存），滿足現代軟件（如大型游戲、視頻剪輯、虛擬機）對內存的高需求；
性能優化：x64 增加了更多通用寄存器和向量寄存器，提升了數據處理效率，尤其適合多任務和復雜計算場景。
軟件生態的適配 目前主流操作系統（Windows 10/11、macOS、Linux）和軟件（瀏覽器、設計工具、編程語言）均優先支持 x64，32 位 x86 軟件正逐漸被淘汰（如 Windows 11 已不再原生支持 32 位系統）。
兼容性優勢 x64 并非 “拋棄” x86，而是向下兼容—— 既能運行 64 位程序，也能兼容 32 位 x86 程序，兼顧了新技術和舊軟件的使用需求，而 x86 無法支持 64 位程序。
總結
關系：x64 是 x86 架構的 64 位擴展，基于 x86 發展而來，且完全兼容 x86 程序；
先進性：x64 在內存支持、性能、軟件生態等方面全面優于 x86，是當前主流的先進架構，而 x86（32 位）已逐漸退出主流舞臺，僅在老舊設備或嵌入式場景中少量存在。
選擇哪個版本？
git的Standalone 和 Portable 有什么區別?
Git 的 Standalone（標準安裝版）和 Portable（便攜版）是兩種不同的分發形式，主要區別體現在安裝方式、存儲位置、系統集成度和使用場景上。以下是詳細對比：
一、核心區別
特性 Standalone（標準安裝版） Portable（便攜版） 安裝方式 通過安裝程序（.exe）安裝到系統目錄（如 C:\Program Files） 解壓到任意目錄（如 U 盤、移動硬盤）即可使用，無需安裝 系統集成 深度集成系統：
- 添加環境變量
- 注冊文件關聯
- 安裝系統服務不修改系統配置，完全獨立運行 存儲位置 配置文件和用戶數據存儲在系統目錄或用戶配置文件夾（如 %AppData%） 所有文件集中在解壓目錄，可隨移動設備帶走 便攜性 依賴系統安裝，無法直接復制到其他電腦使用 可在不同電腦間直接移動使用，無需重新配置 適用場景 固定電腦長期使用，需系統級集成功能（如右鍵菜單、環境變量） 移動辦公、多設備共享、臨時使用或受限環境（如無管理員權限） 二、優缺點對比
類型 優點 缺點 Standalone - 系統級集成，使用便捷（如右鍵菜單、全局命令）
- 自動更新
- 適合固定設備長期使用- 安裝需管理員權限
- 無法在不同設備間快速遷移
- 可能與其他版本沖突Portable - 無需安裝，可直接運行
- 完全便攜，適合移動辦公
- 不影響系統配置，可共存多個版本- 缺少系統集成功能（如右鍵菜單）
- 需手動管理更新
- 配置文件可能丟失三、適用場景建議
選擇 Standalone：
在固定電腦上長期使用 Git
需要系統級集成功能（如右鍵菜單、環境變量）
依賴自動更新機制
選擇 Portable：
在多臺電腦間共享 Git 環境（如 U 盤攜帶）
在無管理員權限的設備上使用
需要隔離配置（如測試不同版本的 Git）
臨時使用或不想影響系統原有安裝
四、注意事項
便攜版的路徑依賴：
解壓后不要隨意移動目錄，否則可能導致工具鏈（如 MinGW）無法找到依賴文件。
配置文件管理：
便攜版的配置文件隨解壓目錄存儲，移動設備丟失可能導致配置丟失。建議通過
.gitconfig文件或環境變量同步配置。性能差異：
便攜版從 U 盤運行時，讀寫速度可能較慢，尤其是處理大倉庫時。
總結
Standalone 適合固定設備的長期使用，提供深度系統集成；
Portable 適合移動場景，無需安裝即可使用，且不影響系統環境。
根據你的使用頻率、設備穩定性和是否需要跨設備使用來選擇即可。
下載不下來咋辦
git官網下載不下來
解決辦法參考：
(2 封私信 / 20 條消息) 解決git 官網無法下載問題 - 知乎
git 安裝包 最新 下載 快速 國內 鏡像 地址_安裝包下載安裝-CSDN博客
git使用
安裝完成后咋使用呢？
安裝完成后在桌面點擊鼠標右鍵會顯示如下內容
Git Bash 和 Git GUI 是 Git 提供的兩種不同操作界面，分別面向命令行用戶和圖形界面偏好者。
一般都是使用Git Bash
這時候我們就可以進行本地操作了。
Git Bash 提供了類 Linux 的命令行體驗，支持大多數常用的 Linux 命令和語法，非常適合在 Windows 上使用 Git 的開發者。但由于底層是 Windows 系統，它與原生 Linux 環境仍存在一些差異，在處理復雜場景或系統級操作時需注意。
有了命令行串口，后續的操作和Linux一樣，直接參考：
嵌入式LINUX開發成長計劃_linux嵌入式開發-CSDN博客
如果需要遠程SSH，也一樣配置。
和gitlab交互
附上gitlab的基本使用
一文掌握：Gitlab的完整使用手冊-阿里云開發者社區
注意：關于私有倉庫
在 GitLab 中，倉庫的 ** 私有（Private）和公開（Public）** 設置決定了誰可以訪問、查看和操作倉庫內容。以下是兩者的核心區別及適用場景：
一、核心區別
特性 私有倉庫（Private） 公開倉庫（Public） 可見性 僅項目成員和明確授權的用戶可見 任何互聯網用戶均可查看（無需登錄） 克隆 / 下載權限 僅項目成員可克隆或下載代碼 任何人可克隆或下載代碼 Issue/MR 權限 僅項目成員可創建 / 評論 Issue 和合并請求 非成員可查看 Issue/MR，但需項目成員批準才能合并 Wiki / 文檔權限 僅項目成員可編輯 非成員可查看，但通常無法編輯 默認 CI/CD 行為 僅項目成員可見流水線日志 流水線日志對所有人公開（可能泄露敏感信息） 搜索引擎索引 不會被搜索引擎（如 Google）索引 可能被搜索引擎索引，內容可被公開搜索到 適用場景 商業項目、敏感代碼、內部協作 開源項目、公共文檔、教學資源 二、安全與隱私影響
1. 私有倉庫
數據保護：代碼和相關信息僅對授權用戶可見，適合包含敏感信息（如 API 密鑰、商業邏輯）的項目。
權限精細控制：可針對不同成員設置角色（如 Guest、Developer、Maintainer），限制操作權限。
合規要求：滿足 GDPR、HIPAA 等法規對數據隱私的要求。
2. 公開倉庫
無隱私保護：任何人可查看代碼、提交歷史、Issue 等內容，需確保不包含敏感信息。
潛在風險：
意外提交的密碼、密鑰等可能被濫用。
公開的 CI/CD 日志可能泄露內部網絡信息。
有一個疑問，我在gitlab上有個私有倉庫，我本地能clone下來嗎？
是的，你可以從 GitLab 上克隆私有倉庫到本地，但需要通過身份驗證來證明你有權訪問該倉庫。以下是具體步驟和注意事項：
一、前提條件
已被添加為倉庫成員 倉庫所有者需將你添加為成員（如 Developer、Maintainer 等角色），否則無法訪問。
本地安裝 Git 確保已安裝 Git 并配置了用戶名和郵箱：
二、克隆私有倉庫的方法
方法 1：使用 HTTPS（推薦）
# 從 GitLab 復制 HTTPS 地址 git clone https://gitlab.com/your-group/your-private-repo.git
優點：簡單易用，無需額外配置。
缺點：每次推送 / 拉取需輸入用戶名和密碼（或訪問令牌）。
方法 2：使用 SSH（推薦長期使用）
生成 SSH 密鑰（如果沒有）
將公鑰添加到 GitLab：
復制
~/.ssh/id_ed25519.pub的內容。登錄 GitLab → Settings → SSH Keys → 粘貼公鑰。
克隆倉庫
優點：一次配置后無需重復輸入密碼。
缺點：需正確配置 SSH 密鑰。
三、身份驗證方式
HTTPS 身份驗證
密碼：使用 GitLab 賬號密碼（僅適用于非雙因素認證賬戶）。
個人訪問令牌（推薦）：
生成令牌：GitLab → Settings → Access Tokens → 勾選
api和read_repository權限。克隆時使用令牌代替密碼：
SSH 身份驗證
確保本地私鑰（如
~/.ssh/id_ed25519）未被修改，且與 GitLab 上的公鑰匹配。四、常見問題及解決方法
權限不足錯誤
原因：未被添加為倉庫成員，或 URL 拼寫錯誤。
解決：聯系倉庫所有者添加權限，或檢查 URL。
SSH 連接失敗
原因：SSH 密鑰未配置或不匹配。
解決：
HTTPS 每次都要求輸入密碼
解決：緩存憑證（適用于 Windows/Linux）：
五、總結
只要你是私有倉庫的授權成員，通過 HTTPS 或 SSH 均可成功克隆。建議優先使用 SSH 方式，避免頻繁輸入密碼。如果遇到權限問題，需聯系倉庫所有者確認你的成員身份和角色。
gitlab添加成員是添加的gitlab賬號，我本地使用ssh秘鑰方式從gitlab上clone代碼時，不用登錄賬號密碼，gitlab是怎么知道我有沒有某個倉庫的權限的？
GitLab 通過 SSH 密鑰綁定的用戶身份 和 倉庫成員權限設置 來驗證你的訪問權限。即使你在克隆時無需輸入賬號密碼，GitLab 仍能通過 SSH 密鑰確認你的身份，并檢查該身份是否被授權訪問特定倉庫。具體流程如下：
一、SSH 認證原理
密鑰對綁定 你在本地生成 SSH 密鑰對（公鑰 + 私鑰），并將 公鑰 添加到 GitLab 賬號中。此時，GitLab 會將該公鑰與你的賬號綁定。
身份驗證流程
1. 你發起克隆請求：git clone git@gitlab.com:group/repo.git 2. GitLab 服務器收到請求，要求你證明擁有配對的私鑰 3. 你的本地 SSH 客戶端使用私鑰加密一個挑戰信息并發送給服務器 4. GitLab 用你的公鑰解密該信息，驗證是否匹配 5. 若匹配，GitLab 確認你是公鑰對應的賬號持有者關鍵點
公鑰存儲在 GitLab：每個公鑰唯一對應一個 GitLab 用戶。
私鑰僅保存在本地：不傳輸到服務器，安全性由非對稱加密保證。
二、權限驗證流程
當你通過 SSH 克隆私有倉庫時，GitLab 執行以下檢查：
1. 驗證 SSH 密鑰是否屬于已注冊用戶（身份驗證） 2. 檢查該用戶是否為倉庫成員（權限驗證） 3. 檢查用戶在倉庫中的角色（如 Developer、Maintainer） 4. 根據角色決定允許的操作（如只讀、可提交、可刪除）
若你的 SSH 密鑰綁定的 GitLab 用戶未被添加到倉庫成員中，GitLab 會拒絕訪問。
若你是 Guest 角色，GitLab 僅允許你查看倉庫，而無法克隆或提交代碼。
核心問題就是：我填寫公鑰時需要登錄gitlab賬號，因此可以使得賬號和秘鑰之間產生關聯。
這樣就能保證只有特定的主機和特定的gitlab賬號才能操作特定的倉庫。
實戰記錄?
在gitlab上新建一個工程，并初始化一個readme文件
此時，這個遠程倉庫是空的；
接著，本地電腦上創建一個空目錄，然后將這個倉庫給clone下來（注意要先配置SSH秘鑰）
首先在目錄里點擊鼠標右鍵打開git bash
然后直接git clone xxx
報錯
重試一遍，在提示時輸入yes，就可以了
這時候，倉庫就被clone到本地了；
此時，我本地已經有一個工程了，怎么添加到倉庫？
問題來了：Git 如何將整個文件夾添加到Git
參考：Git 如何將整個文件夾添加到Git|極客教程
可見，git add可以直接添加整個文件夾。
Git將開始跟蹤“myproject”文件夾中的所有文件和子文件夾。
忽略某些文件
Git 如何在Windows上設置.gitignore文件？
參考：
Git 如何在Windows上設置.gitignore文件|極客教程
Windows10 下創建 .gitignore 的方法 - 楷哥 - 博客園
又遇到一個問題，被添加到
.gitignore文件中的文件通常不會被 Git 追蹤，也不會被提交到版本庫，但是我現在的需求是：我想先將整個目錄都提交到gitlab上，但是后續我又想只跟蹤部分目錄，怎么辦？首先要明確一點，通常不想被跟蹤的，都是那些自動生成的內容，比如一些編譯鏈接后，或者打開工程后，生成的一些文件，這種情況下，我們就可以直接在提交之前，將這些內容都刪掉，同時，為了避免后續生成這些文件后被git跟蹤，所以將這些自動生成的內容都在.gitignore里排除掉。
比如：
.depend和.layout是 Code::Blocks 的輔助配置文件，用于優化編譯和保存界面布局。通常不需要版本控制，應通過.gitignore忽略它們，以避免沖突并保持版本庫簡潔。.gitignore只允許某些文件被跟蹤咋寫？
在
.gitignore中使用 否定模式（!） 可以實現 “只允許某些文件被跟蹤” 的需求。# 允許特定文件/目錄 !dir/ # 允許 dir 目錄被跟蹤 !dir/*.txt # 允許 dir 目錄下的 .txt 文件 !important.csv # 允許根目錄下的 important.csv搞定上述內容后，直接git add -> git commit -> git push即可。
 + Python Flask 快速入門 - 接口操作審計日志功能)
)