Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序，Get更优阅读体验！
立即前往
文档建议反馈控制台
首页
学习
活动
专区
圈层
工具
MCP广场
文章/答案/技术大牛
发布
首页
学习
活动
专区
圈层
工具
MCP广场
返回腾讯云官网
社区首页 >专栏 >【git#4】分支管理 -- 知识补充

【git#4】分支管理 -- 知识补充

作者头像
IsLand1314
发布于 2025-04-26 11:45:58
发布于 2025-04-26 11:45:58
12000
代码可运行
举报
文章被收录于专栏：学习之路学习之路
运行总次数：0
代码可运行
关联问题
换一批

一、bug 分支

假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要解决。

  • 在Git中，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

可现在 dev2 的代码在工作区中开发了一半，还无法提交，怎么办?例如:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git branch
* dev2
  master

lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
I am coding...

lighthouse@VM-8-10-ubuntu:gitcode$ git status
On branch dev2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   book

no changes added to commit (use "git add" and/or "git commit -a")

Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git stash
Saved working directory and index state WIP on dev2: 2bd7b8b modify Readme
lighthouse@VM-8-10-ubuntu:gitcode$ git status
On branch dev2
nothing to commit, working tree clean

用 git status 查看工作区，就是干净的(除非有没有被 Git 管理的文件)，因此可以放心地创建分支来修复bug。

储藏 dev2 工作区之后，由于我们要基于 master 分支修复 bug，所以需要切回 master 分支，再新建临时分支来修复 bug，示例如下:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout -b fix_bg # 新建并切换
Switched to a new branch 'fix_bg'
lighthouse@VM-8-10-ubuntu:gitcode$ vim book
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
lighthouse@VM-8-10-ubuntu:gitcode$ git add book
lighthouse@VM-8-10-ubuntu:gitcode$ git commit -m "fix bug"
[fix_bg c0637e0] fix bug
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bg 分支

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
Switched to branch 'master'
lighthouse@VM-8-10-ubuntu:gitcode$ git merge --no-ff -m "merge fix_bug branch" fix_bg
Merge made by the 'ort' strategy.
 book | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

至此，bug的修复工作已经做完了，我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout dev2
Switched to branch 'dev2'
lighthouse@VM-8-10-ubuntu:gitcode$ git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用 git stash list 命令看看:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git stash list
stash@{0}: WIP on dev2: 2bd7b8b modify Readme

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下，如何恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git stash pop
On branch dev2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   book

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (e2dfd6d0312e2454d1a7a4a3eb65cf3e28f333af)

再次查看的时候，我们已经发现已经没有现场可以恢复了

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git stash list
lighthouse@VM-8-10-ubuntu:gitcode$

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要用 git stash drop 来删除;

  • 当然也可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令git stash apply stash@{o}

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
I am coding... Done
lighthouse@VM-8-10-ubuntu:gitcode$ git add .
lighthouse@VM-8-10-ubuntu:gitcode$ git commit -m "modify book"
[dev2 ccb0f97] modify book
 1 file changed, 1 insertion(+)

但我们注意到了，修复 bug的内容，并没有在 dev2 上显示。此时的状态图为:

image-20250408222829805
image-20250408222829805

Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。

  • 我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的

原因：在合并分支时可能会有冲突，而代码冲突需要我们手动解决(在 master上解决)

  • 我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。

此时的状态为:

image-20250408223022215
image-20250408223022215

解决这个问题的一个好的建议就是：最好在自己的分支上合并下 master ，再让 master 去合并dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master

此时的状态为：

image-20250408223401563
image-20250408223401563
image-20250408223405993
image-20250408223405993

对应的实操演示如下，要说明的是，以下演示的merge操作，没有使用 --no-ff ，但上述的图示是禁用 Fast forward 了模式后得出的，主要是为了方便解释问题。

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# dev 合并 master
lighthouse@VM-8-10-ubuntu:gitcode$ git branch
* dev2
  master
lighthouse@VM-8-10-ubuntu:gitcode$ git merge master
Auto-merging book
CONFLICT (content): Merge conflict in book
Automatic merge failed; fix conflicts and then commit the result.

# 发送冲突
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d
I am coding... Done
=======
a,b,c,d,e
>>>>>>> master

