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后就像这样

分支策略

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

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

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

小结

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的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。