Git 分支管理

使用技巧

更人性化地输出 log 日志

我们可以通过 git log --graph --pretty 命令使得输出的 log 日志更加人性化。

注意，一些我们个人常用但是又比较难以输入的命令，我们可以使用 alias 配置简化其输入。例如命令 git config --global alias.lg "log --graph --pretty" 便将我们上述讲的命令简化为了 git lg ，之后我们只需要输入 git lg 就相当于输入了上面那个命令。

对比差异

我们可以使用 git diff 命令对比两个文件的不同：

• git diff <id1> <id2> 对比两次提交之间的差异,仅输入一个提交 id 时对比本工作区和其的差异。

• git diff <branch1> <branch2> 对比两个分支之间的差异，仅输入一个分支名时对比本工作区和其的差异。

• git diff --staged 对比暂存区和版本库之间的差异，不输入 --staged 参数时对比工作区和暂存区之间的差异。

下图中当前分支和 main 相同，存储库和暂存区相同，只有工作区删除了 lab1-report.pdf 文件。

stash暂存区保存

当我们需要放下手头的工作去处理另一个紧急的事件，但是手头的工作又没完成不能 commit 时，我们可以使用 git stash save '标记' 命令将其暂存区内的状态保存在 list 内。同时，我们还可以通过 git stash list 命令查看保存了的暂存区的状态。

在将紧急事件处理结束后，我们可以使用 git stash apply (stash@{n}) 将队列首(第 n 个)状态恢复，然后使用 git stash drop (stash@{n}) 在 list 内删除此状态(第 n 个状态)。或者我们直接使用 git stash pop 一次性完成上述两步。最后，我们还可以通过 git stash clear 命令完全删除所有暂存状态。

merge 和 rebase 的异同

git merge <分支> 和 git rebase <分支> 都可以合并分支。 但是， merge 不会更改原始 commit 信息的上下文，即 merge 相当于保存了原始分支的情况；而 rebase 会对原始 commit 进行整理，使得合并后的分支看起来如同一直是一个分支一样。

merge 可以保留分支信息用于复原，而 rebase 则让分支图显得更加简洁。所以，在开发中经常是合并到主分支上时使用 merge (这样可以复原主分支的合并情况)，合并到个人开发的分支时使用 rebase (防止分支图变得过于复杂)。

冲突解决

我们先构造一种冲突情况。

我们在master中的test内容为第一排是“111”，第二排是“333”；

我们在main中的test内容为第一排是“111”，第二排是“222”。

冲突之后会在我们的工作区文件内形成冲突的说明，这是需要我们手动解决冲突，待解决之后再次尝试合并，如下：

修改后：

再次尝试合并：

常用分支解决方案

注意：首先明确尽量保证本地分支名和远程仓库对应的分支名相同。

一些远程分支操作：

git branch -r 查看远程分支git push origin :<分支名>删除远程分支

git checkout <分支名> origin/<分支名>将本地不存在的远程分支迁移到本地

Git Flow 分支管理解决方案

流程图：

• Production 分支 即常用的 master 分支，这个分支用于发布不同版本的成品产品。所以通常不在这个分支上进行修改。

• Develop 分支 主开发分支，其内包含所有要发布到下一个 Release 分支的代码。

• Feature 分支 用于一些相对独立的功能的开发，开发完成后合并到 Develop 分支。

• Release 分支 当开发到某一程度时，需要发布新本版，便从 Develop 分支创建一个 Release 分支。在完成发布前准备后，再合并到 Production(master) 分支和 Develop 分支。

• Hotfix 分支 在 Production(master) 分支上发现 bug 时，便创建 Hotfix 分支进行修补，修补完成后合并到 Production(master) 分支和 Develop 分支。

个人开发常常只需要使用 Production(master) 分支和 Develop 分支。

GitHub 上有开源的 Git Flow 工具：gitflow (opens new window)