# 解决冲突并重新提交
lighthouse@VM-8-10-ubuntu:gitcode$ vim book
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
I am coding... Done
lighthouse@VM-8-10-ubuntu:gitcode$ git add .
lighthouse@VM-8-10-ubuntu:gitcode$ git commit -m "merge master"
[dev2 9e77002] merge master
lighthouse@VM-8-10-ubuntu:gitcode$ git status
On branch dev2
nothing to commit, working tree clean

# 切回 master
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
Switched to branch 'master'

# master 合并 dev2  -- 无需解决冲突
lighthouse@VM-8-10-ubuntu:gitcode$ git merge dev2
Updating adbb267..9e77002
Fast-forward
 book | 1 +
 1 file changed, 1 insertion(+)
lighthouse@VM-8-10-ubuntu:gitcode$ git status
On branch master
nothing to commit, working tree clean

# 删除 dev2 分支
lighthouse@VM-8-10-ubuntu:gitcode$ git branch -d dev2
Deleted branch dev2 (was 9e77002).
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
I am coding... Done

二、强制删除分支

软件开发中，总有无穷无尽的新的功能要不断添加进来

  • 添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。
  • 可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。
  • 这时使用传统的 git branch -d 命令删除分支的方法是不行的。

演示如下:

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# 新增并切换到 dev3 分支
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout -b dev3
Switched to a new branch 'dev3'
lighthouse@VM-8-10-ubuntu:gitcode$ clear

# 开始开发新功能并提交
lighthouse@VM-8-10-ubuntu:gitcode$ vim book
lighthouse@VM-8-10-ubuntu:gitcode$ cat book
Hello Island1314
Hello World
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e
I am coding... Done
I am writing new features ...
lighthouse@VM-8-10-ubuntu:gitcode$ git add .
lighthouse@VM-8-10-ubuntu:gitcode$ git commit -m "modify book for new features"
[dev3 fb6a737] modify book for new features
 1 file changed, 1 insertion(+)
 
 # 此时新功能叫停, 切回 master 准备删除 dev3
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
Switched to branch 'master'

对 dev3 进行删除，如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
# 常规删除 dev3 分支时失败
lighthouse@VM-8-10-ubuntu:gitcode$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.
# 按照提示进行删除
lighthouse@VM-8-10-ubuntu:gitcode$ git branch -D dev3
Deleted branch dev3 (was fb6a737).

三、分支的作用

🌊 分支在实际中有什么用呢？

  • 假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。
  • 如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
  • 现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

而且 Git 无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件

四、细节补充

1. 未提交修改时（未commit）

当我们在 dev 分支下修改文件之后，master 还是可以看到的（没有 add 的情况下），如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout dev
Switched to branch 'dev'
lighthouse@VM-8-10-ubuntu:gitcode$ vim file

lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
Switched to branch 'master'
lighthouse@VM-8-10-ubuntu:gitcode$ cat file
i miss you # master 分支
I Miss You # dev 分支

lighthouse@VM-8-10-ubuntu:gitcode$ git checkout dev
Switched to branch 'dev'
lighthouse@VM-8-10-ubuntu:gitcode$ git add file
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
A	file
Switched to branch 'master'
lighthouse@VM-8-10-ubuntu:gitcode$ cat file
i miss you # master 分支
I Miss You # dev 分支
  • 工作目录是共享的：所有未提交的改动（包括未 add 的修改和已 add 但未 commit 的暂存）都存在于工作目录中，不会被 Git 自动隔离到特定分支
  • 切换分支时的行为：
    • 如果目标分支（如 master）和当前分支（如 dev）对同一文件的修改不冲突，Git 允许直接切换，并保留工作目录的改动。
    • 因此，在未提交的情况下，无论切换到哪个分支，看到的都是工作目录中的当前内容（即未提交的修改）
2. 已提交修改后

而当我们在 切换到 dev 分支进行 commit 之后，然后再切换到 master 分支查看，然后 如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ git checkout dev
A	file
Switched to branch 'dev'
lighthouse@VM-8-10-ubuntu:gitcode$ git commit file
Aborting commit due to empty commit message.
lighthouse@VM-8-10-ubuntu:gitcode$ git commit -m "改变" file
[dev 1a1993f] 改变
 1 file changed, 2 insertions(+)
 create mode 100644 file
  • 提交 (commit) 的作用：将暂存区的内容永久记录到当前分支的历史中，此时修改正式归属于 dev 分支。
  • 切换分支时的行为：
    • Git 会严格根据目标分支（如 master）的最新提交重建工作目录。
    • 如果 master 分支从未包含 file 文件（即该文件只在 dev 分支提交过，下面等下会细说这个问题），切换到 master 时，Git 会删除工作目录中的 file 文件，因为 master 分支的历史中不存在它

