Git是目前使用最广泛的分布式版本控制系统，由Linus Torvalds开发，最初用于管理Linux内核代码。与依赖中央服务器的集中式工具不同，Git在每个开发者本地都保存完整仓库和版本历史，这让提交、回滚、分支切换等操作非常快速，也能在离线状态下继续工作。开始使用Git并不需要把所有命令背下来，关键是把安装配置、核心概念、日常提交流程和分支操作串成一条清晰路径。
接下来，本文会从Git的作用、安装与初始配置讲起，再解释工作区、暂存区和本地仓库的关系，最后给出从创建仓库到分支合并的实操步骤以及常见避坑建议。
一、Git是什么以及为什么需要版本控制
版本控制的核心目的是记录文件的修改历史，让开发者可以随时查看某个文件在过去哪个时间点被谁修改过，也可以把文件恢复到之前的任意状态。如果没有版本控制，我们往往会手动复制文件夹，出现“项目最终版”“项目最终版2”“项目真正最终版”这样的混乱局面。当功能越改越多，想找回几天前删除的代码会非常困难。
Git采用分布式架构，每个参与者clone仓库时都会得到完整的历史记录。这意味着即使远程服务器不可用，本地仍然可以提交、查看日志、创建分支。Git还通过快照方式保存文件状态，未修改的文件不会重复存储，效率很高。相比SVN等集中式工具，Git的分支创建和合并成本极低，这鼓励开发者频繁使用分支隔离功能开发，从而降低代码冲突风险。
无论是个人学习笔记、小型脚本，还是大型团队协作项目，Git都能提供清晰的修改轨迹。理解这一点后，再动手安装配置会更有方向感。
二、安装Git与初始配置
安装Git前需要确认操作系统。Windows用户可在Git官方站点下载安装包，安装时大部分选项保持默认即可，但建议在编辑器选择步骤中把默认编辑器改为自己熟悉的工具，例如Visual Studio Code。macOS用户可以通过Homebrew安装，命令为brew install git；Linux用户则使用系统包管理器，例如Ubuntu的sudo apt install git。
安装完成后，打开终端或命令提示符，输入git --version查看版本号。如果正确显示版本信息，说明Git已可用。第一次使用前必须配置用户姓名和邮箱，因为每次提交都会记录这两个信息。配置命令如下：git config --global user.name "你的名字"和git config --global user.email "你的邮箱"。注意这里使用的是全局配置，保存在用户目录下的.gitconfig文件中，Windows路径通常为C:\Users\用户名\.gitconfig。如需为某个项目单独设置身份，可在项目目录下使用不带--global的相同命令。
还可以配置命令别名提高效率，例如把git checkout简写为git co，把git status简写为git st。别名的配置可以写在.gitconfig中，也可以用命令git config --global alias.co checkout完成。配置完成后，可以开始理解Git的核心区域。
三、核心概念：工作区、暂存区与本地仓库
Git把文件流转划分为三个主要区域。工作区就是当前项目目录里能直接看到的文件和文件夹，你对文件的增删改都发生在工作区。暂存区是一个中间层，用来决定哪些修改会进入下一次提交。本地仓库保存提交历史，每次commit都会生成一个快照，并带有一个唯一的哈希值作为标识。
可以用一个简单流程理解：文件在工作区修改后，通过git add命令放入暂存区，再通过git commit命令把暂存区内容永久记录到本地仓库。工作区与暂存区之间可以反复调整，提交前还可以用git diff查看尚未暂存的修改，或用git diff --cached查看暂存区与上次提交的差异。
这种设计的好处是灵活控制提交粒度。比如你同时修改了三个文件，但其中两个属于功能A，一个属于功能B，就可以只把功能A的两个文件add进暂存区并提交，功能B的文件留到下一次提交。这样提交历史会非常清晰，便于以后追踪问题。
| 区域 | 作用 | 常用操作 |
|---|---|---|
| 工作区 | 当前可见文件，修改直接发生 | 编辑、新建、删除文件 |
| 暂存区 | 暂存准备提交的修改 | git add、git reset |
| 本地仓库 | 保存提交历史和版本快照 | git commit、git log |
四、从零开始：创建仓库与首次提交
进入项目目录后，运行git init命令会创建一个名为.git的隐藏文件夹，其中包含Git跟踪版本所需的全部元数据。此时目录就成为一个本地仓库，但还没有任何提交记录。如果是从远程仓库获取已有项目，则应使用git clone命令加仓库地址，这样会自动下载完整历史并配置远程关联。
首次提交前，建议先创建.gitignore文件，把不需要纳入版本控制的文件或目录列进去，例如编译产物、日志文件、依赖目录、环境配置文件等。这样能避免把大文件或敏感信息提交到仓库。.gitignore的语法比较简单，每行一个模式，星号表示通配，斜杠/表示目录。例如要忽略node_modules目录，可以写node_modules/；忽略所有日志文件可以写*.log。
然后按顺序执行：git add .将当前目录所有修改加入暂存区，或使用git add 文件名添加指定文件；git commit -m "首次提交"创建第一个提交。提交信息应尽量写清楚本次改动内容，避免使用“更新”“修改”这类模糊描述。完成后可以用git log查看提交历史，用git status查看当前工作区状态。
如果需要关联远程仓库，可以运行git remote add origin 仓库地址，然后git push -u origin main推送本地提交。注意新仓库默认分支可能是master或main，可根据远程平台要求调整。
五、日常高频操作与分支管理
日常开发中最常用的命令包括git status、git add、git commit、git pull、git push、git diff和git log。git status可以随时查看哪些文件被修改、哪些已暂存，是最安全的命令之一；git pull用于从远程拉取最新代码并合并到本地；git push用于把本地提交推送到远程。
分支是Git最强大的功能之一。默认分支通常为main或master，代表稳定的主线版本。开发新功能时，应先创建独立分支，例如git branch feature-login创建一个名为feature-login的分支，再通过git checkout feature-login切换过去。也可以使用git switch命令，语义更直观。在分支上完成开发和提交后，切回主分支并运行git merge feature-login合并。合并完成后可删除该分支：git branch -d feature-login。
多人协作时，合并冲突不可避免。冲突通常发生在两人同时修改同一文件的同一行区域。出现冲突时，Git会标记冲突文件内容，需要手动编辑文件解决冲突，再执行git add和git commit完成合并。不要直接丢弃他人改动，应结合上下文判断保留哪部分或整合双方逻辑。频繁拉取远程更新、保持分支粒度小，是减少冲突的有效方式。
六、常见问题与避坑建议
第一个常见问题是忘记配置用户信息就提交，导致提交历史显示为系统默认名或乱码。解决方法是检查git config user.name和git config user.email，如果未配置则补齐，并可以用git commit --amend --reset-author修正最近一次提交的作者信息。
第二个常见问题是提交粒度过大。一次提交包含多个不相关功能，会让历史难以查看和回滚。应尽量保持一次提交只做一件事，并写清楚提交信息。比如“添加登录表单校验”比“改了一些东西”有用得多。
第三个问题是误把敏感文件提交到仓库。密码、密钥、配置中的数据库地址等一旦提交就会留在历史记录中，即使后续删除，仍可通过历史版本找回。因此应在提交前用.gitignore排除敏感文件。如果已经提交，不要只删除文件，还需要考虑清理历史或立即更换密钥。
第四个问题是合并冲突处理不当。很多人遇到冲突后直接选择保留自己的版本，导致他人修改丢失。正确做法是打开冲突文件，理解双方改动，逐处合并，然后运行测试确认。如果对合并结果不确定，可以先创建备份分支再操作。
第五个问题是忽略分支策略。直接在main或master上开发并提交，容易造成主线不稳定。建议团队约定简单的分支流程，例如main只接受经过测试的合并，功能开发在feature分支进行，发布前使用release分支。对于个人项目，至少也应把实验性改动放在单独分支，避免污染主线。
最后，定期推送本地提交到远程仓库是一种备份习惯。本地磁盘损坏或误删目录时，远程仓库可以作为恢复来源。不要等到功能全部完成才推送，完成一个可用阶段就可以提交并推送。
开始使用Git进行版本控制并不需要一次掌握所有高级命令。理解工作区、暂存区、本地仓库三层关系，熟练使用status、add、commit、branch、merge等基础操作，再配合良好的提交习惯和分支策略，就可以在日常开发中获得巨大收益。遇到问题时，先查看git status和git log了解当前状态，再针对性解决，往往能避免误操作。随着使用深入，可以逐步学习rebase、cherry-pick、stash等进阶技巧，让版本管理更加高效。