尧图网站建设 
1. 从“版本管理”到“团队协作”为什么每个开发者都绕不开Git如果你刚开始接触编程或者刚从学校进入公司项目组听到最多的词里一定有“Git”。它可能出现在“代码提交一下”、“拉一下最新代码”、“你分支合并冲突了”这些日常对话里。很多人第一次接触Git尤其是在Windows环境下感觉就像在操作一个黑盒一堆命令敲下去文件状态变来变去一不小心就把别人的代码搞乱了或者自己的修改不见了。这种感觉非常正常因为Git的设计哲学和传统的文件管理方式比如直接复制粘贴、用网盘同步完全不同。简单来说Git是一个分布式版本控制系统。这个名词听起来有点唬人我们拆开来看。“版本控制”意味着它能帮你记录文件主要是代码的每一次改动你可以随时回到任何一个历史版本就像游戏存档一样。“分布式”是Git最核心、也最反直觉的特性。它意味着你电脑上的本地仓库就拥有项目的完整历史不依赖于某个中央服务器。这带来的好处是你可以在断网的情况下继续工作、提交代码、查看历史提交代码到服务器只是一个“同步”操作而不是“保存”操作这大大提升了安全性和灵活性。在Windows上使用Git你通常会遇到两个选择原生的Git for Windows也叫git-scm和集成在GitHub Desktop等图形化工具里的Git。这篇内容会以前者为主因为它是最通用、最接近Git本质的工具掌握了它你就能理解任何图形化工具背后的原理。我们将从零开始手把手完成安装、基础配置并通过一个完整的模拟团队协作案例让你彻底明白git init、git add、git commit、git push、git pull、git branch这些命令到底在做什么以及如何避免那些常见的“坑”。2. 在Windows上安装Git选对版本避开第一个坑安装是第一步但这里的选择会直接影响后续的使用体验。我们不推荐使用某些“绿色版”或“破解版”直接从官方或可信渠道获取是最稳妥的。2.1 官方下载与版本选择最权威的下载地址是Git官方网站git-scm.com。进入下载页面你会看到一个很大的“Download for Windows”按钮。点击后会自动开始下载安装程序。目前以当前普遍环境为例稳定版是Git for Windows 2.x系列。这里有一个关键选择32-bit还是64-bit除非你的Windows系统是非常老的32位系统现在已极为罕见否则一律选择64-bit版本。它能更好地利用现代计算机的内存和处理器性能。下载得到的通常是一个名为类似Git-2.44.0-64-bit.exe的安装文件。注意国内访问官方网站有时可能速度较慢。如果遇到困难也可以考虑从一些国内知名的开源镜像站下载但务必核对文件的哈希值如SHA256确保文件未被篡改。这是保证开发环境安全的第一步。2.2 安装过程中的关键配置选项运行安装程序后你会看到一系列配置页面。大部分可以保持默认但以下几项需要特别留意选择组件Select ComponentsGit Bash Here和Git GUI Here务必勾选。这会在你的文件资源管理器右键菜单中添加这两个选项非常方便。Git Bash是一个模拟Linux终端的环境是使用Git命令的主要场所。Git LFS (Large File Support)如果你未来可能会处理大型文件如图片、模型、数据集建议安装。它可以更高效地管理大文件。Associate .git* configuration files with the default text editor关联.gitconfig等配置文件用默认文本编辑器打开可选。选择默认编辑器Choosing the default editor used by Git默认是Vim。对于新手来说Vim的学习曲线非常陡峭保存退出都需要按:wq然后回车。强烈建议将其改为你熟悉的编辑器例如Nano一个简单的终端编辑器或者选择Use Visual Studio Code as Git‘s default editor如果你安装了VSCode。这能避免你第一次提交时卡在编辑器里不知所措。调整PATH环境Adjusting your PATH environment推荐选择Git from the command line and also from 3rd-party software。这个选项会将Git的可执行文件添加到系统的PATH环境变量中。这意味着你不仅可以在Git Bash里使用Git命令还可以在Windows自带的命令提示符CMD或PowerShell里直接使用git命令兼容性最好。选择HTTPS传输后端Choosing HTTPS transport backend保持默认的Use the OpenSSL library即可。它负责处理Git与远程仓库如GitHub、Gitee通过HTTPS协议通信时的加密。配置行尾符号转换Configuring the line ending conversions这是Windows用户最容易出问题的地方也是导致文件换行符混乱CRLF vs LF的根源。必须选择Checkout Windows-style, commit Unix-style line endings。它的作用是当你从仓库拉取代码checkout时Git会自动将LFLinux/Unix/macOS风格换行符转换为CRLFWindows风格当你提交代码时Git又会自动将CRLF转换回LF。这样保证了仓库内代码风格统一LF同时在你的Windows本地编辑时又是正常的CRLF。如果团队混用不同系统这个设置至关重要。配置终端模拟器Configuring the terminal emulator选择Use MinTTY (the default terminal of MSYS2)。MinTTY是Git Bash使用的终端它比Windows默认的控制台ConHost功能更强大支持复制粘贴鼠标选中即复制右键粘贴、更好的字体渲染等。完成这些配置后一路点击“Next”直到安装完成。安装结束后你可以在开始菜单找到“Git”文件夹里面包含Git Bash、Git GUI和Git CMD。2.3 验证安装与基础配置安装完成后我们需要验证并做一些最基础的全局配置。打开Git Bash在开始菜单或桌面上找到Git Bash并打开。你会看到一个黑底或白底的终端窗口命令行提示符通常是用户名电脑名 MINGW64 ~表示你当前在用户主目录~下。验证安装输入以下命令如果显示Git版本号说明安装成功。git --version配置用户信息这是使用Git前必须做的第一步。Git的每次提交都会记录作者信息。在Git Bash中执行以下两条命令将邮箱和用户名替换成你自己的通常使用你GitHub/Gitee等平台的注册邮箱和用户名。git config --global user.email your_emailexample.com git config --global user.name Your Name--global参数表示这是全局配置对这台电脑上所有的Git仓库生效。信息会保存在C:\Users\你的用户名\.gitconfig文件中。可选检查配置你可以用以下命令查看所有的全局配置。git config --global --list你应该能看到刚才设置的user.email和user.name。至此Git的环境就准备好了。接下来我们进入核心部分理解Git的工作流程。3. 理解Git的核心工作区、暂存区与仓库很多新手觉得Git命令难记根本原因是没理解Git管理文件的“三区”模型。这是Git设计的精髓理解了它命令就不再是死记硬背的咒语。想象你正在写一份报告工作区Working Directory就是你电脑上直接能看到、能编辑的那个文件夹。你在这里增删改查文件。暂存区Staging Area / Index这是一个非常关键的“缓存区域”。当你觉得报告中的某个章节写好了你可以先把它“标记”起来准备放入最终版本。这个“标记”的动作就是把文件放入暂存区。暂存区允许你精细控制哪些修改要进入下一次提交。仓库Repository尤其是本地仓库Local Repo位于你项目根目录下的隐藏文件夹.git里。当你觉得所有“标记”好的修改可以形成一个有意义的、可回溯的节点时你就执行“提交”这时暂存区的内容就会被永久保存到仓库的历史记录中生成一个唯一的“提交记录”Commit。为什么需要暂存区这提供了巨大的灵活性。比如你同时修改了文件A和文件B但这次提交只想包含文件A的修改因为文件B还没改完。你可以只把文件A加入暂存区然后提交。文件B的修改则保留在工作区不影响本次提交。没有暂存区的版本控制系统你只能选择提交所有修改或不提交很不方便。基本命令与三区的关系git add file将工作区中指定文件的当前修改添加到暂存区。git commit -m “message”将暂存区的所有内容作为一个新的版本快照提交到本地仓库。-m后面是本次提交的说明务必写清楚。git status查看当前工作区、暂存区的状态。这是你最常用的命令之一它能告诉你哪些文件被修改了、哪些已暂存、哪些未被跟踪。git log查看本地仓库的提交历史。我们用一个小例子来串一下这个过程。在桌面或任意位置新建一个文件夹my-git-demo右键选择Git Bash Here。# 1. 初始化一个新的Git仓库 git init # 这时当前目录下会生成一个隐藏的 .git 文件夹本地仓库建立。 # 2. 创建一个新文件并查看状态 echo “Hello Git” readme.txt git status # 输出会显示 Untracked files: readme.txt表示Git发现了一个新文件但还没开始跟踪它。 # 3. 将文件添加到暂存区 git add readme.txt git status # 输出会显示 Changes to be committed: new file: readme.txt表示readme.txt已在暂存区等待提交。 # 4. 提交到本地仓库 git commit -m “Add readme.txt with initial greeting” git status # 输出显示 nothing to commit, working tree clean。工作区和暂存区都干净了修改已安全存入仓库。 git log # 你会看到一条提交记录包含提交哈希值、作者、时间和你写的提交信息。这个过程就是Git最基础的本地工作流。接下来我们要引入更强大的功能分支。4. 分支管理团队并行开发的基石分支是Git的“杀手级”功能。你可以把分支想象成一条独立的时间线。默认情况下Git会创建一个叫main旧版本可能是master的主分支。你可以从主分支上创建新的分支在新分支上开发新功能、修复bug而不会影响主分支的稳定性。开发完成后再将新分支合并回主分支。为什么用分支假设你要开发一个“用户登录”功能。如果你直接在main分支上改代码改到一半发现一个紧急bug需要修复你会非常尴尬提交吧功能没做完不提交吧没法干净地切回去修bug。有了分支你可以从main创建新分支feature-login。在feature-login上安心开发登录功能。突然线上有bug立即切换回main分支创建另一个分支hotfix-bug去修复。修复完成后将hotfix-bug合并回main并部署。切换回feature-login继续开发完全不受影响。基础分支命令git branch列出所有本地分支当前分支前会标有*号。git branch branch-name创建一个新分支。git checkout branch-name切换到指定分支。git checkout -b branch-name创建并立即切换到新分支常用组合命令。git merge branch-name将指定分支合并到当前分支。git branch -d branch-name删除已合并的分支。让我们在之前的例子上继续操作模拟一个功能开发场景# 假设我们当前在 main 分支readme.txt 已提交。 # 1. 创建并切换到开发登录功能的分支 git checkout -b feature-login # 2. 在新分支上工作修改文件 echo “- User login feature (WIP)” readme.txt git add readme.txt git commit -m “Start working on login feature” # 3. 模拟一个紧急修复先切回main分支 git checkout main # 4. 创建并切换到热修复分支 git checkout -b hotfix-typo # 修改文件修复一个拼写错误假设 echo “This is the main branch.” main-feature.txt git add main-feature.txt git commit -m “Fix typo in main feature description” # 5. 将热修复合并到main分支 git checkout main git merge hotfix-typo # 因为hotfix-typo是直接从main分出去的且main在分出去后没有新提交这通常是一次“快进合并”非常顺利。 # 6. 删除已合并的热修复分支 git branch -d hotfix-typo # 7. 回到登录功能分支继续开发 git checkout feature-login # 此时你在feature-login分支上看不到hotfix-typo分支的修改因为还没合并可以继续独立开发。这个流程展示了分支如何让多线任务并行不悖。最后当feature-login开发完成后我们需要将其合并回main这就可能遇到Git中最经典的问题合并冲突。5. 远程协作与冲突解决从本地到团队到目前为止我们都在本地操作。真正的团队协作需要一个大家都能访问的“中央”仓库如GitHub、Gitee、GitLab虽然Git是分布式的但这个远程仓库通常作为大家同步代码的约定交点。5.1 连接远程仓库我们以GitHub为例国内用户也可用Gitee操作几乎完全相同。在GitHub上创建新仓库登录GitHub点击“New repository”。仓库名设为my-git-demo可与本地不同选择Public或Private千万不要勾选“Initialize this repository with a README”因为我们本地已有内容。点击创建。将本地仓库与远程仓库关联创建后GitHub会显示一个仓库地址HTTPS或SSH。在本地my-git-demo目录的Git Bash中执行git remote add origin https://github.com/你的用户名/my-git-demo.gitorigin是给这个远程仓库起的一个别名习惯上用origin。首次推送代码到远程git push -u origin mainpush命令将本地分支的提交推送到远程仓库。-u参数是--set-upstream的简写它建立了本地main分支与远程origin/main分支的追踪关系。设置好后以后在这个分支上只需要用git push即可。现在你的代码就托管在GitHub上了。团队其他成员可以通过git clone 仓库地址将代码下载到他们的本地。5.2 模拟团队协作与合并冲突冲突发生在两个分支对同一文件的同一部分进行了不同的修改并且Git无法自动决定该保留哪一个。我们来亲手制造并解决一个冲突。场景你和同事都在main分支的readme.txt文件末尾添加了一行内容并且各自先提交到了本地然后尝试推送到远程。你先推送成功# 假设你本地main分支的readme.txt最后一行是“Line A” echo “Line A” readme.txt git add readme.txt git commit -m “Add line A” git push origin main # 成功推送到远程同事在你之后提交但推送前没有拉取你的更新 我们在本地模拟同事的操作需要先“忘记”远程的最新状态# 我们先假装回到推送前的状态在本地创建一个“同事”的提交 # 使用 git reset 回退一步仅用于演示日常慎用 git reset --hard HEAD~1 # 回退到上一个提交这步操作后你的“Line A”提交在本地历史中暂时消失了。 # 现在模拟同事的修改他加了“Line B” echo “Line B” readme.txt git add readme.txt git commit -m “Add line B”同事尝试推送但被拒绝git push origin main你会看到错误提示! [rejected] main - main (fetch first)。意思是远程仓库的main分支已经有了你推送的“Line A”提交而同事本地的main分支历史与远程不一致缺少“Line A”提交因此被拒绝。解决之道先拉取再合并 同事需要先把你提交的代码拉取下来与自己的修改合并。git pull origin mainpull命令相当于git fetch获取远程更新 git merge合并到当前分支。 执行后Git会尝试自动合并但因为你们两个修改了同一文件的相近位置自动合并失败提示CONFLICT (content)。手动解决冲突 此时运行git status会显示both modified: readme.txt。 打开readme.txt文件你会看到类似这样的内容Hello Git - User login feature (WIP) HEAD Line B Line A xxxxxx (某个提交哈希值) HEAD到之间是当前分支同事的本地分支的内容Line B。到之间是拉取下来的远程分支你推送的的内容Line A。 Git把选择权交给了你。你需要手动编辑这个文件决定最终内容。比如你想要保留两者Hello Git - User login feature (WIP) Line A Line B或者只保留一个或者修改成其他内容。编辑完成后保存文件。标记冲突已解决并完成合并# 将解决冲突后的文件添加到暂存区告诉Git冲突已处理 git add readme.txt # 完成合并提交 git commit -m “Merge branch ‘main‘ of ... into main, resolving conflict” # 此时本地仓库已经包含了“Line A”和“Line B”两个修改以及一个合并提交。 # 最后推送合并后的结果到远程 git push origin main至此一次完整的冲突解决流程就完成了。关键在于在推送前总是先拉取最新的远程代码git pull在本地处理好可能的冲突然后再推送。养成这个习惯能避免很多协作问题。6. 日常高效工作流与实用技巧掌握了基础概念和命令后一套高效的日常流程能让你事半功倍。下面是一个常见的单人/团队开发流程建议开始新功能前确保本地main分支是最新的。git checkout main git pull origin main创建功能分支基于最新的main创建。git checkout -b feature/your-feature-name建议使用清晰的分支命名如feature/login-page、bugfix/crash-on-startup。在功能分支上开发进行多次小颗粒度的提交。# 多次 add 和 commit git add . git commit -m “feat: add user input validation” git commit -m “fix: correct button color”提交信息尽量规范可以参考类似“Angular提交规范”用前缀如feat:、fix:、docs:、style:、refactor:等。同步主分支变更如果开发时间较长期间main分支可能有更新。可以定期将main的更新合并到你的功能分支减少最终合并时的冲突。git checkout main git pull origin main git checkout feature/your-feature-name git merge main # 处理可能出现的冲突功能完成准备合并最后拉取一次最新的main并合并到功能分支处理冲突。在本地确保代码测试通过。将功能分支推送到远程仓库。git push origin feature/your-feature-name发起合并请求Pull Request / Merge Request在GitHub/Gitee等平台界面上对你的功能分支发起一个PR/MR。这是一个代码审查流程团队成员可以评论你的代码。这是保证代码质量的重要环节。合并与清理PR被审核通过后在平台上将其合并到main分支。然后回到本地切换到main分支拉取最新的包含你功能的代码并删除已经合并的本地和远程功能分支。git checkout main git pull origin main git branch -d feature/your-feature-name git push origin --delete feature/your-feature-name # 删除远程分支几个必备的实用技巧与命令git diff查看工作区与暂存区git diff、或暂存区与仓库git diff --staged之间的具体修改内容。解决冲突时非常有用。git log --oneline --graph --all以简洁的单行格式、图形化方式查看所有分支的历史非常直观。.gitignore文件在项目根目录创建这个文件里面写上你不想被Git跟踪的文件或文件夹模式如编译产物node_modules/、*.log、IDE配置文件.idea/等。Git会自动忽略它们。这是保持仓库清洁的关键。撤销操作git checkout -- file丢弃工作区中对某个文件的修改危险操作谨慎使用。git reset HEAD file将已添加到暂存区的文件移回工作区取消暂存。git commit --amend修改最近一次提交的提交信息或者将暂存区的新修改追加到上一次提交不会产生新的提交记录。储藏更改git stash当你正在一个分支上工作需要临时切换到另一个分支处理急事但当前修改又没完成不想提交。可以用git stash将工作区和暂存区的修改“储藏”起来让工作区变干净。处理完急事后用git stash pop恢复储藏的内容。7. 图形化工具辅助并非替代而是增强虽然命令行是理解Git的根本但图形化工具GUI在某些场景下能极大提升效率比如可视化分支历史、解决冲突、查看文件差异等。VS Code内置的Git工具非常强大。左侧源代码管理图标或CtrlShiftG可以直观地看到文件变更状态、进行暂存、提交、推送、拉取等操作。其内置的差异对比和合并冲突解决工具也很好用。GitHub Desktop / GitKraken / Sourcetree这些是独立的Git GUI客户端。它们提供了更丰富的可视化界面来管理分支、查看提交网络图。对于复杂的分支合并操作看图操作比记命令更直观。我的建议是初学者先从命令行开始强迫自己理解“三区”和基本命令。在熟悉了核心概念后再使用GUI工具来提高日常操作的效率。两者结合使用是最好的状态。当你用GUI点了一个按钮时你心里应该清楚它在背后执行了哪条或哪几条Git命令这样你才能真正掌控你的版本库。最后关于Windows环境的一个小贴士如果你在Git Bash中操作文件路径时遇到空格或中文问题可以用英文引号将路径括起来或者使用Tab键自动补全。对于复杂的项目保持目录和文件名尽量使用英文和数字能避免很多不必要的麻烦。Git本身对中文支持很好但某些外围工具或脚本可能会因为编码问题出错。 Git入门指南：从零掌握分布式版本控制与团队协作
1. 从“版本管理”到“团队协作”为什么每个开发者都绕不开Git如果你刚开始接触编程或者刚从学校进入公司项目组听到最多的词里一定有“Git”。它可能出现在“代码提交一下”、“拉一下最新代码”、“你分支合并冲突了”这些日常对话里。很多人第一次接触Git尤其是在Windows环境下感觉就像在操作一个黑盒一堆命令敲下去文件状态变来变去一不小心就把别人的代码搞乱了或者自己的修改不见了。这种感觉非常正常因为Git的设计哲学和传统的文件管理方式比如直接复制粘贴、用网盘同步完全不同。简单来说Git是一个分布式版本控制系统。这个名词听起来有点唬人我们拆开来看。“版本控制”意味着它能帮你记录文件主要是代码的每一次改动你可以随时回到任何一个历史版本就像游戏存档一样。“分布式”是Git最核心、也最反直觉的特性。它意味着你电脑上的本地仓库就拥有项目的完整历史不依赖于某个中央服务器。这带来的好处是你可以在断网的情况下继续工作、提交代码、查看历史提交代码到服务器只是一个“同步”操作而不是“保存”操作这大大提升了安全性和灵活性。在Windows上使用Git你通常会遇到两个选择原生的Git for Windows也叫git-scm和集成在GitHub Desktop等图形化工具里的Git。这篇内容会以前者为主因为它是最通用、最接近Git本质的工具掌握了它你就能理解任何图形化工具背后的原理。我们将从零开始手把手完成安装、基础配置并通过一个完整的模拟团队协作案例让你彻底明白git init、git add、git commit、git push、git pull、git branch这些命令到底在做什么以及如何避免那些常见的“坑”。2. 在Windows上安装Git选对版本避开第一个坑安装是第一步但这里的选择会直接影响后续的使用体验。我们不推荐使用某些“绿色版”或“破解版”直接从官方或可信渠道获取是最稳妥的。2.1 官方下载与版本选择最权威的下载地址是Git官方网站git-scm.com。进入下载页面你会看到一个很大的“Download for Windows”按钮。点击后会自动开始下载安装程序。目前以当前普遍环境为例稳定版是Git for Windows 2.x系列。这里有一个关键选择32-bit还是64-bit除非你的Windows系统是非常老的32位系统现在已极为罕见否则一律选择64-bit版本。它能更好地利用现代计算机的内存和处理器性能。下载得到的通常是一个名为类似Git-2.44.0-64-bit.exe的安装文件。注意国内访问官方网站有时可能速度较慢。如果遇到困难也可以考虑从一些国内知名的开源镜像站下载但务必核对文件的哈希值如SHA256确保文件未被篡改。这是保证开发环境安全的第一步。2.2 安装过程中的关键配置选项运行安装程序后你会看到一系列配置页面。大部分可以保持默认但以下几项需要特别留意选择组件Select ComponentsGit Bash Here和Git GUI Here务必勾选。这会在你的文件资源管理器右键菜单中添加这两个选项非常方便。Git Bash是一个模拟Linux终端的环境是使用Git命令的主要场所。Git LFS (Large File Support)如果你未来可能会处理大型文件如图片、模型、数据集建议安装。它可以更高效地管理大文件。Associate .git* configuration files with the default text editor关联.gitconfig等配置文件用默认文本编辑器打开可选。选择默认编辑器Choosing the default editor used by Git默认是Vim。对于新手来说Vim的学习曲线非常陡峭保存退出都需要按:wq然后回车。强烈建议将其改为你熟悉的编辑器例如Nano一个简单的终端编辑器或者选择Use Visual Studio Code as Git‘s default editor如果你安装了VSCode。这能避免你第一次提交时卡在编辑器里不知所措。调整PATH环境Adjusting your PATH environment推荐选择Git from the command line and also from 3rd-party software。这个选项会将Git的可执行文件添加到系统的PATH环境变量中。这意味着你不仅可以在Git Bash里使用Git命令还可以在Windows自带的命令提示符CMD或PowerShell里直接使用git命令兼容性最好。选择HTTPS传输后端Choosing HTTPS transport backend保持默认的Use the OpenSSL library即可。它负责处理Git与远程仓库如GitHub、Gitee通过HTTPS协议通信时的加密。配置行尾符号转换Configuring the line ending conversions这是Windows用户最容易出问题的地方也是导致文件换行符混乱CRLF vs LF的根源。必须选择Checkout Windows-style, commit Unix-style line endings。它的作用是当你从仓库拉取代码checkout时Git会自动将LFLinux/Unix/macOS风格换行符转换为CRLFWindows风格当你提交代码时Git又会自动将CRLF转换回LF。这样保证了仓库内代码风格统一LF同时在你的Windows本地编辑时又是正常的CRLF。如果团队混用不同系统这个设置至关重要。配置终端模拟器Configuring the terminal emulator选择Use MinTTY (the default terminal of MSYS2)。MinTTY是Git Bash使用的终端它比Windows默认的控制台ConHost功能更强大支持复制粘贴鼠标选中即复制右键粘贴、更好的字体渲染等。完成这些配置后一路点击“Next”直到安装完成。安装结束后你可以在开始菜单找到“Git”文件夹里面包含Git Bash、Git GUI和Git CMD。2.3 验证安装与基础配置安装完成后我们需要验证并做一些最基础的全局配置。打开Git Bash在开始菜单或桌面上找到Git Bash并打开。你会看到一个黑底或白底的终端窗口命令行提示符通常是用户名电脑名 MINGW64 ~表示你当前在用户主目录~下。验证安装输入以下命令如果显示Git版本号说明安装成功。git --version配置用户信息这是使用Git前必须做的第一步。Git的每次提交都会记录作者信息。在Git Bash中执行以下两条命令将邮箱和用户名替换成你自己的通常使用你GitHub/Gitee等平台的注册邮箱和用户名。git config --global user.email your_emailexample.com git config --global user.name Your Name--global参数表示这是全局配置对这台电脑上所有的Git仓库生效。信息会保存在C:\Users\你的用户名\.gitconfig文件中。可选检查配置你可以用以下命令查看所有的全局配置。git config --global --list你应该能看到刚才设置的user.email和user.name。至此Git的环境就准备好了。接下来我们进入核心部分理解Git的工作流程。3. 理解Git的核心工作区、暂存区与仓库很多新手觉得Git命令难记根本原因是没理解Git管理文件的“三区”模型。这是Git设计的精髓理解了它命令就不再是死记硬背的咒语。想象你正在写一份报告工作区Working Directory就是你电脑上直接能看到、能编辑的那个文件夹。你在这里增删改查文件。暂存区Staging Area / Index这是一个非常关键的“缓存区域”。当你觉得报告中的某个章节写好了你可以先把它“标记”起来准备放入最终版本。这个“标记”的动作就是把文件放入暂存区。暂存区允许你精细控制哪些修改要进入下一次提交。仓库Repository尤其是本地仓库Local Repo位于你项目根目录下的隐藏文件夹.git里。当你觉得所有“标记”好的修改可以形成一个有意义的、可回溯的节点时你就执行“提交”这时暂存区的内容就会被永久保存到仓库的历史记录中生成一个唯一的“提交记录”Commit。为什么需要暂存区这提供了巨大的灵活性。比如你同时修改了文件A和文件B但这次提交只想包含文件A的修改因为文件B还没改完。你可以只把文件A加入暂存区然后提交。文件B的修改则保留在工作区不影响本次提交。没有暂存区的版本控制系统你只能选择提交所有修改或不提交很不方便。基本命令与三区的关系git add file将工作区中指定文件的当前修改添加到暂存区。git commit -m “message”将暂存区的所有内容作为一个新的版本快照提交到本地仓库。-m后面是本次提交的说明务必写清楚。git status查看当前工作区、暂存区的状态。这是你最常用的命令之一它能告诉你哪些文件被修改了、哪些已暂存、哪些未被跟踪。git log查看本地仓库的提交历史。我们用一个小例子来串一下这个过程。在桌面或任意位置新建一个文件夹my-git-demo右键选择Git Bash Here。# 1. 初始化一个新的Git仓库 git init # 这时当前目录下会生成一个隐藏的 .git 文件夹本地仓库建立。 # 2. 创建一个新文件并查看状态 echo “Hello Git” readme.txt git status # 输出会显示 Untracked files: readme.txt表示Git发现了一个新文件但还没开始跟踪它。 # 3. 将文件添加到暂存区 git add readme.txt git status # 输出会显示 Changes to be committed: new file: readme.txt表示readme.txt已在暂存区等待提交。 # 4. 提交到本地仓库 git commit -m “Add readme.txt with initial greeting” git status # 输出显示 nothing to commit, working tree clean。工作区和暂存区都干净了修改已安全存入仓库。 git log # 你会看到一条提交记录包含提交哈希值、作者、时间和你写的提交信息。这个过程就是Git最基础的本地工作流。接下来我们要引入更强大的功能分支。4. 分支管理团队并行开发的基石分支是Git的“杀手级”功能。你可以把分支想象成一条独立的时间线。默认情况下Git会创建一个叫main旧版本可能是master的主分支。你可以从主分支上创建新的分支在新分支上开发新功能、修复bug而不会影响主分支的稳定性。开发完成后再将新分支合并回主分支。为什么用分支假设你要开发一个“用户登录”功能。如果你直接在main分支上改代码改到一半发现一个紧急bug需要修复你会非常尴尬提交吧功能没做完不提交吧没法干净地切回去修bug。有了分支你可以从main创建新分支feature-login。在feature-login上安心开发登录功能。突然线上有bug立即切换回main分支创建另一个分支hotfix-bug去修复。修复完成后将hotfix-bug合并回main并部署。切换回feature-login继续开发完全不受影响。基础分支命令git branch列出所有本地分支当前分支前会标有*号。git branch branch-name创建一个新分支。git checkout branch-name切换到指定分支。git checkout -b branch-name创建并立即切换到新分支常用组合命令。git merge branch-name将指定分支合并到当前分支。git branch -d branch-name删除已合并的分支。让我们在之前的例子上继续操作模拟一个功能开发场景# 假设我们当前在 main 分支readme.txt 已提交。 # 1. 创建并切换到开发登录功能的分支 git checkout -b feature-login # 2. 在新分支上工作修改文件 echo “- User login feature (WIP)” readme.txt git add readme.txt git commit -m “Start working on login feature” # 3. 模拟一个紧急修复先切回main分支 git checkout main # 4. 创建并切换到热修复分支 git checkout -b hotfix-typo # 修改文件修复一个拼写错误假设 echo “This is the main branch.” main-feature.txt git add main-feature.txt git commit -m “Fix typo in main feature description” # 5. 将热修复合并到main分支 git checkout main git merge hotfix-typo # 因为hotfix-typo是直接从main分出去的且main在分出去后没有新提交这通常是一次“快进合并”非常顺利。 # 6. 删除已合并的热修复分支 git branch -d hotfix-typo # 7. 回到登录功能分支继续开发 git checkout feature-login # 此时你在feature-login分支上看不到hotfix-typo分支的修改因为还没合并可以继续独立开发。这个流程展示了分支如何让多线任务并行不悖。最后当feature-login开发完成后我们需要将其合并回main这就可能遇到Git中最经典的问题合并冲突。5. 远程协作与冲突解决从本地到团队到目前为止我们都在本地操作。真正的团队协作需要一个大家都能访问的“中央”仓库如GitHub、Gitee、GitLab虽然Git是分布式的但这个远程仓库通常作为大家同步代码的约定交点。5.1 连接远程仓库我们以GitHub为例国内用户也可用Gitee操作几乎完全相同。在GitHub上创建新仓库登录GitHub点击“New repository”。仓库名设为my-git-demo可与本地不同选择Public或Private千万不要勾选“Initialize this repository with a README”因为我们本地已有内容。点击创建。将本地仓库与远程仓库关联创建后GitHub会显示一个仓库地址HTTPS或SSH。在本地my-git-demo目录的Git Bash中执行git remote add origin https://github.com/你的用户名/my-git-demo.gitorigin是给这个远程仓库起的一个别名习惯上用origin。首次推送代码到远程git push -u origin mainpush命令将本地分支的提交推送到远程仓库。-u参数是--set-upstream的简写它建立了本地main分支与远程origin/main分支的追踪关系。设置好后以后在这个分支上只需要用git push即可。现在你的代码就托管在GitHub上了。团队其他成员可以通过git clone 仓库地址将代码下载到他们的本地。5.2 模拟团队协作与合并冲突冲突发生在两个分支对同一文件的同一部分进行了不同的修改并且Git无法自动决定该保留哪一个。我们来亲手制造并解决一个冲突。场景你和同事都在main分支的readme.txt文件末尾添加了一行内容并且各自先提交到了本地然后尝试推送到远程。你先推送成功# 假设你本地main分支的readme.txt最后一行是“Line A” echo “Line A” readme.txt git add readme.txt git commit -m “Add line A” git push origin main # 成功推送到远程同事在你之后提交但推送前没有拉取你的更新 我们在本地模拟同事的操作需要先“忘记”远程的最新状态# 我们先假装回到推送前的状态在本地创建一个“同事”的提交 # 使用 git reset 回退一步仅用于演示日常慎用 git reset --hard HEAD~1 # 回退到上一个提交这步操作后你的“Line A”提交在本地历史中暂时消失了。 # 现在模拟同事的修改他加了“Line B” echo “Line B” readme.txt git add readme.txt git commit -m “Add line B”同事尝试推送但被拒绝git push origin main你会看到错误提示! [rejected] main - main (fetch first)。意思是远程仓库的main分支已经有了你推送的“Line A”提交而同事本地的main分支历史与远程不一致缺少“Line A”提交因此被拒绝。解决之道先拉取再合并 同事需要先把你提交的代码拉取下来与自己的修改合并。git pull origin mainpull命令相当于git fetch获取远程更新 git merge合并到当前分支。 执行后Git会尝试自动合并但因为你们两个修改了同一文件的相近位置自动合并失败提示CONFLICT (content)。手动解决冲突 此时运行git status会显示both modified: readme.txt。 打开readme.txt文件你会看到类似这样的内容Hello Git - User login feature (WIP) HEAD Line B Line A xxxxxx (某个提交哈希值) HEAD到之间是当前分支同事的本地分支的内容Line B。到之间是拉取下来的远程分支你推送的的内容Line A。 Git把选择权交给了你。你需要手动编辑这个文件决定最终内容。比如你想要保留两者Hello Git - User login feature (WIP) Line A Line B或者只保留一个或者修改成其他内容。编辑完成后保存文件。标记冲突已解决并完成合并# 将解决冲突后的文件添加到暂存区告诉Git冲突已处理 git add readme.txt # 完成合并提交 git commit -m “Merge branch ‘main‘ of ... into main, resolving conflict” # 此时本地仓库已经包含了“Line A”和“Line B”两个修改以及一个合并提交。 # 最后推送合并后的结果到远程 git push origin main至此一次完整的冲突解决流程就完成了。关键在于在推送前总是先拉取最新的远程代码git pull在本地处理好可能的冲突然后再推送。养成这个习惯能避免很多协作问题。6. 日常高效工作流与实用技巧掌握了基础概念和命令后一套高效的日常流程能让你事半功倍。下面是一个常见的单人/团队开发流程建议开始新功能前确保本地main分支是最新的。git checkout main git pull origin main创建功能分支基于最新的main创建。git checkout -b feature/your-feature-name建议使用清晰的分支命名如feature/login-page、bugfix/crash-on-startup。在功能分支上开发进行多次小颗粒度的提交。# 多次 add 和 commit git add . git commit -m “feat: add user input validation” git commit -m “fix: correct button color”提交信息尽量规范可以参考类似“Angular提交规范”用前缀如feat:、fix:、docs:、style:、refactor:等。同步主分支变更如果开发时间较长期间main分支可能有更新。可以定期将main的更新合并到你的功能分支减少最终合并时的冲突。git checkout main git pull origin main git checkout feature/your-feature-name git merge main # 处理可能出现的冲突功能完成准备合并最后拉取一次最新的main并合并到功能分支处理冲突。在本地确保代码测试通过。将功能分支推送到远程仓库。git push origin feature/your-feature-name发起合并请求Pull Request / Merge Request在GitHub/Gitee等平台界面上对你的功能分支发起一个PR/MR。这是一个代码审查流程团队成员可以评论你的代码。这是保证代码质量的重要环节。合并与清理PR被审核通过后在平台上将其合并到main分支。然后回到本地切换到main分支拉取最新的包含你功能的代码并删除已经合并的本地和远程功能分支。git checkout main git pull origin main git branch -d feature/your-feature-name git push origin --delete feature/your-feature-name # 删除远程分支几个必备的实用技巧与命令git diff查看工作区与暂存区git diff、或暂存区与仓库git diff --staged之间的具体修改内容。解决冲突时非常有用。git log --oneline --graph --all以简洁的单行格式、图形化方式查看所有分支的历史非常直观。.gitignore文件在项目根目录创建这个文件里面写上你不想被Git跟踪的文件或文件夹模式如编译产物node_modules/、*.log、IDE配置文件.idea/等。Git会自动忽略它们。这是保持仓库清洁的关键。撤销操作git checkout -- file丢弃工作区中对某个文件的修改危险操作谨慎使用。git reset HEAD file将已添加到暂存区的文件移回工作区取消暂存。git commit --amend修改最近一次提交的提交信息或者将暂存区的新修改追加到上一次提交不会产生新的提交记录。储藏更改git stash当你正在一个分支上工作需要临时切换到另一个分支处理急事但当前修改又没完成不想提交。可以用git stash将工作区和暂存区的修改“储藏”起来让工作区变干净。处理完急事后用git stash pop恢复储藏的内容。7. 图形化工具辅助并非替代而是增强虽然命令行是理解Git的根本但图形化工具GUI在某些场景下能极大提升效率比如可视化分支历史、解决冲突、查看文件差异等。VS Code内置的Git工具非常强大。左侧源代码管理图标或CtrlShiftG可以直观地看到文件变更状态、进行暂存、提交、推送、拉取等操作。其内置的差异对比和合并冲突解决工具也很好用。GitHub Desktop / GitKraken / Sourcetree这些是独立的Git GUI客户端。它们提供了更丰富的可视化界面来管理分支、查看提交网络图。对于复杂的分支合并操作看图操作比记命令更直观。我的建议是初学者先从命令行开始强迫自己理解“三区”和基本命令。在熟悉了核心概念后再使用GUI工具来提高日常操作的效率。两者结合使用是最好的状态。当你用GUI点了一个按钮时你心里应该清楚它在背后执行了哪条或哪几条Git命令这样你才能真正掌控你的版本库。最后关于Windows环境的一个小贴士如果你在Git Bash中操作文件路径时遇到空格或中文问题可以用英文引号将路径括起来或者使用Tab键自动补全。对于复杂的项目保持目录和文件名尽量使用英文和数字能避免很多不必要的麻烦。Git本身对中文支持很好但某些外围工具或脚本可能会因为编码问题出错。