总结

  • 提交后，数据已保存在 dev 分支的历史中，不会丢失。
  • master 分支的工作区被重建为它自己的最新提交状态，因此看不到 dev 分支的改动。

这里要说一下，由于我们在 master 分支下没有 commit 过文件，因此当我们在 dev下首次 commit，那么 master 分支下的 file 文件就会消失，如下：

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
lighthouse@VM-8-10-ubuntu:gitcode$ cat file
i miss you # master 分支
I Miss You # dev 分支

lighthouse@VM-8-10-ubuntu:gitcode$ git checkout master
Switched to branch 'master'
lighthouse@VM-8-10-ubuntu:gitcode$ cat file
cat: file: No such file or directory
lighthouse@VM-8-10-ubuntu:gitcode$ ll
total 20
drwxrwxr-x 4 lighthouse lighthouse 4096 Apr 18 19:52 ./
drwxrwxr-x 7 lighthouse lighthouse 4096 Apr 15 21:47 ../
-rw-rw-r-- 1 lighthouse lighthouse  129 Apr  8 23:05 book
drwxrwxr-x 8 lighthouse lighthouse 4096 Apr 18 19:52 .git/
drwxrwxr-x 3 lighthouse lighthouse 4096 Apr 10 22:29 git_learning/

初始状态：

  • master 分支未提交过 file 文件（或该文件未被跟踪）。
  • 你在 dev 分支修改并提交了 file，此时 file 成为 dev 分支的一部分。

切换回 master：

  • master 分支没有 file 的记录，Git 会清理工作目录，删除 file 文件以匹配 master 分支的状态

因此分支交换的逻辑，可以这样理解，如下：

  • 未提交时：
    • 如果修改未提交，Git 在切换分支时会尽量保留工作区内容（除非目标分支和当前修改冲突）。
    • 保留的原因：并非“怕数据丢失”，而是为了用户能自由切换分支并继续工作。例如，你在 dev 修改了文件，想临时切到 master 修复问题，Git 允许携带未提交的修改切换（只要不冲突）。
  • 提交后：
    • 提交的修改会写入 dev 分支的历史记录，此时 dev 分支的最新提交包含该文件，而 master 分支的历史记录中没有该文件。
    • 切换回 master 时，Git 会根据 master 的最新提交重建工作区，因此文件会消失（因为 master 从未记录过它）。
3. 如何避免问题
  • 提交前检查分支状态：确保在正确的分支提交改动。
  • 使用 git stash：临时保存未提交的修改，切换分支后再恢复
    • 核心功能：临时保存工作区和暂存区的未提交修改，清空工作区，使其“干净”（与当前分支的最新提交一致）
    • 效果：切换分支时，未提交的修改不会被带到其他分支（避免意外覆盖或冲突）
  • 理解文件跟踪：新增文件需通过 git add 和 commit 明确添加到分支历史中。

  • 未提交的修改：属于工作目录，切换分支时可能保留（除非冲突）。
  • 已提交的修改：属于特定分支的历史，切换分支时 Git 会严格重建工作目录以匹配目标分支

这就是为什么在提交后切换到 master 时文件“消失”的原因——Git 严格遵循分支的历史记录管理文件

4. 重新理解 工作区、暂存区、版本库
  1. 工作区（Working Directory）
    • 所有分支共享同一个物理工作目录，未提交的修改（无论是否 add）都存在于工作区中，不直接绑定到任何分支
    • 工作区的内容会根据当前分支的最新提交动态变化
  2. 暂存区（Staging Area）：同样全局共享，git add 后的内容属于暂存区，与分支无关。
  3. 版本库（Repository）
    • 提交（commit）后，修改会绑定到当前分支的历史记录中，不同分支的提交历史是独立的
    • 提交后的内容属于分支的历史记录，与工作区无关

但是看到这里，也许大家也会有点问题，就是当 commit 之后，那么产生的文件在两个分支下不就内容不一样了吗，此时它两也能算得上全局共享嘛？？？

解释如下：

假设有一个文件 file.txt，初始状态如下：

