Git安装到本地仓库创建：从零搭建完整开发环境-代码聚汇网

Git安装到本地仓库创建：从零搭建完整开发环境

莫魔墨·2026-09-02·阅读 21 GEO检测（免费）

Git安装环境配置本地仓库

|难度：普通|阅读约 42 分钟

很多人在学习Git的时候，第一步就卡在了环境安装上。“git不是内部或外部命令”、装完以后怎么点都没反应、好不容易装好了却不知道该怎么建本地仓库，这些问题我在带新人的时候几乎每周都能遇到。所以今天这篇内容，我就把Git安装、环境配置、本地仓库创建这一整条链路完整地捋一遍，从下载安装到敲下第一行git init，再到完成第一次提交，每一步都给出可以直接照着做的流程和参数，同时会把我在实际使用中踩过的坑、总结出的经验一起放进来，给正在入门Git的朋友和需要给团队做环境准备的开发同学做一个参考。

1. 工具选型与安装前准备

1.1 不同操作系统下的Git版本选择

先说结论：官网下载地址是git-scm.com，这是Git官方维护的下载站点，无论你用的是Windows、macOS还是Linux，都建议优先从这里获取安装包，而不是去第三方下载站碰运气。第三方站点的问题不在下载速度，而是你拿到的安装包可能被重新打包过，里面夹带了什么你根本不知道。我确实见过有人从某下载站装完Git之后，浏览器主页被改、多了几个来路不明的插件，这属于典型的安装源污染问题，一旦发生，排查起来非常麻烦。

再说版本选择。Git的版本迭代比较快，但对普通开发者来说，没有必要追求最新版。我的建议是：选当前大版本下的小版本号比较高的稳定版，比如2.4x.x这种。新版本上线初期可能存在一些兼容性问题，而太老的版本又会缺一些新命令参数。以Windows平台为例，下载页面里通常会出现“64-bit Git for Windows Setup”和“32-bit Git for Windows Setup”两个选项，现在绝大多数电脑都是64位系统，直接选64位版本即可。如果你不确定自己的系统位数，可以在Windows设置里查看系统信息，或者按住Win+R键输入“dxdiag”查看。

macOS用户分两种情况：如果你电脑上装了Homebrew，一条命令就能装完：brew install git。这种方式的好处是后续升级方便，brew upgrade git就能搞定。如果没装Homebrew，就直接从官网下载macOS版本的安装包，双击安装，和装普通软件没有区别。

Linux用户直接用包管理器就好。Ubuntu/Debian系用sudo apt install git，CentOS/RHEL系用sudo yum install git，Fedora用sudo dnf install git。需要注意的一点是，系统自带的软件源里Git版本可能偏旧，如果对版本有特殊要求，可以通过添加官方源或源码编译的方式安装，但这对绝大多数场景来说没必要，包管理器给的版本足够日常开发使用。

1.2 安装前需要确认的三件事

在动手安装之前，我建议你先确认三件事，因为这三件事会直接影响后面的体验。

第一，系统架构。Windows用户在下载安装包前，先确认自己是64位还是32位系统。虽然现在32位系统基本绝迹了，但万一你手上是一台老旧的测试机，装错版本就会在安装过程中报错，或者装完以后运行不了。第二，权限问题。安装软件需要管理员权限，Windows下请右键安装包选择“以管理员身份运行”，macOS下如果是通过安装包安装，需要在“系统偏好设置 - 安全性与隐私”中允许从App Store和被认可的开发者那里下载的应用程序。第三，已有的开发环境。如果你电脑上已经装了IDE（比如VS Code、IntelliJ IDEA）或者其他版本控制工具，安装Git时要注意版本冲突和PATH环境变量的问题。之前遇到过一位同事装了TortoiseGit（就是大家俗称的“小乌龟”）之后又装Git for Windows，结果两个工具里的Git命令互相干扰，命令行里输入git help的时候弹出的文档位置都不对。这种情况在使用中虽然不致命，但排查起来确实会让人抓狂。

一个小提醒：如果你日常使用主要依靠IDE内置的Git功能，比如VS Code的源代码管理面板，那系统里装一份标准Git环境仍然是必要的，因为IDE内置插件底层调用的还是系统PATH里的git程序。如果没有独立Git环境，很多IDE插件会直接提示找不到Git。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 安装步骤与核心配置

2.1 Windows平台安装：每一步选什么

Windows下Git安装向导的步骤比较多，大概有十几个页面。这里我不把所有页面都列一遍，只挑几个容易选错、但影响很大的选项重点讲。

