git学习8-分支管理-分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

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

2CXXXX34 /e/pyc_study (master)
□□ start typora
2CXXXX34 /e/pyc_study (master)
□□ git branch
* master
2CXXXX34 /e/pyc_study (master)
□□ git switch -c dev
Switched to a new branch 'dev'
2CXXXX34 /e/pyc_study (dev)
□□

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

2CXXXX34 /e/pyc_study (dev)
□□ ls
main.py  README.md
2CXXXX34 /e/pyc_study (dev)
□□ vim README.md
2CXXXX34 /e/pyc_study (dev)
□□ git status
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
2CXXXX34 /e/pyc_study (dev)
□□ git add README.md
2CXXXX34 /e/pyc_study (dev)
□□ git status
On branch dev
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   README.md

2CXXXX34 /e/pyc_study (dev)
□□ git commit -m "add merge"
[dev 848bcf1] add merge
 1 file changed, 3 insertions(+)
2CXXXX34 /e/pyc_study (dev)
□□

现在，我们切换回master：

2CXXXX34 /e/pyc_study (dev)
□□ git switch master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
2CXXXX34 /e/pyc_study (master)
□□

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

□□ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 README.md | 3 +++
 1 file changed, 3 insertions(+)
2CXXXX34 /e/pyc_study (master)
□□ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
2CXXXX34 /e/pyc_study (master)
□□

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

2CXXXX34 /e/pyc_study (master)
□□ git log --graph --pretty=oneline --abbrev-commit
*   4b678dd (HEAD -> master) merge with no-ff
|\
| * 848bcf1 (dev) add merge
|/
* 4f06dec (origin/master, origin/HEAD) 0423 etc.
*   bdffc59 conflict fixed
|\
| * 53a3d1f AND simple
* | d71bde7 & simple
|/
* 915ed39 branch dev modified
* 2d69ef5 modify main.py from little black
* 40e5382 from carysLaptop little black
* 1aa2f87 README.md 已在 Bitbucket 中，在线编辑过。
* a2252ec modify readme.md
* 5cd5ad8 from haierLaptop PyCharm Ver01
* 2d5f4c7 Initial commit
2CXXXX34 /e/pyc_study (master)
□□

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

git-no-ff-mode

git-no-ff-mode

使用dev分支，再merge，不加--no-ff参数

使用Fast forward

git-br-ff-merge

git-br-ff-merge

2CXXXX34 /e/pyc_study (master)
□□ git switch dev
Switched to branch 'dev'
2CXXXX34 /e/pyc_study (dev)
□□ vim README.md
2CXXXX34 /e/pyc_study (dev)
□□ git add README.md
2CXXXX34 /e/pyc_study (dev)
□□ git commit -m "edit by dev 2nd"
[dev 3e87d02] edit by dev 2nd
 1 file changed, 1 insertion(+)
2CXXXX34 /e/pyc_study (dev)
□□ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
2CXXXX34 /e/pyc_study (master)
□□ vim README.md            # 查看
2CXXXX34 /e/pyc_study (master)
□□ git merge dev
Merge made by the 'recursive' strategy.   # 之前学习的merge：Updating 2d69ef5..915ed39 <br /> Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
2CXXXX34 /e/pyc_study (master)
□□ vim README.md
2CXXXX34 /e/pyc_study (master)
□□ git log --graph --pretty=oneline --abbrev-commit
*   04ab191 (HEAD -> master) Merge branch 'dev'
|\
| * 3e87d02 (dev) edit by dev 2nd
* | 4b678dd merge with no-ff
|\|
| * 848bcf1 add merge
|/
* 4f06dec (origin/master, origin/HEAD) 0423 etc.
*   bdffc59 conflict fixed
|\
| * 53a3d1f AND simple
* | d71bde7 & simple
|/
* 915ed39 branch dev modified
* 2d69ef5 modify main.py from little black
* 40e5382 from carysLaptop little black
* 1aa2f87 README.md 已在 Bitbucket 中，在线编辑过。
* a2252ec modify readme.md
* 5cd5ad8 from haierLaptop PyCharm Ver01
* 2d5f4c7 Initial commit
2CXXXX34 /e/pyc_study (master)
□□

Merge made by the 'recursive' strategy.

git的合并策略总共有3种，一种是resovle，一种是recursive，一种是octopus。其中resolve和recursive适用于合并2个branch，octopus适用于合并3个或者3个以上的branch。

创新新分支，使用Fast-forward模式merge，对比

2CXXXX34 /e/pyc_study (master)
□□ git switch -c feature2
Switched to a new branch 'feature2'
2CXXXX34 /e/pyc_study (feature2)
□□ vim README.md
2CXXXX34 /e/pyc_study (feature2)
□□ vim README.md
2CXXXX34 /e/pyc_study (feature2)
□□ git add README.md
2CXXXX34 /e/pyc_study (feature2)
□□ git commit -m "edit by feature2 for merge to master"
[feature2 89272a1] edit by feature2 for merge to master
 1 file changed, 3 insertions(+)
2CXXXX34 /e/pyc_study (feature2)
□□ git swtich master
git: 'swtich' is not a git command. See 'git --help'.

The most similar command is
        switch
2CXXXX34 /e/pyc_study (feature2)
□□ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)
2CXXXX34 /e/pyc_study (master)
□□ git merge feature2
Updating 04ab191..89272a1
Fast-forward
 README.md | 3 +++
 1 file changed, 3 insertions(+)
2CXXXX34 /e/pyc_study (master)
□□ git log --graph --pretty=oneline --abbrev-commit
* 89272a1 (HEAD -> master, feature2) edit by feature2 for merge to master #仅增加了这一行。
*   04ab191 Merge branch 'dev'
|\
| * 3e87d02 (dev) edit by dev 2nd
* | 4b678dd merge with no-ff
|\|
| * 848bcf1 add merge
|/
* 4f06dec (origin/master, origin/HEAD) 0423 etc.
*   bdffc59 conflict fixed
|\
| * 53a3d1f AND simple
* | d71bde7 & simple
|/
* 915ed39 branch dev modified
* 2d69ef5 modify main.py from little black
* 40e5382 from carysLaptop little black
* 1aa2f87 README.md 已在 Bitbucket 中，在线编辑过。
* a2252ec modify readme.md
* 5cd5ad8 from haierLaptop PyCharm Ver01
* 2d5f4c7 Initial commit
2CXXXX34 /e/pyc_study (master)
□□

git log --graph --pretty=oneline --abbrev-commit 比较

Fast-forward merge:

* 89272a1 (HEAD -> master, feature2) edit by feature2 for merge to master

--no-ff merge:

*   4b678dd (HEAD -> master) merge with no-ff
|\
| * 848bcf1 (dev) add merge
|/

从分支历史上就可以看出分支信息。

分支策略

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

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

git-br-policy

git-br-policy

小结

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

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

posted on 2021-04-25 16:39  carysun  阅读(176)  评论(0)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 carysun
Powered by .NET 8.0 on Kubernetes