步骤 1：在 master 分支创建文件并提交

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
git checkout master
echo "Hello from master" > file.txt
git add file.txt
git commit -m "Add file in master"

此时：

  • master 分支的提交历史包含 file.txt。
  • 工作区中的 file.txt 内容是 Hello from master。

步骤 2：创建 dev 分支并修改文件

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
git checkout -b dev
echo "Hello from dev" > file.txt
git add file.txt
git commit -m "Update file in dev"

此时：

  • dev 分支的提交历史包含修改后的 file.txt（内容是 Hello from dev）。
  • master 分支的提交历史仍为旧版本（内容是 Hello from master）。

步骤 3：切换回 master 分支查看文件

代码语言：javascript
代码运行次数：0
运行
AI代码解释
复制
git checkout master
cat file.txt
Hello from master
关键现象解释
  1. 为什么切换分支后文件内容变了？
    • Git 会根据目标分支的最新提交重建工作区。
    • master 分支的最新提交是原始版本，而 dev 分支的最新提交是修改后的版本。
  2. 工作区是“共享”的吗？
    • 物理上共享：所有分支操作同一块磁盘区域。
    • 逻辑上隔离：切换分支时，Git 会覆盖工作区内容，使其匹配目标分支的提交。
    • 你可以理解为：工作区是“共享的舞台”，但每次切换分支时，Git 会更换舞台上的“布景”。
  3. 提交后的文件到底属于谁？
    • 提交后的内容属于分支的历史记录，不直接绑定到工作区。
    • dev 分支的提交历史中有一个新版本的 file.txt，而 master 分支的提交历史中仍是旧版本。
全局共享 vs 分支独立

区域

是否全局共享？

是否受分支切换影响？

工作区

✅ 是（所有分支共享同一物理目录）

✅ 是（切换分支时内容会被覆盖）

暂存区

✅ 是

✅ 是（切换分支时可能被覆盖）

版本库（提交）

❌ 否（每个分支有独立提交历史）

❌ 否（提交历史永久绑定到分支）

疑问解决
  • 你的问题： “commit 之后，产生的文件在两个分支下内容不一样了，此时它们还能算全局共享吗？”
  • 答案：
    • 工作区本身是共享的，但它的内容会根据当前分支的提交历史动态变化。
    • 提交后的差异是分支历史隔离的结果，而不是工作区本身的隔离。
    • 你可以想象工作区是一个“画布”，而不同分支是“不同的画作版本”。每次切换分支时，Git 会擦掉当前画布上的内容，重新绘制目标分支对应的画作。
总结
  • 工作区共享：所有分支操作同一块磁盘区域，但内容由当前分支的提交历史决定。
  • 提交隔离：不同分支的提交历史独立，切换分支时 Git 会严格按目标分支的历史重建工作区。
  • 看似矛盾的现象：工作区是共享的，但提交后的文件在不同分支下内容不同，这正是 Git 分支机制的核心设计——通过动态覆盖工作区内容，实现高效的多分支协作。
本文参与 腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。
原始发表：2025-04-25，如有侵权请联系 cloudcommunity@tencent.com 删除
管理
开发
git
ubuntu
工作

本文分享自 作者个人站点/博客 前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ，欢迎热爱写作的你一起参与！