第一个是“Select Components”（选择组件）这一步。默认情况下，“Git Bash Here”和“Git GUI Here”是勾选状态，建议保留。Git Bash是Windows下最常用的Git命令行终端，它提供了一个类Linux的shell环境，很多在CMD里跑不了或很难跑的命令在Git Bash里就是一条命令的事。额外建议勾选“Add a Git Bash Profile to Windows Terminal”，这样你可以在Windows Terminal里直接打开Git Bash，体验会好很多。

第二个是“Choosing the default editor”（选择默认编辑器）。Git在某些场景下（比如写commit message、处理合并冲突）会调用一个编辑器。默认选的是Vim，但对不熟悉Vim的人来说，进去以后连怎么保存退出都搞不明白，现场非常尴尬。我见过不止一个新手在Vim里写完提交说明，然后发现不知道怎么关闭，最后直接把命令行窗口关了，结果提交没成，还留下了lock文件。所以这里建议直接选择你平时用的编辑器，比如VS Code、Notepad++，选VS Code的话后面写提交消息会很顺手。如果列表里没有，就选最下面的“Select editor manually”，后续自己配置。

第三个是“Adjusting your PATH environment”（调整PATH环境变量）。这里有三个选项，第一个是“Git from the command line and also from 3rd-party software”，第二个是“Git from the command line only”，第三个是“Use Git and optional Unix tools from the Command Prompt”。关键要选第一个，也是最推荐的一个。选这个以后，Git会被安装到环境变量PATH中，无论是CMD还是PowerShell都能直接识别git命令。选第二个的话，只能在Git Bash里用Git，在CMD里输入git会直接提示“git不是内部或外部命令”。第三个选项会把一些Unix工具也放进PATH，可能会和Windows自带命令产生冲突，不建议选。

第四个是“Configuring the line ending conversions”（行尾转换）。这里Windows和Linux/macOS的换行符标准不一样，Windows是CRLF（回车+换行），Linux和macOS是LF（只换行）。三个选项里，默认选项是“Checkout Windows-style, commit Unix-style line endings”，意思是检出到工作区时转换成CRLF，提交到仓库时转换成LF，这个选项适合在Windows上开发、但项目需要跨平台协作的情况，保持默认即可。如果你所在团队所有人都用Windows，团队也没有跨平台的需求，选第二项“Checkout as-is, commit Unix-style line endings”会更符合实际情况，即在检出时不转换换行符，提交时统一转换成LF。这一项后面还可以通过git config --global core.autocrlf来调整，不用太焦虑。

装完以后，在任意目录下右键，如果能看到“Open Git Bash here”和“Open Git GUI here”两个选项，说明安装位置和组件都正常。

2.2 macOS与Linux平台安装要点

macOS上通过Homebrew安装Git，命令是brew install git。装完后默认路径在/usr/local/bin目录下（Apple Silicon芯片的Mac则在/opt/homebrew/bin目录下）。需要注意的是，macOS系统自带了一个Git的“幽灵版本”——当你直接在终端输入git时，系统可能会弹窗提示你安装“Command Line Tools”。如果你已经通过Homebrew装好了Git，记得在终端里执行which git确认一下，如果输出路径不是/usr/local/bin/git或/opt/homebrew/bin/git，而是/usr/bin/git，那你用的其实还是系统自带版本，需要通过修改PATH优先级或alias的方式确保用上Homebrew版本。

Linux上用包管理器安装基本没有需要配置的选项，sudo apt install git一行命令装完即可。装完后建议执行git --version确认一下版本号。Ubuntu 22.04的软件源默认Git版本是2.34.x，这个版本对日常使用完全够用。

顺带提一下“小乌龟”——TortoiseGit。这是Windows上很有名的一个Git图形客户端，安装它之前必须先装好标准Git，否则它找不到可用的Git核心程序。如果你用不惯命令行，可以试试它，但我会建议还是优先把手动命令学起来，因为无论哪个图形客户端，底层都是那些命令，理解了命令就能理解图形界面在干什么，排查问题的时候也能看懂日志。

2.3 验证安装是否成功的两种方式

安装完成后，验证Git是否真正可用，我习惯分两步来检查。

第一步，打开CMD或PowerShell，输入git --version，如果能输出版本号，比如git version 2.45.0.windows.1，说明Git已经安装成功，并且已经加入PATH环境变量。如果提示“git不是内部或外部命令”，排除掉安装时没选对PATH选项的原因后，大概率是安装后没有重新打开终端窗口。Windows终端的环境变量是在启动时加载的，安装前打开的窗口里没有更新后的PATH，所以装完Git后一定要关掉所有旧终端，重新打开一个。

