分支简介 ​

分支创建

git branch <branchname>

分支切换

git checkout testing

创建并切换分支

git checkout -b <branchname>

查看分叉历史

git log --oneline --decorate --graph --all

分支的新建与合并 ​

让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步骤：

1. 开发某个网站。
2. 为实现某个新的用户需求，创建一个分支。
3. 在这个分支上开展工作。

正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：

1. 切换到你的线上分支（production branch）。
2. 为这个紧急任务新建一个分支，并在其中修复它。
3. 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。
4. 切换回你最初工作的分支上，继续工作。

新建分支 ​

创建一个 iss53 分支用于修复#53问题，

git checkout -b iss53

在处理 #53 问题过程中，需要紧急修复一个问题，先提交暂存 iss53，然后切换回 master

git checkout master

再创建一个紧急修复分支

git checkout -b hotfix

修复完成后，切换回 master，并将 hotfix 合并到 master

git checkout master

git merge hotfix

这时可以删除 hotfix 分支了

使用带 -d 选项的 git branch 命令来删除分支：

git branch -d hotfix

分支的合并 ​

git checkout master

git merge iss53

遇到冲突时的分支合并 ​

冲突区段示例

<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
 please contact us at support@github.com
</div>
>>>>>>> iss53:index.html

分支管理 ​

查看当前所有分支的一个列表

git branch

查看每一个分支的最后一次提交

git branch -v

--merged 与 --no-merged 这两个有用的选项可以过滤这个列表中已经合并或尚未合并到当前分支的分支。

查看哪些分支已经合并到当前分支

git branch --merged

查看所有包含未合并工作的分支

git branch --no-merged

如果存在未被合并的分支，使用 git branch -d 命令删除它时会失败

如果真的想要删除分支并丢掉那些工作，可以使用 -D 选项强制删除。

如果处于其他分支上，想要查看有哪些分支没有被合并到 master 分支，可以这样：

git branch --no-merged master

分支开发工作流 ​

长期分支 ​

在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 还有一些名为 develop 或者 next 的平行分支， 被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定， 但是一旦达到稳定状态，它们就可以被合并入 master 分支了。 这样，在确保这些已完成的主题分支（短期分支，比如之前的 iss53 分支）能够通过所有测试， 并且不会引入更多 bug 之后，就可以合并入主干分支中，等待下一次的发布

主题分支 ​

主题分支对任何规模的项目都适用。 主题分支是一种短期分支，它被用来实现单一特性或其相关工作

远程分支 ​

查看远程引用的完整列表

git ls-remote <remote>

获得远程分支的更多信息

git remote show <remote>

推送

git push <remote> <branch>

如何避免每次输入密码

如果不想在每一次推送时都输入用户名与密码，你可以设置一个 “credential cache”。

最简单的方式就是将其保存在内存中几分钟，可以简单地运行 git config --global credential.helper cache 来设置它。

bash

git config --global credential.helper cache

跟踪分支

git checkout -b <branch> <remote>/<branch>

git checkout -b serverfix origin/serverfix

git checkout --track origin/serverfix

拉取

从服务器上抓取本地没有的数据，它并不会修改工作目录中的内容，它只会获取数据然后让你自己合并

git fetch

git pull 在大多数情况下它的含义是一个 git fetch 紧接着一个 git merge 命令

git pull

删除远程分支

可以运行带有 --delete 选项的 git push 命令来删除一个远程分支

git push origin --delete serverfix

变基 ​

git rebase 是 整理提交历史、让分支更线性 的利器。

可以把它理解为：把一串提交“挪”到另一个基点之上重新播放一遍。

用得好，提交历史非常干净；用不好，容易把自己和同事都坑到。

一、git rebase 是干嘛的（一句话版） ​

把当前分支的提交，按顺序重新应用到另一个分支的最新提交之上

对比一下：

• git merge：保留分叉历史，生成一次 merge commit
• git rebase：改写历史，让提交看起来像是“从一开始就在最新分支上开发”

二、最常见的使用场景（90% 的使用量） ​

1️⃣ 功能分支跟上主分支最新代码（最常用） ​

git checkout feature/login
git rebase main

效果：

main:     A---B---C
feature:         D---E

rebase 后：

main:     A---B---C---D'---E'

📌 好处

• 没有多余的 merge commit
• PR / 提交记录更清爽

2️⃣ 合并前整理提交（压缩、修改 commit） ​

这是 rebase 的灵魂用法。

git rebase -i HEAD~3

会出现类似：

pick a1b2c3 feat: add login page
pick d4e5f6 fix: login style
pick g7h8i9 fix: typo

你可以改成：

pick a1b2c3 feat: add login page
squash d4e5f6 fix: login style
squash g7h8i9 fix: typo

👉 最终变成 一个干净的 commit

📌 常见指令：

• pick：保留
• squash (s)：合并到前一个
• reword (r)：只改 commit message
• edit (e)：中途停下来改代码

三、rebase 过程中发生了什么？ ​

rebase 并不是“挪动提交”，而是：

复制一份提交 → 应用到新基点 → 原提交被丢弃

所以：

• commit hash 一定会变
• 这就是为什么 rebase 会“改历史”

四、冲突怎么处理？ ​

rebase 遇到冲突是常态，不是异常。

流程：

# 出现冲突
git status

# 手动解决冲突后
git add .
git rebase --continue

如果你不想玩了：

git rebase --abort

📌 记住一句话： rebase 是“一次一个提交”地 replay，所以冲突可能会多次出现

五、rebase vs merge（什么时候用哪个） ​

一句经验法则：

没 push 的分支，随便 rebase；已经 push 给别人用的分支，不要 rebase

六、和远程分支一起用（高频踩坑点） ​

❌ 错误操作

git push
git rebase main
git push   # ❌ 会被拒绝

因为历史不一致了。

✅ 正确姿势（你知道你在干嘛）

git push --force-with-lease

📌 永远用 --force-with-lease 不要用裸 --force

七、实战推荐 workflow ​

你可以养成这个习惯：

# 1. 拉最新主分支
git fetch origin

# 2. rebase 到最新 main
git rebase origin/main

# 3. 提交前整理 commit
git rebase -i origin/main

# 4. 推送
git push --force-with-lease

👉 非常适合 PR 前整理历史

八、一句忠告（很重要） ​

rebase 是“外科手术刀”，不是“菜刀”

• 能让项目历史非常优雅
• 但公共历史乱 rebase，一定会出事故

3.2 Git 分支 - 分支的新建与合并