Git分支管理笔记(下)

四.分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息

实战--no-ff方式的git merge禁用fast forward 模式

首先,仍然创建并切换dev分支

凌风@▒▒▒plus MINGW64 ~ (main)
$ git switch -c dev
Switched to a new branch 'dev'

修改readme.txt文件,并提交一个新的commit

凌风@▒▒▒plus MINGW64 ~ (dev)
$ vi readme.txt
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git add readme.txt
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git commit -m"add merge"
[dev ce4820a] add merge
 1 file changed, 1 insertion(+), 1 deletion(-)

现在,我们切换回main

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git switch main
Switched to branch 'main'
Your branch is ahead of 'origin/main' by 4 commits.
  (use "git push" to publish your local commits)

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward

凌风@▒▒▒plus MINGW64 ~ (main)
$ git merge --no-ff -m"merge with no-ff" dev
Merge made by the 'ort' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去。合并后,我们用git log看看分支历史

凌风@▒▒▒plus MINGW64 ~ (main)
$ git log --graph --pretty=oneline --abbrev-commit
*   4ab0e03 (HEAD -> main) merge with no-ff
|\
| * ce4820a (dev) add merge
|/
*   927fe64 conflict fixed
|\
| * 1256ca3 AND simple
* | f059fde & simple
|/
* 2df8fcc branch test
* 0baf1fe (origin/main) add test.txt
* 4541db5 remove test.txt
* c8a038f add test.txt
* 9ccdba9 it is terrible
* 4c7b91a wrote a readme tet

可以看到,不使用Fast forward模式,merge后就像这样

Git分支管理笔记(下)_第1张图片

分支策略

在实际开发中,应该按照几个基本原则进行分支管理

首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;

你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。所以,团队合作的分支看起来就像这样

Git分支管理笔记(下)_第2张图片

小结

Git分支十分强大,在团队开发中应该充分应用。

合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并

五.Bug分支

问题

软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除

实例

当我们接到一个修复一个代号101的bug的任务时,就创建一个分支issue-101来修复它,但是,当前正在dev上进行的工作还没有提交

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git status
On branch dev
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   readme.txt
Untracked files:
  (use "git add ..." to include in what will be committed)
        .bash_history
        .git-for-windows-updater
        .gitconfig
        .lesshst
        .ssh/
        .viminfo
        gitskills/
        learngit/

工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?

幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash
Saved working directory and index state WIP on dev: d769829 merged bug fix 101
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git branch
* dev
  main
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git cherry-pick 8937562
error: Your local changes to the following files would be overwritten by merge:
        readme.txt
Please commit your changes or stash them before you merge.
Aborting
fatal: cherry-pick failed

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

首先确定要在哪个分支上修复bug,假定需要在main分支上修复,就从main创建临时分支issue-101

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git checkout main
Switched to branch 'main'
Your branch is ahead of 'origin/main' by 8 commits.
  (use "git push" to publish your local commits)
凌风@▒▒▒plus MINGW64 ~ (main)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug,然后提交

凌风@▒▒▒plus MINGW64 ~ (issue-101)
$ vi readme.txt
凌风@▒▒▒plus MINGW64 ~ (issue-101)
$ git add readme.txt
凌风@▒▒▒plus MINGW64 ~ (issue-101)
$ git commit -m "fix bug 101"
[issue-101 8937562] fix bug 101
 1 file changed, 1 insertion(+)

修复完成后,切换到main分支,并完成合并,最后删除issue-101分支

凌风@▒▒▒plus MINGW64 ~ (issue-101)
$ git switch main
Switched to branch 'main'
Your branch is ahead of 'origin/main' by 8 commits.
  (use "git push" to publish your local commits)
凌风@▒▒▒plus MINGW64 ~ (main)
$ git merge --no-ff -m"merged bug fix 101" issue-101
Merge made by the 'ort' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)
我用
凌风@▒▒▒plus MINGW64 ~ (main)
$ git merge --no-ff -m"merged bug fix 101" issue-101
这个命令删不了issue-101分支,最后是直接凌风@▒▒▒plus MINGW64 ~ (dev)
$ git branch -D issue-101
Deleted branch issue-101 (was 8937562).

bug修复完接着回到dev分支干活,发现工作区是干净的,用git stash list命令查看工作现场存到哪里了

凌风@▒▒▒plus MINGW64 ~ (main)
$ git switch dev
Switched to branch 'dev'
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git status
On branch dev
Untracked files:
  (use "git add ..." to include in what will be committed)
        .bash_history
        .git-for-windows-updater
        .gitconfig
        .lesshst
        .ssh/
        .viminfo
        gitskills/
        learngit/
nothing added to commit but untracked files present (use "git add" to track)

工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:

1、用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash apply
error: Your local changes to the following files would be overwritten by merge:
        readme.txt