第二步，输入git config --list，看能否正常输出现有配置项。如果提示“fatal: unable to read config file”，那说明当前用户主目录下没有全局配置文件，这个不一定是异常，后面配置完用户名和邮箱后就会自动生成。

3. 安装后的基础配置：这步千万别跳过

3.1 配置用户名和邮箱：Git提交的第一道关卡

很多新手装完Git以后就急着建仓库、提交代码，结果提交记录里用户名永远是默认的“user”，邮箱是“user@localhost”，后面想改就麻烦了。这俩配置属于Git的“门面”，你的每一次提交都会带上它们，别人通过提交记录了解你，第一眼看到的就是这个。

配置命令非常简单：

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

加了--global参数后，这组配置会写入用户主目录下的.gitconfig文件，对当前系统下该用户的所有仓库生效。如果没有加--global，配置只会写入当前仓库的.git/config文件，只对当前仓库生效。一般来说，个人电脑上建议直接设成global级别的，省心。如果以后有某个仓库需要用到不同的身份，可以在那个仓库目录里单独执行不带--global的配置命令覆盖。

除了用户名和邮箱，还有两个配置建议顺手做好。一个是git config --global init.defaultBranch main，把默认分支名从master改成main。这个改动纯粹是出于命名习惯的更新，现在越来越多的新项目默认分支都叫main了，提前改好省得每次新建仓库都手动处理。另一个是git config --global core.autocrlf false（Windows用户如果之前选的是默认换行符选项，可以把这条也配上）。这个根据团队规范来，如果你一个人开发，把autocrlf设为false可以避免很多换行符相关的warning。

3.2 SSH配置与本地免密登录

SSH配置不是本地仓库创建的必需项，如果你只在自己电脑上提交，完全用不到SSH。但如果你想把本地仓库推到GitHub、GitLab或者其他远程仓库，配置SSH免密可以省掉每次输入用户名密码的麻烦。

配置SSH分四步：

检查是否已有SSH密钥：ls -al ~/.ssh，看有没有id_rsa和id_rsa.pub这对文件。
如果没有，生成新的密钥：ssh-keygen -t rsa -b 4096 -C "你的邮箱"。一路回车就好，生成的公钥在~/.ssh/id_rsa.pub里。
把公钥内容复制到代码托管平台的SSH Keys设置里。
测试连接：ssh -T git@github.com（如果是GitLab就换成git@gitlab.com）。看到Hi后面跟着你的用户名，说明配置成功。

注意：SSH密钥相当于一台电脑的“通行证”，私钥id_rsa千万不要泄露，也绝对不要提交到仓库里，否则别人拿着你的私钥就能以你的身份操作代码仓库。这一点再怎么强调都不为过。

3.3 与IDE联动的环境设置

如果你的开发主力是VS Code或IntelliJ IDEA，装完Git之后建议先在命令行里确认一遍基础命令都能用，然后再打开IDE进行关联设置。VS Code装好Git插件后，如果没有在PATH中找到git，会在源代码管理面板里提示“Git not found”，这时需要手动指定git.exe的路径。IDEA里的设置路径是“File - Settings - Version Control - Git”，这里填的Git executable path要指向实际安装目录。

另外，IDEA的Maven本地仓库优化和Git没有直接关系，但不少人在配环境的时候会把这两个混在一起。Maven本地仓库是存依赖jar包的目录，Git本地仓库是存项目代码版本的目录，这俩不要搞混。如果要用Gradle拉取本地Maven仓库里的包，也不是Git的职责，是构建工具本身的仓库配置问题。这里只是提醒一下，文章的核心还是Git。

4. 本地仓库创建：从git init到第一次提交

4.1 目录规划：不要随手建仓库

说句实在话，第一步我见过最多的问题不是命令不会敲，而是仓库建在了错误的地方。有人直接在C盘根目录初始化，有人把仓库建在系统临时目录里，还有人每建一个子目录就git init一次，最后嵌套了好几层仓库，自己都搞不清哪个仓库管哪块代码。

关于目录规划，我的建议是：在开始之前先建好一个清晰的项目目录结构，比如D:\Projects\demo-project（Windows）或~/Projects/demo-project（macOS/Linux），然后再在这个目录里初始化Git仓库。不要让仓库直接建在用户主目录或盘符根目录，这样会把大量无关文件纳入版本控制范围，导致Git运行缓慢且提交记录混乱。

