github 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 git@github.com:LinFengxxxx/Qt.git (fetch)

origin git@github.com: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 <2010947927@qq.com>

Date: Wed Aug 10 20:19:35 2022 +0800

fix bug 101

commit d769829e42bcd8a22e3bdd76b6ffe2534616b7cc

Merge: 4ab0e03 890af29

Author: LinFeng <2010947927@qq.com>

Date: Sun Aug 7 23:18:27 2022 +0800

merged bug fix 101

commit 890af291feee6b40b93151dc60885a4b8a8c0e6a

Author: LinFeng <2010947927@qq.com>

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

推荐链接

 您阅读本篇文章共花了： 

大家都在找：

github：gitlab中文官网入口

git：git基本操作命令