Git 日记

学习日记草稿打卡，内容分析来自于 deekseep,仅学习记录。

Vscode

安装 Git

• 确保你的电脑上已经安装了 Git。你可以从 Git 官网 下载并安装。
• 安装后，打开终端（或 Git Bash），设置你的用户名和邮箱，这将是你的提交记录标识：
  bash
  git config --global user.name "你的用户名" git config --global user.email "你的邮箱@example.com"
• 初始化仓库
  • 对于新项目：在 VS Code 中打开你的项目文件夹，然后按 Ctrl+Shift+P（或 Cmd+Shift+P on Mac）打开命令面板，输入并选择 Git: Initialize Repository。
  • 对于现有项目：如果你的文件夹已经是一个 Git 仓库（包含 .git 文件夹），VS Code 会自动检测到。

认识 VS Code 中的 Git 界面

完成初始化后，你会看到左侧活动栏有一个源代码管理图标（分支形状）。点击它，主界面会分为几个部分：

• A. 更改（Changes）：这里列出了所有已修改但尚未暂存的文件。

• B. 暂存的更改（Staged Changes）：这里列出了已暂存、准备提交的文件。

• C. 提交按钮和消息框：在这里输入提交信息并执行提交操作。

• D. 分支状态和更多操作：显示当前分支名，并可以展开进行更多操作（如拉取、推送、分支管理等）。

基本工作流程

这是一个标准的 Git 工作流在 VS Code 中的实现。

1. 修改文件

当你对项目中的文件进行修改（创建、编辑、删除）后，这些文件会出现在 "更改" 区域。

• M：表示已修改。

• U：表示未跟踪（新文件）。

• D：表示已删除。

2. 暂存更改（Staging）

暂存相当于告诉 Git："我准备要提交这些文件的这些改动了"。

• 暂存单个文件 ：将鼠标悬停在文件上，点击出现的 "+" 号。

• 暂存所有更改 ：点击 "更改" 区域上方的 "+" 号。

• 暂存部分代码块/行 ：点击文件右侧的对比视图 ，在代码行号旁边点击 "+" 号，可以只暂存某几行的改动。这是非常强大的功能！

暂存后的文件会从 "更改" 区域移动到 "暂存的更改" 区域。

提交（Commit）

• 在顶部的输入框（消息框）中，输入有意义的提交信息，描述这次修改的内容。

• 按 Ctrl+Enter（Windows/Linux）或 Cmd+Enter（Mac）进行提交。

• 你也可以点击消息框旁边的 "..." 菜单，选择 "提交并同步" ，这个操作会依次执行 commit -> pull -> push，非常高效。

4. 推送（Push）到远程仓库

提交只是将改动保存在了本地仓库。要与团队共享，需要推送到远程仓库（如 GitHub, GitLab）。

• 如果你的本地分支已经设置了上游分支，提交后左下角的状态栏会显示一个同步图标（云朵状，带上下箭头），点击它即可完成推送和拉取。

• 你也可以点击 "..." 菜单，选择 "推送"。

分支与标签操作菜单

点击顶部分支名称（例如 master）旁边的展开箭头，会弹出这个菜单，用于管理分支和标签。

• 打开更改：打开所有已修改文件的列表。

• 签出：切换到另一个已有的分支。

• 签出(已分离)：切换到某一次特定的提交，进入"分离头指针"状态（通常用于临时查看历史版本，不推荐在此状态下进行新开发）。

• 创建分支...：基于当前状态创建一个新的分支。这是开始新功能开发或修复 Bug 时的标准操作。

• 删除分支：删除指定的本地分支。

• 创建标记... ：为当前提交创建一个标签（Tag），通常用于标记发布版本（如 v1.0.0）。

• 挑拣：将另一个分支的某一次特定提交，复制到当前分支。

• 拉取

  • 功能 ：从你当前分支所关联的远程仓库下载最新代码并合并到本地 。等同于 git pull。

  • 使用场景 ：每天开始工作前，或团队成员推送了新代码后，用它来更新你的本地代码。（非常常用）

• 抓取

  • 功能 ：从远程仓库下载所有最新的提交历史和信息 ，但不会自动合并 到你的工作区。等同于 git fetch。

  • 使用场景：你想看看远程仓库有没有更新，但又不确定是否要立即合并到自己的代码里。比"拉取"更安全，因为它允许你先审查变化再手动合并。

• 签出到...

  • 功能 ：切换分支。你可以快速切换到另一个已有分支，或基于当前状态创建一个新分支。

  • 使用场景 ：开始开发新功能前创建新分支，或修复 Bug 时需要切换到其他分支。（非常常用）

• 存储

  • 功能 ：暂存你的临时修改 。把你当前未提交的更改临时保存起来，让工作区恢复到干净状态，之后可以再重新应用这些更改。等同于 git stash。

  • 使用场景 ：当你正在修改一个功能时，突然需要紧急切换到另一个分支去修复一个 Bug。（非常实用）

提交选项菜单：高级操作

点击 "提交"按钮 右侧的小箭头，会展开这个菜单，提供更多提交方式。

• 提交：与主按钮功能完全相同。

• 提交(修改) ：这个选项用于修改上一次的提交 。它会将当前已暂存的更改，合并到上一次的提交中，并允许你修改上一次的提交信息。注意：这会重写历史，如果提交已推送，可能会造成混乱。

