Git 的使用教程 | 豆包MarsCode AI刷题

一、基本配置与初始化

1. 用户信息配置

   • 在开始使用 Git 前，需要配置好用户的基本信息，包括用户名和邮箱地址，因为这些信息会被记录在每一次提交中，方便后续追踪代码的提交者。使用以下命令进行配置：

git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

• 这里的--global参数表示全局配置，适用于该用户在这台机器上所有的 Git 仓库。如果只想针对某个特定仓库配置，可以进入相应仓库目录，去掉--global参数进行配置。

2. 仓库初始化

   • 若要创建一个新的 Git 仓库，可以在项目所在的目录下执行git init命令，这会在该目录下生成一个隐藏的.git文件夹，里面包含了 Git 仓库管理版本控制所需的所有信息，如提交记录、分支信息等。
   • 另外，如果是从已有的远程仓库（比如在 GitHub、GitLab 等代码托管平台上的项目）克隆到本地，使用git clone [远程仓库地址]命令，例如：git clone https://github.com/username/project.git，这样就可以把远程仓库完整地复制到本地，方便后续操作。

二、日常开发中的使用

1. 文件状态查看与暂存区管理

   • 在开发过程中，经常需要了解文件的状态，可以通过git status命令查看。它会显示哪些文件是新增的、修改过的，以及哪些文件已经被添加到暂存区等信息。
   • 当修改了一些文件后，若想将这些修改纳入下一次提交的范围，需要先把文件添加到暂存区，使用git add [文件路径或文件名]命令。例如，git add main.py就是将main.py这个文件添加到暂存区；如果想添加所有修改过的文件，可以使用git add.命令（注意这里的.表示当前目录下的所有文件）。

2. 提交代码

   • 把文件添加到暂存区后，就可以进行代码提交了，使用git commit -m "提交说明"命令，其中"提交说明"部分要简洁明了地描述这次提交所做的更改内容，比如git commit -m "修复登录页面的用户名验证漏洞"。好的提交说明有助于后续查看版本历史时快速理解每次提交的意义，方便代码回溯和问题排查。
   • 建议遵循一定的提交规范，例如采用类似 Angular 团队的提交规范格式：type(scope): subject，type可以是feat（新功能）、fix（修复 bug）、docs（文档修改）等，scope描述影响的范围，subject是简短的描述内容。这样可以让提交历史更加清晰、有条理。

3. 分支管理

   • 创建分支：在开发新功能或者修复 bug 时，最好基于主分支（通常是master或者main分支）创建新的分支，使用git branch [分支名称]命令，比如git branch feature-login就是创建一个名为feature-login的分支用于开发登录功能。
   • 切换分支：创建好分支后，需要切换到该分支进行开发，使用git checkout [分支名称]命令，例如git checkout feature-login就切换到了刚创建的登录功能分支上。也可以使用git checkout -b [分支名称]命令来合并创建和切换分支这两个步骤，更加便捷。
   • 合并分支：当分支上的功能开发完成或者 bug 修复后，需要把分支合并回主分支或者其他目标分支。通常先切换到目标分支（如master），然后使用git merge [要合并的分支名称]命令，例如git merge feature-login就把feature-login分支的内容合并到了master分支上。合并过程中可能会遇到冲突，需要手动解决冲突后再继续合并操作，解决冲突时要仔细对比不同分支上对同一处代码的修改，选择合适的保留或修改方式，然后再提交合并后的结果。

三、团队协作中的最佳实践

1. 远程仓库设置与同步

   • 团队协作一般会有一个远程仓库作为代码的集中存储和共享平台（如 GitHub、GitLab 等）。要关联本地仓库和远程仓库，使用git remote add origin [远程仓库地址]命令，这里的origin是远程仓库的默认别名，可以自定义其他别名，但通常使用origin。例如，git remote add origin https://github.com/teamname/project.git。
   • 当团队成员对远程仓库有新的提交后，本地仓库需要进行同步更新，使用git pull origin [分支名称]命令，比如git pull origin master就是拉取远程master分支的最新内容到本地对应的分支上，这样可以保证本地仓库的代码始终与团队其他成员的工作保持同步，避免出现代码冲突和不一致的情况。

