关于git:git分支间切换注意点和bug分支的处理

45次阅读

共计 6536 个字符,预计需要花费 17 分钟才能阅读完成。

git 分支间切换留神点和 bug 分支的解决

[toc]

备注:

本文参考于廖雪峰老师的博客 Git 教程。按照其博客进行学习和记录,感激其自私分享,也欢送各位查看原文。

知识点

  • 以后一个分支上批改文件或目录后,在没有提交前,任何一个分支的状态 (git status) 都会同步为一样
  • 合并或切换分支工作,肯定是在以后分支提交后,或者应用 git stash 将以后暂存区状态保留下来之后进行,即以后分支 git status 显示为洁净的仓库再切换
  • 同时批改了同一个工作区雷同文件,因为 Git 治理版本是通过挪动 HEAD 指针,工作区的批改对于挪动到不同分支的指针是一样的。此时 masterdev分支 git add 增加到暂存区,git status在不同分支状态是一样的,如果 master 分支先 commit,两头所做的批改,会全副算作master 的批改(因为 dev 没有提交,仅仅 add 增加了暂存区,两头的批改在切换分支提交后会在 dev 分支失落,但所有批改都存在于 master 的提交中)。故:理论开发中肯定要提交或者暂存以后暂存区的状态后,再切换分支进行其余批改,否则在本分支所做批改的状态会失落。
  • git stash对于 git 没有治理的文件状态不会保留(新创建或批改没有增加过的文件)。
  • git stash list查看 stash 的列表
  • git stash pop复原 stash 到以后分支,并删除stash
  • git stash apply,git stash drop复原 stash 和删除stash
  • git stash apply stash@{0}复原指定的 stash 到以后分支。

记一次分支合并问题情况

从分支点开始,不同分支批改工作区的内容(不增加到暂存区和提交),切换分支,工作区的内容是一样的。

这一点也证实了,Git 批改的是 HEAD 斧正,而不是文件

如下:

  • git status查看 dev 分支上 Git 的状态,洁净工作区
  • 切换到 mster,查看 Git 状态,洁净工作区
$ git status
位于分支 dev
无文件要提交,洁净的工作区
$ git checkout master
切换到分支 'master'
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)无文件要提交,洁净的工作区
  • master 分支下,批改 readme 文件,查看状态,和切换到 dev 分支下,常看状态。疏忽近程分支的提醒。
$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt
批改尚未退出提交(应用 "git add" 和 / 或 "git commit -a")$ git checkout dev
M    readme.txt
切换到分支 'dev'
$ git status
位于分支 dev
尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt
批改尚未退出提交(应用 "git add" 和 / 或 "git commit -a")

必须在提交或者暂存以后暂存区的状态后,再切换或合并分支

工作区的批改对于不同分支是一样的:

同时批改了同一个工作区雷同文件,因为 Git 治理版本是通过挪动 HEAD 指针,工作区的批改对于挪动到不同分支的指针是一样的。此时 masterdev分支 git add 增加到暂存区,git status在不同分支状态是一样的,如果 master 分支先 commit,两头所做的批改,会全副算作master 的批改(因为 dev 没有提交,仅仅 add 增加了暂存区,两头的批改在切换分支提交后会在 dev 分支失落,但所有批改都存在于 master 的提交中)。故:理论开发中肯定要提交或者暂存以后暂存区的状态后,再切换分支进行其余批改,否则在本分支所做批改的状态会失落。

同理,合并分支也一样,必须在提交或者暂存以后暂存区状态后,再进行分支的合并。

如下为批改工作区或增加到暂存区后对 git 分支切换和提交的整体测试:

  • 如下, master分支上批改readme,查看状态,
$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt
批改尚未退出提交(应用 "git add" 和 / 或 "git commit -a")
  • 切换到 dev 查看状态,
$ git checkout dev
M    readme.txt
切换到分支 'dev'
$ git status
位于分支 dev
尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt
批改尚未退出提交(应用 "git add" 和 / 或 "git commit -a")
  • dev 分支上批改 readme 文件,切换到 master 分支,查看内容