如果你是在已有项目目录中初始化仓库，先看一下目录里的文件结构，删掉不必要的临时文件、编译产物（比如target、bin、node_modules等目录），再执行git init。新项目建议先创建.gitignore文件，把构建产物、IDE配置文件、系统文件等排除在版本管理之外，这样后续每次git status的结果都会很干净。

4.2 git init到底做了什么

在项目目录下执行git init之后，Git会在当前目录创建一个.git子目录。这个目录里存放的是Git仓库的核心数据，包括对象库、索引文件、日志记录等。可以用ls -a查看，会看到一个.git文件夹。这个文件夹就是仓库本体，项目里其他文件只是“工作区”内容。

这一点特别重要：删掉.git目录，仓库历史就没了；复制项目时忘了带.git目录，就等于复制了一份没有版本历史的普通文件。所以如果你想把仓库整个迁移到另一台机器，要么直接把整个项目目录（包含.git）打包带走，要么用git clone把仓库克隆过去。

Git仓库的工作流程可以理解为三个区：工作区（你实际编辑文件的地方）、暂存区（也称索引区，表示“打算提交的文件快照”）和版本库（历史提交记录）。git init创建好仓库后，这三块区域就都准备好了，只是现在仓库里还是空的，没有任何提交。

4.3 完整跑通第一次提交

假设有一个名为demo-project的目录，里面已经有了一个README.md文件。第一次提交的完整流程是：

bash复制cd ~/Projects/demo-project
git init
git status
git add README.md
git commit -m "初始化项目：添加README文档"

这五条命令我从头解释一下。

git init用于初始化仓库，输出“Initialized empty Git repository”就算成功。git status是查看当前状态，你会看到“No commits yet”和“Untracked files”这两段提示，README.md显示在“Untracked files”列表里，说明Git已经看到了这个文件，但还没有管理它。git add README.md把文件加入暂存区，此时文件从“Untracked”变成“Changes to be committed”。git commit -m "初始化项目：添加README文档"将暂存区的内容提交到版本库，生成一条提交记录。

如果目录里有多个文件需要提交，可以用git add .把当前目录下所有未跟踪文件都加进暂存区。但这里有一个前提：你的.gitignore文件已经配置好，否则会把不该提交的文件也卷进来。第一次提交前最好用git status再看一遍确认。

提交成功后，可以执行git log查看提交记录。你会看到一条类似“commit xxxxx（HEAD -> main or master）”的记录，后面跟着作者、日期和提交说明。到这一步，本地仓库就有了第一条提交，一个可用的Git仓库就算正式建好了。

4.4 提交规范：别让“update”刷屏

关于提交信息，我强烈建议从第一个提交开始就养成良好的习惯。热词里有一条“git提交规范”，说明很多人在意这个。这里给一个日常够用的提交信息模板：类型(scope): 描述。类型包括feat（新功能）、fix（修复bug）、docs（文档）、style（格式调整）、refactor（重构）、test（测试）等。比如feat(user): 新增用户登录接口、fix(cart): 修复购物车数量错乱问题。提交信息不要太长，但要让人一眼就知道这次改了什么。别写“update”“修复问题”这种说了等于没说的信息，过两个星期你再回头看，自己都不知道当时改了啥。

4.5 查看提交历史的三个常用命令

创建完仓库后，日常用得最多的三个查看命令是git status、git log和git diff。

git status用于查看工作区当前状态，会告诉你哪些文件被修改过、哪些文件在暂存区、哪些文件还没有被跟踪。git log用于查看提交历史，默认输出按时间倒序排列，每条记录包含提交哈希值、作者、日期和提交信息。如果觉得输出太详细，可以加--oneline参数，只显示一行摘要。git diff用于查看文件的具体改动内容，不加参数时显示工作区和暂存区的差异，加了--cached参数后显示暂存区和最近一次提交的差异。这三个命令配合使用，基本能应对日常开发中的绝大多数问题。

5. 本地仓库创建常见问题排查

5.1 “git不是内部或外部命令”的完整排查思路

这个报错在Windows下出现得最频繁，原因就一个：系统PATH环境变量里没有包含git.exe所在的目录。排查步骤按顺序来：