Please commit your changes or stash them before you merge.
Aborting
On branch dev
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   readme.txt
Untracked files:
  (use "git add ..." to include in what will be committed)
        .bash_history
        .git-for-windows-updater
        .gitconfig
        .lesshst
        .ssh/
        .viminfo
        gitskills/
        learngit/
no changes added to commit (use "git add" and/or "git commit -a")
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash drop
Dropped refs/stash@{0} (d82448327237f656470cb7740d964c423695dc2e)

2、用git stash pop,恢复的同时把stash内容也删了

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash pop
On branch dev
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   readme.txt

Untracked files:
  (use "git add ..." to include in what will be committed)
        .bash_history
        .git-for-windows-updater
        .gitconfig
        .lesshst
        .ssh/
        .viminfo
        gitskills/
        learngit/
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (1fc9dda0d02d5e0f39a69d37d5e941b523abc562)

可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令$ git stash apply stash@{0}

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash list
stash@{0}: WIP on dev: d769829 merged bug fix 101
stash@{1}: WIP on dev: ce4820a add merge
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash list
stash@{0}: WIP on dev: ce4820a add merge
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash list

main分支的bug被修复后,由于dev分支是早期从main分支分出来的,所以,这个bug其实在当前dev分支上也存在,如何修复在dev分支上同样的bug,不是重复操作一次

同样的bug,要在dev上修复,我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意:我们只需要复制4c805e2 fix bug 101这个提交所做的修改,并不是把整个main分支merge过来。

为了方便操作,Git专门提供了一个cherry-pick命令,让我们能复制一个特定的提交到当前分支

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git stash
Saved working directory and index state WIP on dev: d769829 merged bug fix 101
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git cherry-pick 8937562
[dev ff0c78c] fix bug 101
 Date: Wed Aug 10 20:19:35 2022 +0800
 1 file changed, 1 insertion(+)

Git自动给dev分支做了一次提交,注意这次提交的commit是1d4b803,它并不同于main的4c805e2,因为这两个commit只是改动相同,但确实是两个不同的commit。用git cherry-pick,我们就不需要在dev分支上手动再把修bug的过程重复一遍

既然可以在main分支上修复bug后,在dev分支上可以“重复”这个修复过程,那么在dev分支上修复bug,然后在main分支上“重复”行不行?当然可以,不过仍然需要git stash命令保存现场,才能从dev分支切换到main分支

小结

修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删

当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场;

在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick 命令,把bug提交的修改“复制”到当前分支,避免重复劳动

六.Feature分支

问题

加一个新功能时,不能因为一些实验性质的代码而把主分支搞乱,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git switch -c feature-vulcan
Switched to a new branch 'feature-vulcan'

实操

开发代号为Vulcan的新功能

凌风@▒▒▒plus MINGW64 ~ (feature-vulcan)
$ vi vulcan.py
凌风@▒▒▒plus MINGW64 ~ (feature-vulcan)
$ git add vulcan.py
warning: in the working copy of 'vulcan.py', LF will be replaced by CRLF the next time Git touches it
凌风@▒▒▒plus MINGW64 ~ (feature-vulcan)
$ git status
On branch feature-vulcan
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        new file:   vulcan.py
Untracked files:
  (use "git add ..." to include in what will be committed)
        .bash_history
        .git-for-windows-updater
        .gitconfig
        .lesshst
        .ssh/
        .viminfo
        gitskills/
        learngit/

开发完毕后,切回dev,准备合并

凌风@▒▒▒plus MINGW64 ~ (feature-vulcan)
$ git commit -m"add feature vulcan"
[feature-vulcan f745ce0] add feature vulcan
 1 file changed, 1 insertion(+)
 create mode 100644 vulcan.py
凌风@▒▒▒plus MINGW64 ~ (feature-vulcan)
$ git switch dev
Switched to branch 'dev'

feature分支和bug分支是类似的,可以直接合并,删除,但是此时因为某些原因新功能必须取消!这个包含资料的分支还必须就地销毁

销毁失败。Git提醒,feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用大写的-D参数,我们强行删除

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was f745ce0).

小结

开发一个新feature,最好新建一个分支

如果要丢弃一个没有被合并过的分支,可以通过git branch -D 强行删除。

七.多人协作

当从远程仓库克隆时,实际上Git自动把本地的main分支和远程的main分支对应起来了,且远程仓库的默认名称是origin。

实操

要查看远程库的信息,用git remote

用git remote -v显示了可以抓取和推送的origin的地址如果没有推送权限,就看不到push的地址。

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git remote
origin
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git remote -v
origin  [email protected]:LinFengxxxx/Qt.git (fetch)
origin  [email protected]:LinFengxxxx/Qt.git (push)

推送分支

把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上