$ git checkout master
M    readme.txt
切换到分支 'master'
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)$ cat readme.txt
`this is a test that I learning and use git version control system
this is a beginning
wofaidognyixie dognxi
create two new branch
Creating a new branch is quick and simple.
add a new branch
master modify
dev modify
  • master 分支上将批改增加到暂存区,查看状态
$ git add readme.txt
$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)批改:readme.txt
  • 切换到 dev 分支,批改 readme 文件后,切换回 master 分支,查看状态。会呈现工作区的批改提醒
$ git checkout dev
M    readme.txt
切换到分支 'dev'
$ git checkout master
M    readme.txt
切换到分支 'master'
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)批改:readme.txt
尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt
  • 切换回 dev 分支,git add增加在存储区后,查看状态, 状态为暂存(未提交)
$ git checkout dev
M    readme.txt
切换到分支 'dev'
$ git add readme.txt
$ git status
位于分支 dev
要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)批改:readme.txt
  • 切换回 master 分支,git status查看状态也为暂存(未提交)
$ git checkout master
M    readme.txt
切换到分支 'master'
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)liu@liu-virtual-machine:~/gitTest$ git status
位于分支 master
您的分支当先 'origin/master' 共 8 个提交。(应用 "git push" 来公布您的本地提交)要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)批改:readme.txt
  • master 分支提交,查看状态,显示无文件要提交,工作区洁净
$ git commit -m"commit master"
[master 1ba95a4] commit master
 1 file changed, 2 insertions(+)
$ git status
位于分支 master
您的分支当先 'origin/master' 共 9 个提交。(应用 "git push" 来公布您的本地提交)无文件要提交,洁净的工作区
  • 切换到 dev 分支,工作区状态为洁净,暂存区无提交,如下。
$ git checkout dev
切换到分支 'dev'
$ git status
位于分支 dev
无文件要提交,洁净的工作区
  • 此时,别离在 masterdev分支先查看 readme 文件内容

dev分支,显示为所有改变之前的内容

master分支下的 readme 文件内容为最新(蕴含在 dev 分支下批改和增加到暂存区的内容)

超前提交的分支无奈合并落后版本的分支(即无奈倒退到未提交过的分支状态)

目前所知,依附分支之间的合并(merge)无奈实现版本倒退 (兴许有方法,未进行深入研究),只能通过git reset --hard commit_id 实现版本回退。

master 上新建分支 dev,而后批改master 上内容,并增加提交,此时 master 的版本比 dev 版本要高,如果此时想把 dev(分支的低版本)合并到master 上会产生什么呢?

  • master如果更新后(更新后的上游分支),试图将未进行更新的 dev 分支合并到以后分支,会提醒必须给出一个提交信息解释此合并,否则会终止合并提交

输出正当解释后,会再一次确认存储缓冲区的更改

如下为操作实现后的终端状态

$ git merge dev
Merge made by the 'recursive' strategy.
 testOndev.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 testOndev.txt

然而查看文件内容,并没有回到原先状态。

倒退合并失败,其实这种状况应该应用版本回退

  • 即便应用 --no-ff 参数,应用一般模式合并,如下:
$ git merge --no-ff -m"merge backup" dev
Already up-to-date.

文件内容仍然放弃和 master 统一,没有合并到 dev 分支状态。

解决:应用版本回退git reset --hard commit_id,能够实现理论的批改。

$ git reset --hard a7d3eb7
HEAD 当初位于 a7d3eb7 fixed conflict

内容批改。

bug 分支

有了下面切换分支和合并失败的经验,就不难理解上面的操作了。

软件开发中,bug总是在你想到和想不到的失常状况和意外状况下呈现。修复bug,在 Git 中齐全能够通过建设一个长期分支来修复,修复后合并分支即可。

然而当你正在开发时,对于忽然接到一个修复 bug 的工作,因为以后开发 (dev 分支)没有实现,dev上的工作可能还没有提交。

此时如果想创立一个长期分支 issue10 修复 master 分支的bug

查看 Git 状态如下:

$ git status
位于分支 dev
要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)新文件:newFile

尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt

因为没有开发完,可能临时无奈提交

暂存以后暂存区的状态

  • Git 提供了一个 stash 性能,能够把以后暂存区工作状态“储备”起来,等当前复原现场后持续工作。
$ git stash
Saved working directory and index state WIP on dev: 0df6e43 Merge branch 'dev'
HEAD 当初位于 0df6e43 Merge branch 'dev'
  • 查看状态,显示无文件要提交,工作区也是洁净的。
$ git status
位于分支 dev
无文件要提交,洁净的工作区

注:git stash对于 git 没有治理的文件状态不会保留(新创建没有增加过的文件)。

  • 确定从哪个分支上修复 bug,当初在master 分支上修复,切换并新建分支issue10
$ git checkout master
切换到分支 'master'
您的分支当先 'origin/master' 共 13 个提交。(应用 "git push" 来公布您的本地提交)$ git checkout -b issue10
切换到一个新分支 'issue10'
$ cat readme.txt

`this is a test that I learning and use git version control system
this is a beginning
wofaidognyixie dognxi
create two new branch
Creating a new branch is quick and simple.
add a new branch
master modify
dev modify again commit on master

如上为 readme 内容,将 master modify 改为modify on master, 提交

$ git add readme.txt
$ git commit -m"fixed a bug"
[issue10 afc33ef] fixed a bug
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到 master 分支并合并。最初删除 issue10 分支

$ git checkout master
切换到分支 'master'
您的分支当先 'origin/master' 共 13 个提交。(应用 "git push" 来公布您的本地提交)$ git merge --no-ff -m"merged fixed bug" issue10
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue10
已删除分支 issue10(曾为 afc33ef)。

bug批改实现后,当初回到 dev 分支接着开发,此时 dev 的状态是洁净的。

$ git checkout dev
切换到分支 'dev'
$ git status
位于分支 dev
无文件要提交,洁净的工作区
  • 应用 git stash list 查看暂存的状态
$ git stash list
stash@{0}: WIP on dev: 0df6e43 Merge branch 'dev'

复原暂存起来的状态

  • git stash apply 复原,但复原后,stash内容并不删除,须要用 git stash drop 来删除
  • 应用 git stash pop, 复原的同时会把stash 内容也删除。
$ git stash pop
位于分支 dev
要提交的变更:(应用 "git reset HEAD < 文件 >..." 以勾销暂存)新文件:newFile

尚未暂存以备提交的变更:(应用 "git add < 文件 >..." 更新要提交的内容)(应用 "git checkout -- < 文件 >..." 抛弃工作区的改变)批改:readme.txt

抛弃了 refs/stash@{0} (90a1bdda8ec2c4d1a2833b45ffa2a0be3f2af670)

能够屡次 stash,复原的时候,先用git stash list 查看,而后用 git stash apply 指定复原到哪个状态

$ git stash apply stash@{0}

正文完
 0