第一步，确认git.exe到底有没有安装。如果安装过程中报错或者中途取消，很可能根本没装成功，重新安装一次并确保走完所有步骤。第二步，找到git.exe的实际路径。默认情况下它是C:\Program Files\Git\cmd\git.exe，如果记不清，可以在开始菜单里搜索“Git Bash”，右键打开文件位置，然后一路找到cmd目录下的git.exe。第三步，把这个路径加到PATH环境变量中。右键“此电脑”进入“属性”，选择“高级系统设置”，点“环境变量”，在“系统变量”里找到Path，编辑并新增一行C:\Program Files\Git\cmd。第四步，重新打开CMD，输入git --version验证。

如果上面步骤都正常，还提示找不到git，大概率是你在安装时选了“Git from the command line only”，这个选项不会把Git加入系统PATH，只会让Git Bash内部可用。解决方式很简单：重新运行安装程序，在“Adjusting your PATH environment”这一步改成“Git from the command line and also from 3rd-party software”，然后完成安装。

5.2 “fatal: not a git repository (or any of the parent directories): .git”

这个报错的意思是当前目录或上级目录中找不到.git目录，也就是说你不在任何Git仓库里。常见场景是你在一个尚未执行git init的目录里执行了git add或git commit。解决办法就是先执行git init，或者切换到正确的仓库目录。还有一种情况是你在仓库的子目录里执行了git commit，正常情况下子目录也能向上找到仓库，但如果环境变量GIT_DIR被设置成了其他路径，就会出现这个报错，这种属于比较冷门的原因了，一般用不到排查这一步。

5.3 换行符警告与乱码问题

第一次在Windows上提交代码时，很多人在git add时会看到一行warning：LF will be replaced by CRLF。这是Git在按你的自动换行符策略做转换时的提示，不是错误，不影响提交。但如果团队里有不同系统的成员，建议在项目根目录加一个.gitattributes文件来统一规则，比如设置* text=auto、*.sh text eol=lf等，这样比全局配置更精细、更可控。

另外还有一个常见问题：git status里中文文件名显示成类似“\345\210\235\345\247\213”这样的转义序列。这是Git在输出非ASCII字符时默认做的转义处理，执行git config --global core.quotepath false就能解决，设置后中文文件名会正常显示。

5.4 不小心删了.git目录怎么办

这个属于主动作死型问题。如果仓库里的提交记录还没有推送到远程，那删除.git后，历史记录就彻底丢了。文件本身还在工作区，但所有提交历史、分支信息全都没了。解决办法是立刻停止对该目录的一切操作，然后找历史备份或远程仓库clone一份。如果连远程都没有，那就只能从头开始重新建仓库了。

所以，新建仓库后第一件事我建议就是立即把仓库推送到远程平台（GitHub、GitLab或公司内部的代码托管服务），这样即使本地环境出问题，代码和历史记录也不至于全军覆没。

6. 本地仓库日常使用：核心命令与避坑心得

6.1 日常开发必会的一组命令

仓库建好后，日常开发循环基本就是“改代码、看状态、暂存、提交”这四个动作。这里给出一整套日常命令，照着用就行：

bash复制# 拉取远程最新代码（如果有远程仓库）
git pull

# 查看工作区状态
git status

# 查看具体改动内容
git diff

# 把文件加入暂存区
git add 文件名或目录

# 提交到版本库
git commit -m "feat(模块): 提交说明"

# 推送到远程
git push

# 查看提交历史
git log --oneline

# 查看某次提交改了什么
git show 提交哈希值

# 撤销工作区改动
git restore 文件名

# 撤销暂存区的暂存状态
git restore --staged 文件名

# 合并分支
git merge 分支名

# 切换分支
git checkout 分支名或git switch 分支名

这里我要特别说一下git restore和git checkout的区别。git restore是Git 2.23版本新增的命令，专门用于恢复工作区或暂存区的文件，而git checkout承担的功能太多，既能切换分支又能撤销修改，对新手来说容易混淆。如果你用的是2.23以上的版本，建议有意识地用git switch切换分支、用git restore撤销修改，语义更清晰，不容易出错。搜索热词里也有“git restore”，说明不少人在这个命令上栽过跟头。

6.2 .gitignore的正确写法

.gitignore是绝大多数新手会忽略、但实际开发中非常重要的文件。它的作用就是告诉Git“下面这些文件不要纳入版本管理”。常见需要忽略的内容包括：构建输出目录（如dist、build、target）、依赖目录（如node_modules）、IDE配置文件（如.idea、.vscode）、系统文件（如.DS_Store、Thumbs.db）、日志文件和环境变量文件（如*.log、.env）。

一个简单的.gitignore文件长这样：

gitignore复制# 依赖目录
node_modules/
vendor/