2. 代码审查与协作流程

   • 创建合并请求（Pull Request 或 Merge Request） ：在完成分支上的开发后，不是直接合并到主分支，而是向主分支发起一个合并请求。在代码托管平台（如 GitHub 的 Pull Request、GitLab 的 Merge Request）上按照流程填写相关信息，如本次更改的详细描述、关联的任务或问题编号等，方便团队其他成员进行代码审查。
   • 代码审查（Code Review） ：团队成员（一般是经验更丰富或者负责相关模块的同事）会对提交的合并请求进行代码审查，审查内容包括代码的逻辑正确性、是否符合编码规范、有没有潜在的安全隐患等。审查者可以在平台上直接添加评论，指出需要修改的地方，开发者根据反馈意见进行相应的修改，修改完成后再次提交，直到代码审查通过，这样可以提高代码质量，减少错误进入主分支的概率。
   • 遵循分支保护规则：在远程仓库设置中，可以配置分支保护规则，比如规定只有经过代码审查且满足一定条件（如至少有一位指定的审核人通过）的合并请求才能合并到主分支，强制保障主分支的代码质量和稳定性。

3. 处理冲突的协作

   • 当多个团队成员同时修改了同一处代码，在合并分支时就可能出现冲突。遇到冲突时，首先要及时沟通，了解各个成员修改的意图和背景，确定最佳的解决方案。
   • 然后在本地手动解决冲突，Git 会在冲突的文件中标记出不同分支的修改内容，通常用<<<<<<<、=======、>>>>>>>这些符号来区分，开发者需要根据实际情况选择保留哪些内容、修改哪些内容，解决完冲突后，再通过git add和git commit命令提交解决冲突后的结果，继续进行合并操作。

四、版本控制的最佳实践

1. 定期打标签（Tag）

   • 对于项目中的重要版本、里程碑式的发布节点，可以通过打标签的方式进行标记，方便后续随时回溯到特定版本。使用git tag -a [标签名称] -m "标签说明"命令，例如git tag -a v1.0 -m "首个正式版本发布"，这里的-a表示创建一个带注释的标签，-m后面跟着对标签的说明文字。
   • 标签可以帮助在项目需要回滚到某个历史版本或者查看特定阶段的代码状态时，快速准确地定位，比如出现严重问题需要回退到上一个稳定版本时，直接根据标签进行版本切换即可。

2. 使用 Git 日志与可视化工具

   • 查看 Git 日志：通过git log命令可以查看项目的提交历史，了解不同阶段的代码变更情况，它会显示每次提交的作者、日期、提交说明以及对应的哈希值等信息。还可以添加一些参数来定制查看的效果，比如git log --oneline可以以简洁的一行形式展示每次提交，方便快速浏览提交历史；git log --graph可以以图形化的方式展示分支的合并、分叉等情况，更直观地呈现版本控制的结构。
   • 使用可视化工具：除了命令行查看日志，还可以使用一些 Git 的可视化工具，如 GitKraken、SourceTree 等，这些工具能够以更直观的界面展示仓库的版本信息、分支结构、提交历史等内容，对于复杂的项目和不太熟悉命令行操作的团队成员来说，更容易理解和操作 Git 相关的工作流程，辅助进行版本控制和团队协作。

3. 备份与恢复策略

   • 定期备份仓库：无论是本地仓库还是远程仓库，都应该有定期备份的计划，防止因意外情况（如硬盘损坏、服务器故障等）导致代码丢失。对于本地仓库，可以定期将整个.git文件夹复制到外部存储设备或者其他安全的位置；对于远程仓库，很多代码托管平台本身会有数据备份机制，但也可以考虑定期导出仓库数据到本地进行额外备份。
   • 掌握恢复方法：了解如何从备份中恢复仓库以及在出现误操作（如错误删除分支、误提交等）时如何进行回滚和恢复操作。例如，如果误删除了一个分支，可以通过git reflog命令查看操作记录，找到对应分支的哈希值，再通过git branch [分支名称] [哈希值]命令来恢复分支；如果想回滚到某个历史提交，可以使用git reset --hard [哈希值]命令（注意这种方式会丢弃当前分支上在该历史提交之后的所有修改，要谨慎使用）。