本文汇总了熟悉 Git 基本工作流程后常会遇到的三个主题：如何创建 repository（通过 git init 或 IDE）、rebase 与 merge 有何区别，以及如何妥善移除意外进入历史记录的秘密信息。这些内容也适用于使用 Claude Code 的场景，因为它会通过命令执行这些操作，您需要了解命令背后的含义。

示例和界面截图基于 JetBrains IDE；操作名称和位置可能因您使用的版本而异。练习时请另建一个学习用的 repository。在实际项目中，请遵循项目的分支、提交和推送规则。

创建 repository - git init 或通过 IDE

如果项目已经在 GitHub 上，您可以克隆它。另一种情况是，您手头有一个包含代码的本地文件夹。git init 会在其中创建 Git 的内部数据，但不会创建第一个 commit。下面的示例假定 README.md 和 .gitignore 已创建并检查过；其他需要的文件再单独添加。

git init
git status
# 检查 README 和忽略规则后
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

在 IDE 中创建本地 repository 时，请使用创建 Git repository 或启用版本控制的操作。Share Project on GitHub 是另一种独立流程：它还会创建远程 repository，并提供推送选项。推送前，请检查选中的文件、历史记录和可见性。

Kotlin

Public 还是 private

创建 repository 时，您需要选择其可见性：

  • public - repository 对所有互联网用户可见，任何人都能查看代码。适合作品集和 open source 项目；
  • private - 只有您和受邀者可以访问。对于不应公开的工作和练习代码，这是默认选择。

可见性并非一成不变：您之后可以在 GitHub 的 repository 设置中修改。

与 Claude Code 的联系

Claude Code 可以替您运行 git init 并准备第一个 commit。如果 GitHub 上还没有 repository，它也可以通过 GitHub CLI（gh repo create）创建一个；届时由您决定将其设为 public 还是 private。

rebase 与 merge 有何区别

merge 和 rebase 都能把一个分支上的工作整合到另一个分支，但实现方式不同，因此项目历史的呈现也会不同。

merge 会合并历史。如果两条历史线已经分叉，通常会创建一个有两个父 commit 的 merge commit。如果当前分支是另一个分支的祖先，Git 可以执行 fast-forward，而不创建新 commit。下图展示的是分叉的情况。

上方是 main，下方是 feature。合并后，main 指向 M，而 M 有两个父节点：E 和 D。ABEMCD
上方是 main，下方是 feature。合并后，main 指向 M，而 M 有两个父节点：E 和 D。

merge 保留两条历史线并添加 merge commit，因此可以清楚看到当时有一个独立的 feature 分支。

rebase 会移动您的 commit，让它们看起来像是在目标分支的最新节点上开始开发。历史会变成一条线性链。不过这也有代价：rebase 会改写您的 commit，旧 commit 会被具有不同哈希的新 commit 替代。

main 分支指向 E，rebase 后的 feature 分支指向新的 D2。图中未显示 B 之前的共同历史。BEC2D2
main 分支指向 E，rebase 后的 feature 分支指向新的 D2。图中未显示 B 之前的共同历史。

rebase 后，C 和 D 看起来像是在 E 之上创建的：历史变成了线性结构，但它们已经是哈希不同的新 commit（C2、D2）。

该选哪种方式？

  • merge - 适用于需要保留真实历史或分支由多人共用的情况。这是稳妥的默认选择；
  • rebase - 在创建 pull request 前整理自己的个人分支时使用，线性历史更容易阅读。
请注意

熟悉 rebase 期间，请只在自己尚未发布的分支上使用它。其他人已经在使用的分支，只有经过协商并按约定流程才能改写，否则同事手里仍会保留旧历史。如果不确定后果，请先停下来确认项目规则。

请注意

如何整合分支取决于任务和项目规则。不要假设智能体会选择某种默认方式；执行前，请让它说明目标分支、操作方式以及对历史的影响。

从 repository 历史中移除秘密信息

在新 commit 中删除文件，并不能从旧 commit 中移除秘密信息。如果密码或 token 已经暴露给他人，请先在签发它的服务中撤销或轮换。清理历史记录也无法撤回已经保存的副本。

请注意

不要把清理共享历史当作普通的文件修复来执行。它会改变 commit ID，需要团队协调：暂停推送旧分支，找出所有受影响的路径，在单独的副本中检查结果，并与同事约定如何更新他们的副本。

清理历史时，GitHub 介绍的是使用 git-filter-repo 的流程。具体命令取决于您是要删除整个文件还是替换其中的秘密字符串、该字符串出现在哪里，以及历史记录被推送到了哪些地方。请遵循官方敏感数据移除指南，其中包括创建新的 clone、检查结果、更新远程引用，以及同事需要采取的操作。

清理本地副本本身不会改变服务器。强制推送改写后的历史是另一项需要协商的操作；这里不应对所有分支套用一条通用命令。其他人的 clone 和 fork 副本不受您控制；对于 GitHub 仍可访问的链接和缓存，请按照同一指南中的条件联系 Support。

为了降低再次发生的风险：

  • 将秘密信息保存在代码之外，例如环境变量中；
  • 在 Git 开始跟踪本地文件之前（例如 .env），先将它们加入 .gitignore；
  • 提交前检查选中的文件以及 git diff --cached；
  • 如果 repository 支持 secret scanning 和 push protection，请启用它们作为额外检查；但它们无法检测到所有类型的秘密信息。
C++
请注意

智能体可以帮助您找出受影响的路径并准备清理计划。不要为了搜索而把仍有效的秘密信息粘贴到聊天中。先撤销访问权限，再协商如何处理历史记录。

Claude Code 如何与 Git 配合

Claude Code 在操作 repository 时，这三个主题都会派上用场。请留意以下几点：

  • 它可以初始化 repository（git init）并准备第一个 commit；在 GitHub 上创建 repository 时，由您选择 public 还是 private；
  • 它会根据项目规则提出分支整合方式；运行前，请检查 merge 和 rebase 的影响；
  • 它能看到要纳入 commit 的文件，但确保秘密信息没有混进去，最终责任仍由您承担。
请注意

提交前，请同时检查文件列表和 diff 中的文件内容。秘密信息可能藏在普通源文件中，不一定只在 .env 里。如果它已经进入历史记录，请先轮换受影响的秘密信息，再判断是否需要清理历史。

上一篇文章：Git 中的更改撤销与恢复