# 构建产物
dist/
build/
target/

# IDE配置
.idea/
.vscode/
*.iml

# 系统文件
.DS_Store
Thumbs.db

# 日志与环境配置
*.log
.env

之所以要强调写好.gitignore，是因为我见过有人在第一次git add .时把node_modules整个目录提交进去了，几万个文件刷屏，仓库瞬间膨胀到几百MB。对于多人协作项目，这种失误会直接影响所有人的克隆和拉取速度。

6.3 结合IDE让日常操作更顺手

虽然我建议先掌握命令行，但在真实工作中，大多数人还是会用IDE的图形界面来操作Git。VS Code里安装Git相关插件后，源代码管理面板能看到改动文件列表、输入提交信息、一键提交和推送，非常直观。但有一个坑需要提醒：VS Code插件在提交时有时会调用一个自动生成的git命令来显示提交差异，比如git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status。这个命令本身没问题，但如果你在配置里禁用了某些core选项，可能会导致该命令报错。遇到这种情况，最稳妥的排查方法是：在命令行里手动执行同样的命令，看是否能跑通，如果能，就是IDE侧的问题，重启IDE通常能解决。

IntelliJ IDEA的Git集成同样很成熟，可以在“Version Control”窗口里操作分支、提交、推送和合并。但IDEA的Git仓库识别也是基于.git目录的，如果项目目录下没有.git，或者仓库结构被改动过，IDEA会识别不到。这种情况下检查一下项目目录里是否真的有.git文件夹即可。

6.4 我踩过的几个坑

最后分享几个我在实际使用中踩过的坑，每一个都是真金白银换来的教训。

第一个坑：在项目根目录执行git add .之前没写.gitignore，把带有数据库连接信息的配置文件提交上去了。后来推送到远程仓库，配置里的账号密码直接暴露，虽然项目不大，但也够让人心跳加速的。从那以后我养成了一个习惯：第一次git add之前一定先看一遍git status，确认没有敏感文件，并把.gitignore写好。

第二个坑：提交信息写得过于简略。早期我提交的时候直接写“fix bug”，过了一两个月想找某次修改，靠git log翻了好久都找不到对应记录，只能按时间猜。后来我严格执行“类型(模块): 描述”的格式，回查历史变得非常轻松。

第三个坑：换行符问题导致文件被整行标记为改动。有一次在Windows上打开一个原本在Linux上编辑的文件，换行符从LF变成了CRLF，git diff一看，整个文件所有行都显示被修改了。这种情况非常让人摸不着头脑，后来通过git config core.autocrlf配置和.gitattributes规则才彻底解决。

第四个坑：把仓库建在了项目目录的上一级，导致后续在项目子目录里操作时发现Git管了太多不该管的文件。这种问题没有太好的修复办法，最省事的做法就是删掉错误的.git目录，在正确的项目目录里重新git init。

6.5 本地仓库创建的完整自查清单

文章最后，我用一个自查清单帮大家确认自己的Git环境是否顺手，本地仓库是否建得规范：

执行git --version能正常输出版本号。
git config --global user.name和git config --global user.email已经设置，且指向正确的身份。
执行git config --global core.autocrlf false（按需）。
项目的.gitignore已经创建，git status输出中没有垃圾文件。
项目目录下只有一层.git目录，不存在仓库嵌套。
至少完成了一次git commit，git log --oneline能看到提交记录。
如果打算推送远程仓库，SSH密钥已经配好，并且能通过ssh -T测试。
换行符相关配置明确，提交时看不到奇怪的warning。

如果你照着上面这些步骤把每一条都过了一遍，那你的Git基础环境就算搭好了，本地仓库也建得比较规范了。后面再遇到问题，大概率就不是环境层面的问题，而是操作层面的了。

我个人在实际操作中的体会是：Git这东西，配置一次能管很多年，但前几次的配置决定了很多后续体验。环境装好、仓库建好只是第一步，真正重要的是培养一种“带着状态管理思维”去写代码的习惯——随时知道自己改了什么、提交了什么、历史里有什么。这个习惯养成以后，Git才会真正变成一个让你舒服的工具，而不是经常跳出来吓你的拦路虎。

最后再分享一个小技巧：新建完本地仓库并完成第一次提交之后，可以先在本地建一个分支、合并一次再删掉，把这个流程完整走一遍。很多人第一次操作分支就是在项目紧急时候，压力之下很容易出问题，提前演练一次就不怕了。Git的命令不怕多敲，只怕不敲。