管理
开发
git
ubuntu
工作
评论
登录后参与评论
暂无评论
登录 后参与评论
推荐阅读
编辑精选文章
换一批
万字详解高可用架构设计
2845
Go 开发者必备：Protocol Buffers 入门指南
1652
10分钟带你彻底搞懂分布式链路跟踪
1124
多租户的 4 种常用方案
2410
亿级月活的社交 APP，陌陌如何做到 3 分钟定位故障？
1618
60页PPT全解：DeepSeek系列论文技术要点整理
2773
【Git#2】分支管理的基本操作
ubuntubranch工作管理git
Git 的分支机制堪称现代软件开发中的"时空操纵术"。想象你同时拥有多个互不干扰的独立时间线：
IsLand1314
2025/04/22
1460
【Git#2】分支管理的基本操作
Git分支管理
存储工作管理开发git
分⽀就是科幻电影里面的平行宇宙，当你正在电脑前努力学习C++的时候，另⼀个你正在另⼀个平行宇宙里努力学习JAVA。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并 了，结果，你既学会了C++也学会了JAVA。
二肥是只大懒蓝猫
2024/07/19
1170
Git分支管理
【Git#3】分支管理下的分支策略
管理架构开发gitmerge
通常在合并分支时，一般情况下Git会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢?
IsLand1314
2025/04/24
1220
【Git#3】分支管理下的分支策略
Git 分支管理与多人协作实战指南
开发推送git工作管理
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++的时候，另一个你正在另一个平行宇宙里努力学习 JAVA。 如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并 了，结果，你既学会了 C++ 又学会了 JAVA!
用户11316056
2025/01/23
1670
Git 分支管理与多人协作实战指南
【Git#1】初识 git（配置 & 基本认识 & 文件操作）
工作配置git存储对象
在工作或学习时经常遇到这样的情况：我们在编写各种文档时，为了防止文档丢失，更改失误，失误后能恢复到原来的版本，不得不复制出一个副本，比如:
IsLand1314
2025/04/19
3220
【Git#1】初识 git（配置 & 基本认识 & 文件操作）
【Git版本控制器】第四弹——分支管理，合并冲突，--no-ff，git stash
git分布式版本控制工作管理
相关笔记： https://blog.csdn.net/djdjiejsn/category_12893502.html
用户11396661
2025/02/24
710
【Git版本控制器】第四弹——分支管理，合并冲突，--no-ff，git stash
GitHub-分支管理02-BUG与Feature分支
git编程算法
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
踏歌行
2020/10/15
5210
git初入门（三）：分支
git2023腾讯·技术创作特训营 第二期
分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 Git 的时候，另一个你正在另一个平行宇宙里努力学习 SVN。
传说之下的花儿
2023/09/16
3490
git初入门（三）：分支
【Git】二、分支管理详解
指针gitcentos工作管理
​ 分支是什么呢，其实 分支就像是分身术，想象一下，我们学编程语言的时候，如果能进行分身，也就是分支，此时本体去学 c++，而分身去 java，甚至再分身去学 php……
利刃大大
2025/02/06
1550
【Git】二、分支管理详解
【Git】Git 分支管理 ( 使用 git cherry-pick 命令提取提交记录应用于当前分支 | 创建新分支应用某个提交 | git cherry-pick 冲突处理 )
gittxtvim编辑器管理
git cherry-pick 命令的作用是 将指定的 一个或若干个 提交记录 , 应用与当前的分支 ;
韩曙亮
2023/03/30
3.9K0
【Git】Git 分支管理 ( 使用 git cherry-pick 命令提取提交记录应用于当前分支 | 创建新分支应用某个提交 | git cherry-pick 冲突处理 )
git常用命令
开源gitgithub编程算法
注意： git rm file 可以用来删除提交到版本库中的文件，一般删除要执行以下命令：git rm file.txt,git commit -m 'delete'，注意在git commit之前还是可以取消删除的，使用git checkout -- file.txt，可以一键取消删除
爱撒谎的男孩
2019/12/31
3900
GIT学习----第十四节：BUG分支
编程算法git
学习目的 遇到临时bug需要紧急修复，在git如何处理？ git如何进行工作区进行储藏，等待bug修复后的工作区恢复？ 临时储藏 修改后查看工作区状态 $ git status On branch master Your branch is ahead of 'origin/master' by 10 commits. (use "git push" to publish your local commits) Changes not staged for commit: (use "git ad
Rattenking
2021/01/30
4590
初识git · 分支管理
存储工作管理开发git
Git分支管理是一种强大的版本控制策略，它允许开发者在不影响主代码库的情况下，进行并行开发和实验。以下是Git分支管理的简单文字介绍：
_lazy
2024/10/16
3230
初识git · 分支管理
[Git] 如何将已经执行的修改操作撤销
gitreset工作原理指针
在使用 Git 工作时，经常会遇到这样的情况：写了一段代码，或者对文件做了一些修改，但后来发现这些改动不好，想回到之前的状态。根据你的改动所处的“阶段”（在工作区、暂存区还是已经提交到了版本库），撤销修改的方法是不同的。
DevKevin
2025/05/30
1530
[Git] 如何将已经执行的修改操作撤销
史上最详细Git使用教程[通俗易懂]
git
每个开发都可以从master上克隆一个本地版本库，就算没有网络，也可以提交代码到本地仓库、查看log、创建项目分支等等
全栈程序员站长
2022/08/12
7530
史上最详细Git使用教程[通俗易懂]
[Git] 如何进行版本回退
指针gitadd对象工作
版本控制系统最重要的能力之一，就是能够轻松地在项目的不同历史版本之间切换。有时，你可能发现最近的修改引入了严重问题，或者需要回到之前的某个节点重新开始。这时，“版本回退”功能就派上用场了。
DevKevin
2025/05/30
2240
[Git] 如何进行版本回退
GIT操作 之 常用指令（入门级）
html编程算法开源gitgithub
接下来，我们简单捋一捋这个过程： 下行路程：作为小前端的我在本地电脑（工作区）上的一个文件夹下进行初始化git init，紧接着马不停蹄的撸了一把代码，保存为file.html ------------> 通过 add ，把file.html放到了暂存区 ------------> 然后又通过 commit，把file.html送到了本地仓库 ------------> 最后通过 push，把file.html推送到了远程仓库。
celineWong7
2020/11/05
7410
Git教程4(分支管理)
git
  所谓的分支管理其实就是就是同时可以有多条时间线在执行，最终合并为一个点，有点类似于多线程操作，这也正是git有别于其他版本控制软件的地方。
用户4919348
2019/04/02
4610
Git教程4(分支管理)
9 Git和Github高级
gitgithubdevopsaddtxt
本文我将将学习一些高级的 Git 技术，包括分支、合并、恢复、保存更改、选择性提交以及冲突解决等等。这些技术对于软件开发项目中的有效协作和版本控制至关重要。那么，让我们开始吧。
Lemon黄
2023/12/03
2330
9 Git和Github高级
Git之Bug分支
git编程算法
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。 当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交： $ git status On branch dev Changes to be committed: (use "git reset HEAD <file>.
兮动人
2021/06/11
3130
推荐阅读
编辑精选文章
万字详解高可用架构设计Go 开发者必备：Protocol Buffers 入门指南10分钟带你彻底搞懂分布式链路跟踪
相关讨论
腾讯云服务补充协议？备案认证_冷知识？？？宗教知识竞赛脚本？
相关课程
Java数字化IT从业者知识体系微信公众号在线学习平台搭建实践_《硅谷课堂》
【Git#2】分支管理的基本操作
1460
Git分支管理
1170
【Git#3】分支管理下的分支策略
1220
Git 分支管理与多人协作实战指南
1670
【Git#1】初识 git（配置 & 基本认识 & 文件操作）
3220
【Git版本控制器】第四弹——分支管理，合并冲突，--no-ff，git stash
710
GitHub-分支管理02-BUG与Feature分支
5210
git初入门（三）：分支
3490
【Git】二、分支管理详解
1550
【Git】Git 分支管理 ( 使用 git cherry-pick 命令提取提交记录应用于当前分支 | 创建新分支应用某个提交 | git cherry-pick 冲突处理 )
3.9K0
git常用命令
3900
GIT学习----第十四节：BUG分支
4590
初识git · 分支管理
3230
[Git] 如何将已经执行的修改操作撤销
1530
史上最详细Git使用教程[通俗易懂]
7530
[Git] 如何进行版本回退
2240
GIT操作 之 常用指令（入门级）
7410
Git教程4(分支管理)
4610
9 Git和Github高级
2330
Git之Bug分支
3130
相关推荐
【Git#2】分支管理的基本操作
更多 >
IsLand13140
LV.1
这个人很懒，什么都没有留下～
文章
193
获赞
175
专栏
1
作者相关精选
换一批
加入讨论
的问答专区 >
庆丰
1高级总监擅长4个领域
相关课程
一站式学习中心 >
Java
1944人在学
java
数字化IT从业者知识体系
397人在学
CODING DevOps
软件开发
微信公众号在线学习平台搭建实践_《硅谷课堂》
388人在学
文件存储
云点播
CODING DevOps
领券

腾讯云开发者

扫码关注腾讯云开发者

扫码关注腾讯云开发者

领取腾讯云代金券

热门产品

热门推荐

更多推荐

Copyright © 2013 - 2025 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有 

深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

腾讯云计算（北京）有限责任公司 京ICP证150476号 |  京ICP备11018762号 | 京公网安备号11010802020287

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档

Copyright © 2013 - 2025 Tencent Cloud.

All Rights Reserved. 腾讯云 版权所有

登录 后参与评论
1
目录
本文部分代码块支持一键运行，欢迎体验
本文部分代码块支持一键运行，欢迎体验