Git分支管理：如何优雅地使用分支、合并和切换

一、使用分支和合并

【需求描述】最近在使用git进行项目管理的时候，该项目是一个网络库，有这样一个需求场景：1. 对于master主分支，随着库功能的添加和bug修复，会时不时的进行一些提交到远程仓库的操作，并给提交打上tag来表明库版本。2. 另开一个分支，因为我要在该分支上针对某个主分支发布的库版本开发一些应用，比如我在master tag v1.0的版本位置开辟了一个分支使用该版本的库进行应用开发，那么随着时间的推移，主分支发布的重大更新，例如v2.0, 此时我想让我的这个开发应用的分支使用这个新的v2.0版本，怎么做，我需要开辟一个新的分支，然后将之前的开发分支合并的这个新分支吗？还是直接合并到主分支？还是其它什么方案？

下面介绍一些关于git分支管理的信息。

对于这个需求，可以采用以下方案之一：

1.1 使用git rebase 将主分支合并到开发分支

• 方案一：在你的开发应用分支上，使用git rebase命令将主分支的v2.0版本合并到你的分支上。这样，你的分支就可以基于最新的库版本进行开发，而且不会产生多余的合并提交。但是，这种方案有一个缺点，就是你需要解决可能出现的冲突，并且你需要强制推送你的分支到远程仓库，因为你改变了分支的历史。如果你的分支是一个共享分支，那么这种方案可能会给其他协作者带来麻烦。具体操作如下：

# 切换到你的开发应用分支
git checkout dev-app
# 将主分支v2.0版本合并到你的分支上
git rebase master v2.0
# 解决可能出现的冲突，并继续rebase操作
git add .
git rebase --continue
# 强制推送你的分支到远程仓库
git push -f origin dev-app

1.2 新建另外一个开发分支然后将之前的开发分支合并到当前开发分支

• 方案二：在主分支上，使用git checkout命令创建一个新的分支，基于v2.0版本进行开发应用。然后，使用git merge命令将你之前的开发应用分支合并到这个新的分支上。这样，你也可以使用最新的库版本进行开发，而且不会改变任何分支的历史。但是，这种方案也有一个缺点，就是你需要创建一个新的分支，并且可能产生一个合并提交。如果你不想保留你之前的开发应用分支，那么你可以删除它。具体操作如下：

# 切换到主分支
git checkout master
# 创建一个新的分支，基于v2.0版本进行开发应用
git checkout -b new-dev-app v2.0
# 将你之前的开发应用分支合并到这个新的分支上
git merge dev-app
# 解决可能出现的冲突，并完成合并操作
git add .
git commit -m "Merge dev-app into new-dev-app"
# 推送你的新分支到远程仓库
git push origin new-dev-app
# 如果你不想保留你之前的开发应用分支，可以删除它（本地和远程）
git branch -d dev-app
git push origin --delete dev-app

1.3 参考资料：git分支管理的知识和技巧

• Git - Branch Management：Git使用和原理的在线书籍，其中第三章介绍了Git分支管理相关的内容。
• Managing branches in your repository - GitHub Docs：GitHub官方文档中关于如何在GitHub上管理仓库中的分支的部分。
• 10 Key Best Practices for Git Branch Management - Medium：总结了一些Git分支管理方面的最佳实践（博客文章）

二、分支切换

切换分支的时候我们常常要出现要考虑这个问题：

2.1 如果我切换分支会怎么样？当前的工作区和暂存区内容会丢失吗？

分支切换，暂存区和工作区的内容会不会丢失，如何保留？即切换的时候不会丢失我们的暂存区和工作区的修改？

如果你切换分支，当前的工作区和暂存区内容不一定会丢失，这取决于你的本地修改是否会影响到你要切换的分支上的文件。

当你切换分支时，如果有本地修改，git会尝试将这些修改合并到你要切换的分支上。如果合并可以顺利进行，切换分支就会成功，并且你可以在新的分支上看到你的修改。

但是，如果合并过程中出现冲突，比如修改了一个文件，而这个文件在你要切换的分支上和当前分支上有不同的版本，那么你就会收到一个错误信息：error: Your local changes to the following files would be overwritten by checkout。¹ 这时候，git会拒绝切换分支，以保护你的本地修改。

为了解决这个问题，通常有以下几种选择：

• 选择一：提交你的本地修改到当前分支上，然后再切换分支。这样，你就可以保留你的修改，并且在新的分支上继续工作。
• 选择二：放弃你的本地修改，使用git checkout -f 命令强制切换分支。这样，你就可以忽略你的修改，并且在新的分支上开始一个干净的状态。
• 选择三：暂存你的本地修改，使用git stash命令将你的修改保存在一个特殊的区域，然后再切换分支。这样，你就可以在新的分支上恢复你的修改，并且继续工作。

2.2 如果我再切换回去，会怎么样？

如果你再切换回去，会发生什么，取决于你之前是如何切换分支的。可能有几种可能的情况：

• 情况一：如果你之前使用了git stash命令将你的本地修改暂存起来，然后切换到了另一个分支，那么当你再切换回去时，你可以使用git stash apply命令将你的本地修改恢复到工作区和暂存区中。这样，你就可以继续在原来的分支上工作。¹
• 情况二：如果你之前使用了git reset --hard HEAD或者git checkout -f 命令放弃了你的本地修改，然后切换到了另一个分支，那么当你再切换回去时，你的本地修改就会丢失，无法恢复。这样，你就只能在原来的分支上重新开始工作。²
• 情况三：如果你之前使用了git commit命令将你的本地修改提交到了当前分支上，然后切换到了另一个分支，那么当你再切换回去时，你的本地修改就会保留在版本库中，并且更新了当前分支。这样，你就可以在原来的分支上继续工作。³
• 情况四：如果你之前没有使用任何命令，而是直接切换到了另一个分支，并且没有收到任何错误信息，那么说明Git能够自动将你的本地修改合并到新的分支上。这样，当你再切换回去时，Git也会尝试将你的本地修改合并回原来的分支上。如果合并顺利进行，那么你就可以在原来的分支上看到你的修改，并且继续工作。如果合并出现冲突，那么你就需要解决冲突，并且完成合并操作。

以上四种情况都有各自的优缺点，你可以根据自己的实际情况和喜好选择适合自己的情况。如果你想了解更多关于git切换分支和本地修改的知识和技巧，你可以参考以下链接：

2.3参考资料

Git切换分支和本地修改的知识和技巧，参考：

• Switch branch and ignore any changes without committing：如何在不提交本地修改的情况下切换分支（Stack Overflow问题和回答）
• git switch branch without discarding local changes：如何在不放弃本地修改的情况下切换分支（Stack Overflow问题和回答）
• Git allowing me to switch branches without committing changes：为什么git有时候允许在不提交本地修改的情况下切换分支（Stack Overflow问题和回答）