用语句$ git push origin (分支名)

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git push origin main
Enumerating objects: 25, done.
Counting objects: 100% (25/25), done.
Delta compression using up to 12 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (24/24), 2.37 KiB | 808.00 KiB/s, done.
Total 24 (delta 8), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (8/8), done.
To github.com:LinFeng0113/Qt.git
   0baf1fe..b440578  main -> main

并不是一定要把本地分支往远程推送

需要远程推送的:

master分支是主分支,因此要时刻与远程同步;

dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步

不需要远程推送的:

bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug

feature分支是否推到远程,取决于我们是否有合作在上面开发

抓取分支

实战

此处需要再找目录做,我就不写这部分代码了,这部分可以多看看老师的代码

https://www.liaoxuefeng.com/wiki/896043488029600/900375748016320

1多人协作时,大家都会往master和dev分支上推送各自的修改
2别人从远程库clone时,默认情况下,他只能看到本地的master分支。你可以用git branch命令看看是否成立
3现在,开发伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支
4 现在,他就可以在dev上继续修改,然后,时不时地把dev分支push到远程:
5 他已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:
6 此时就会推送失败,因为他的最新提交和你试图推送的提交有冲突,解决办法是先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:
7 git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接再pull:
8 这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push:

通常工作模式

首先,用git push origin 推送自己的修改;
如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用git push origin 推送就能成功!
如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/

小结

查看远程库信息,使用git remote -v;

本地新建的分支如果不推送到远程,对其他人就是不可见的;

从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;

在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;

建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;

从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。

八.Rebase

问题

多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的不得不先pull,在本地合并,然后才能push成功。因此看上去很乱,如何将之整成一条直线呢

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git log --graph --pretty=oneline --abbrev-commit
* ff0c78c (HEAD -> dev) fix bug 101
*   d769829 merged bug fix 101
|\
| * 890af29 fix bug 101
|/
*   4ab0e03 merge with no-ff
|\
| * ce4820a add merge
|/
*   927fe64 conflict fixed
|\
| * 1256ca3 AND simple
* | f059fde & simple
|/
* 2df8fcc branch test
* 0baf1fe add test.txt
* 4541db5 remove test.txt
* c8a038f add test.txt
* 9ccdba9 it is terrible
* 4c7b91a wrote a readme tet

实操

先和远程分支同步,对hello.py这个文件做了两次提交。用git log命令看看:

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git push origin main
Everything up-to-date
凌风@▒▒▒plus MINGW64 ~ (dev)
$ vi hello.py
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git add hello.py
warning: in the working copy of 'hello.py', LF will be replaced by CRLF the next time Git touches it
凌风@▒▒▒plus MINGW64 ~ (dev)
$ vi hello.py
凌风@▒▒▒plus MINGW64 ~ (dev)
$ git add hello.py
warning: in the working copy of 'hello.py', LF will be replaced by CRLF the next time Git touches it

这里不能直接git log ,git log 是查看提交历史,此时退出需要按字母q

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git log
commit ff0c78c5fedaeed9683ebcd3cbcb7cd8a41bf476 (HEAD -> dev)
Author: LinFeng <[email protected]>
Date:   Wed Aug 10 20:19:35 2022 +0800

    fix bug 101
commit d769829e42bcd8a22e3bdd76b6ffe2534616b7cc
Merge: 4ab0e03 890af29
Author: LinFeng <[email protected]>
Date:   Sun Aug 7 23:18:27 2022 +0800
    merged bug fix 101
commit 890af291feee6b40b93151dc60885a4b8a8c0e6a
Author: LinFeng <[email protected]>
Date:   Sun Aug 7 23:17:39 2022 +0800
    fix bug 101
...................................................
...................................................

应该用$ git log --graph --pretty=oneline --abbrev-commit

凌风@▒▒▒plus MINGW64 ~ (dev)
$ git log --graph --pretty=oneline --abbrev-commit
* ff0c78c (HEAD -> dev) fix bug 101
*   d769829 merged bug fix 101
|\
| * 890af29 fix bug 101
|/
*   4ab0e03 merge with no-ff
|\
| * ce4820a add merge
|/
*   927fe64 conflict fixed
|\
| * 1256ca3 AND simple
* | f059fde & simple
|/
* 2df8fcc branch test
* 0baf1fe add test.txt
* 4541db5 remove test.txt
* c8a038f add test.txt
* 9ccdba9 it is terrible
* 4c7b91a wrote a readme tet

(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置

此处因为没人跟我抢,就不会出现本地提交不起的问题,如果出现如何解决可以再仔细看看老师的

https://www.liaoxuefeng.com/wiki/896043488029600/1216289527823648

小结

rebase操作可以把本地未push的分叉提交历史整理成直线;

rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。

你可能感兴趣的:(Git入门学习笔记,github,git)