• 提交和推送 ：强烈推荐使用。这个操作会依次执行两个命令：

  1. git commit（提交到本地仓库）

  2. git push（推送到远程仓库，如 Gitee）

     这是一个非常高效的一次性操作。

• 提交和同步：这是一个更强大的操作，它依次执行三个命令：

  1. git commit（提交）

  2. git pull（拉取远程最新代码，确保没有冲突）

  3. git push（推送）

     在团队协作中，这可以确保你的推送不会因为本地版本落后而失败。

实战案例

当前代码开发是 基于 dev 主线 建立分支 abc ,目前在长期在分支abc 上进行开发，完成后再合并到 dev 主线上，应该如何操作

VS Code 中的操作：

1. 点击左下角分支名，先选择 dev 进行切换。

2. 点击 ... 菜单，选择 拉取，拉取远程最新 dev。

3. 再次点击左下角分支名，切换回 abc。

4. 点击 ... 菜单，选择 合并分支...，然后选择 dev。

第2步：日常开发与提交

在你的 abc 分支上进行编码，这是你的安全沙盒。

• 频繁提交：在 VS Code 的源代码管理面板中，经常提交你的更改。提交信息要清晰，例如"添加用户登录API"、"修复首页样式错位"。

• 推送备份 ：定期将你的 abc 分支推送到远程仓库（如 Gitee），这既是备份，也便于在其他设备上继续工作。

功能完成 - 发起合并请求

当 abc 分支的功能全部开发完成，并准备集成到 dev 时。

1. 最后一遍合并 dev 到 abc ：重复第1步的操作，确保 abc 是基于最新的 dev。这一步至关重要，它能把合并冲突解决在你的分支上，而不是污染 dev 主线。

2. 推送最终版 abc 分支：

   bash

git push origin abc

• 创建 Pull Request：

  • 访问你的 Gitee 仓库页面。

  • 通常会有提示让你为刚推送的 abc 分支创建 Pull Request。

  • 在创建时，源分支 选择 abc，目标分支 选择 dev。

  • 在 PR 描述中清晰说明本次修改的内容、测试情况等。

代码审查与合并

• 代码审查：团队其他成员在 Gitee 的 PR 页面上审查你的代码，提出意见。

• 修改 ：如果有需要修改的地方，你直接在本地 abc 分支上修改，然后再次提交并推送。PR 会自动更新。

• 合并 ：审查通过后，由你或项目负责人将 PR 合并到 dev。在 Gitee 上通常有"合并"按钮，建议选择 "创建合并提交" 或 " squash 合并"，以保持历史清晰。

Pycharm

选项一："将传入更改合并到当前分支"

• 这是什么意思？ ：这是标准的 git pull 操作，相当于 git fetch + git merge。它会将远程的最新更改（传入更改）和你本地的更改进行一次合并。

• 会产生什么结果？ ：如果存在冲突，你需要手动解决，并且最终会生成一个新的"合并提交"。这个提交有两个父节点，记录了这次合并行为。

• 优点：

  • 保留了完整的项目历史，包括合并的时间点和上下文。

  • 是 Git 的默认行为，非常标准。

• 缺点：

  • 如果团队非常频繁地拉取代码，提交历史中会出现大量的合并提交记录，可能会让历史图看起来有些"杂乱"。

• 适用场景：

  • 大多数情况下，这都是一个安全且推荐的选择。

  • 当你本地也有新的提交，并且你希望保留"合并"这一事实时。

选项二："在传入更改上重放当前分支"

• 这是什么意思？ ：这实际上是 git pull --rebase 操作，相当于 git fetch + git rebase。它会先"取下"你本地的所有新提交，暂存起来，然后将你的本地分支更新到和远程一模一样，最后再把你的新提交**"重新播放"**在最前面。

• 会产生什么结果？ ：你的所有本地提交都会被移动到这个项目历史的最顶端，从而形成一条直线式的、非常整洁的历史线。不会产生额外的合并提交。

• 优点：

  • 项目历史是一条直线，非常清晰易懂。

  • 避免了不必要的合并提交。

• 缺点：

  • 重写了历史：对于新手来说，这个概念有点绕。

  • 如果操作不当，可能会带来一些复杂性。

  • 如果你的分支是公共的（已经推送过并被其他人使用），不推荐使用 rebase。

• 适用场景：

  • 你正在一个个人功能分支上开发，还没有推送过你的本地提交。

  • 你希望保持一个干净利落的提交历史。

Gitee

Gitee 如何线上 创建 合并请求

• 进入合并请求页面

  • 在仓库导航栏中，点击 "Pull Requests" 标签页

  • 点击 "+ 新建 Pull Request" 按钮

• 设置合并分支

  • 源分支 ：选择 abc（您想要合并的分支）

  • 目标分支 ：选择 dev（要合并到的分支）

  • 确保分支选择正确，Gitee 会显示两个分支之间的差异

• 填写合并请求信息

  • 标题：清晰描述这个合并请求的目的，例如："将 abc 分支功能合并到 dev"

  • 描述：详细说明：

    • 这个合并包含哪些修改

    • 解决了什么问题

    • 是否有需要注意的地方

    • 可以关联相关任务或Issue

合并方式说明

Gitee 提供三种合并方式，创建后管理员可以选择：

合并方式	说明	适用场景
Merge	创建合并提交，保留完整历史	推荐用于重要功能合并
Squash	压缩成一个提交	整理提交历史，保持整洁
Rebase	变基合并，线性历史	需要清晰线性历史时