2022/03/31 对分支进行管理

对分支进行管理

为什么需要分支管理？

在实际开发过程中master分支应该是最稳定的。不能再上面干活。所以通常会开辟一个dev分支。每个人在在dev分支下建立自己的开发分支。

概括：

个人开发分支--->指向dev分支--->指向master分支

普通的Git合并方式

Git会用Fast forward模式merge代码，但这种模式下，删除分支后，会丢掉分支信息。

需要禁用这种模式需要在合并的时候加参数：

方式如图所示：

# 创建dev分支
git checkout -b dev
# 新建文件、添加到暂存区、提交到版本库
git add read.txt
git commit -m "新文件"
# 切换到主分支
git checkout master
# 禁用模式合并代码
git merge --no-ff -m "新的提交" dev # 本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

查看分支历史：

git log 

区别在于：

• 之前的合并是直接更改了master的指针指向dev版本
• 此次更改是在master分支上为dev的版本创建了一个节点。然后将dev和master在该版本的后一个版本进行合并

处理Bug分支

简单概述情况：

• 当正在dev分支开发的时候突然需要到master分支修改一个Bug
• dev分支不能提交

Git提供了一个stash的功能用于保存当前的工作区。后续可以恢复。

git stash
# 将工作区暂时保存。此时可以切回主分支在新见一个分支进行bug的处理

修复Bug

# 位于dev分支，为Bug单独创建分支进行修复
git checkout -b Bug-1
# 修复完成后添加到暂存区，提交版本库
git add read.txt
git commit -m "修复了bug"
# 切回主分支，合并
git checkout master
git merge --no-ff -m "修复bug" Bug-1

切回dev分支继续开发，但是此时的工作区是空的。需要手动恢复一下保存的工作区：

git checkout dev
# 查看当前工作区状态
git status
# 恢复保存的工作区。有两种方式：
# 恢复保存的工作区不删除保存的工作区
git stash apply "保存的工作区的标识。git stash list 可以查看" # 手动删除工作区 git stash drop
# 恢复工作区同时删除分支
git stash pop

由于之前的Bug已经在master分支发现并修改说明dev分支也存在该Bug。如何将修改Bug的提交复制到dev分支上？

步骤：

• 位于dev分支
• 找到在master分支上的提交的commit号
• 通过指令将master提交的修改复制一份到dev(这得益于git记录的是每一次修改而不是资源本身的特性)

git checkout dev
# 找到在master分支记录的commit号
git log
# 将修改复制到dev分支
git cherry-pick "commit号"

有了这个支持可以直接在dev分支上修复bug，然后在master分支上“重放”。不过依然需要在master分支保存现场

总结

• 保存工作区指令：git stash
• 回到保存的工作区：git stash apply(此时不会删除该保存)
• 回到保存的工作区同时删除分支：git stash pop 保存的号
• 查看所有保存的工作区：git stash

Feature分支

什么是Feature分支？

研发的日常工作：维护、检测、研发。通常我们都处在dev分支。接到新的开发任务的时候需要进行实际的编码开发。那么最好的做法不是在dev分支进行直接开发而是新建一个分支进行开发

场景举例：

git checkout -b newPoint
# 开发完成
git add new.cpp
git commit -m "新功能"

此时将代码合并到dev分支的时候发现功能作废。所以删除分支：

git checkout dev
# 删除分支
git branch -d newPoint

强行删除分支：

git branch -d <分支名称>

总结

• 强制删除分支：git branch -d <分支名称>

Git多人协作

我们知道Git是通过本地和远程的关联进行交互的。所以我们可以关联多个远程仓库

查看关联的远程仓库：

git remote

可以查看远程仓库更详细的信息：

git remote -v
# 显示了可以抓取和推送的远程仓库地址

可以将代码指定的推送到远端的指定分支(前提是本地的该分支与远端的已经有关联或者远端目前没有当前分支)

git push origin dev

当本地有dev分支，远端也有一个dev分支，但是二者没有建立任何关联。此时进行推送的操作会被拒绝。需要手动设置两个分支的关联：

git branch --set-upstream-to=origin/dev dev

设置本地流到远端流

当多人同时在远端的dev分支上进行开发的时候在每次一条代码之前建议先拉取一遍远端的分支。

# 拉取远端指定分支的提交--->在dev分支下
git pull

总结

• 设置本地流和远端流关联：git branch --set-upstream-to=远端分支 本地分支

Git的标签管理

首先明白标签和commit提交时候带的-m参数说明不一样。标签是会和commit id的数据记录再一起。可以通过git log查看到

给分支或者commit打标签的方法也非常简单：

使用git tag指令

步骤 ：

# 切换到需要打标签的分支
git checkout dev
# 给dev分支打上v1.0的标签
git tag v1.0

这样分支dev就被打上了v1.0的标签

# 查看所有标签
git tag
# 查看标签详细信息
git show <标签名称>
# 给指定的commit id打上标签
git tag "标签内容" "commit id"

在打标签的同时可以添加说明文字：

git tag -a 版本号 -m 内容 "commit id"

总结

• 在HEAD指向的分支新建标签git tag <标签名称> (可选是否指定一个commit id)
• 查看所有标签git tag
• 指定标签携带的信息：git tag -a <标签名> -m "携带的信息内容"

标签的概念和提交不一样。分支或者提交打了标签以后不会随着提交而提交到版本库或者是提交到远端(标签只会在本地存储)。需要自己另外进行推送。删除标签也是同理：

Git操作标签

在创建标签了以后标签实质是存储在本地。所以推送到远端等操作需要另外执行。

将本地标签推送到远端：

git push origin 标签名称
# git push origin <tagname>

删除本地存储的标签：

git tag -d 标签名称

如果想删除远端标签，那么做法是再次进行推送：

git push origin refs/tags/标签名称

总结

• git push origin <tagname>：推送一个本地标签；
• git push origin --tags：推送全部未推送过的本地标签；
• git tag -d <tagname>：删除一个本地标签；
• git push origin :refs/tags/<tagname>：删除一个远程标签。