美文网首页
Git 笔记(七)分支管理策略和 bug 分支、Feature

Git 笔记(七)分支管理策略和 bug 分支、Feature

作者: 红发_SHANKS | 来源:发表于2018-07-11 13:55 被阅读20次

    笔记整理自廖老师的 git 教程

    分支策略管理

    通常我们在合并分支的时候,git 会使用 fast-forward模式类合并,但是这种合并方式有一个缺陷:合并分支以后,删除分支,分支的历史记录就看不到了。为了方便后面查看合并的信息,我们使用 --no-f方式禁用fast-forward 模式,这样,哪怕分支删除了,也能看到历史分支信息

    创建新的分支 dev , 在 README 文件中增加 “ 分支策略管理”字样,然后提交到 dev 分支,切换回 master 分支 合并。

    $ git merge --no-f -m "--no-f  分支管理策略" dev
    Merge made by the 'recursive' strategy.
     README.md | 1 +
     1 file changed, 1 insertion(+)
    
    

    合并以后,查看 分支信息。git log --graph --pretty=oneline --abbrev-commit

    $ git log --graph --pretty=oneline --abbrev-commit
    *   833b087 (HEAD -> master) --no-f 分分支管理策略
    |\
    | * bfd0415  新增分支管理策略文字
    |/
    *   f830213 (origin/master, origin/HEAD) merge
    |\
    | * fe4a7e8 dev
    * | 34ed366 master
    
    

    能够很直观的看出我们在已经被删除的 dev 分支做过 新增分支管理策略文字 这样的 commit 。

    总结
    日常开发中,我们应该只在 dev 分支进行开发,master 分支只用来发布新版本,这样能够最大限度的保持 master 分支的安全性。

    为了能够看出来历史合并消息,在合并分支的时候,加上 --no-f 参数,禁用 git 的 fast-forward 模式。

    bug分支

    我们日常在开发的过程中经常出现这样的情况。历史中某一个版本有 bug 需要紧急修复,现在我们又正在进行新功能的开发。这个时候,我们因为新功能还没有开发完成,不能进行提交,又需要先修复 bug 怎么办呢?

    可以先将当前工作进度保存起来,新建一个分支,修复bug ,然后恢复当前工作进度。下面我们来模拟这个情景。

    我们有一个 README 文件,在其中模拟工作状态。

    这里出现了一个bug.
    
    我们愉快的在 dev 分支进行开发...
    
    开发进度70%...
    
    开发进度80%,组长要求先行修复前面的bug
    

    使用 git stash 保存当前工作进度

    $ git stash
    Saved working directory and index state WIP on dev: 5e44f74 在 dev 分支开发进度进行到了 70%
    
    

    新建一个 issue-66分支,进行bug 修复。

    $ git checkout -b issue-66
    Switched to a new branch 'issue-66'
    
    

    修复bug ,并且提交。

    $ git checkout -b issue-66
    Switched to a new branch 'issue-66'
    ...
    这里出现了一个bug. 对bug 进行了修复
    ...
    $ git add .
    $ git commit -m "修复 bug 66"
    [issue-66 9a864d0] 修复 bug 666
     1 file changed, 1 insertion(+), 1 deletion(-)
    $ checkout dev
    bash: checkout: command not found
    $ git merge --no-f -m "bug修复后合并到 dev 分支" issue-66
    Merge made by the 'recursive' strategy.
     README.md | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    $ git branch -d issue-66
    Deleted branch issue-66 (was 9a864d0).
    
    

    回到 dev 分支,继续进行开发

    // 查看我们保存了哪些工作进度,这里只有一个
    $ git stash list
    stash@{0}: WIP on dev: 5e44f74 在 dev 分支开发进度进行到了 70%
    $ git stash pop
    Auto-merging README.md
    On branch dev
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)
    
            modified:   README.md
    
    no changes added to commit (use "git add" and/or "git commit -a")
    Dropped refs/stash@{0} (3092b5561ec681c11f80de49ec799ecc457d7e21)
    
    

    git stash pop恢复了我们保存的工作场景,并且删除了这个场景,现在看看保存的stash,已经没有未恢复的 stash 了。

    $ git stash list
    

    在恢复 stash 的时候,我们也可以使用 $ git stash apply stash@{0}来指定恢复列表中的哪一个 stash 。

    现在,继续完成我们未完成的新功能吧...

    开发进度80%,组长要求先行修复前面的bug
    
    bug也修复了,继续愉快的开发...
    
    开发进度 100%
    
    $ git add .
    $ git commit -m "新功能开发完成"
    [dev cb75959] 新功能开发完成
     1 file changed, 7 insertions(+), 1 deletion(-)
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 3 commits.
      (use "git push" to publish your local commits)
    $ git merge --no-f -m "新功能开发完成,合并到 mater分支" dev
    Merge made by the 'recursive' strategy.
     README.md | 12 +++++++++++-
     1 file changed, 11 insertions(+), 1 deletion(-)
    
    

    查看我们的合并历史

    $ git log --graph --pretty=oneline --abbrev-commit
    *   b6e3d60 (HEAD -> master) 新功能开发完成,合并到 mater分支
    |\
    | * cb75959 (dev) 新功能开发完成
    | *   6a5ba4c bug修复后合并到 dev 分支
    | |\
    | | * 9a864d0 修复 bug 666
    | |/
    | * 5e44f74 在 dev 分支开发进度进行到了 70%
    |/
    * d2d724d bug 出现
    
    

    可以很清晰的看到,我们在 issue-66 分支修复了 bug ,然后合并到了 dev 分支,接着继续在 dev 分支完成了所有的开发,最后合并到了 master 分支。

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

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

    Feature分支

    我们在 开发新功能的时候,通常是常见一个 feature 分支,类似 bug 分支一样,进行开发,开发完成,合并到 dev 分支。但是如果新功能开发完以后,在合并到 dev 分支以前,公司通知,这个新功能不要了,那么就需要删除这个分支。但是没有合并以前的分支 通过 git branch -d feature-name 是删不掉的,git 会提示我们这样可能丢失数据。我们来试验下。

    // 创建新功能的分支 feature-news
    $ git checkout -b feature-news
    Switched to a new branch 'feature-news'
    
    

    努力开发...

    新功能来了
    
    新功能开发完成了
    

    提交完成。

    git add .
    git commit -m "新功能开发完了"
    [feature-news 0f1af3f]  新功能开发完了
     1 file changed, 5 insertions(+), 1 deletion(-)
    $ git checkout dev
    Switched to branch 'dev'
    // 删除分支的时候,git 提示我们 feature 分支还没有 merge ,如果一定要删除,是用 -D
    $ git branch -d feature-news
    error: The branch 'feature-news' is not fully merged.
    If you are sure you want to delete it, run 'git branch -D feature-news'.
    
    

    根据 git 的提示,进行强制删除

    $ git branch -D feature-news
    Deleted branch feature-news (was 0f1af3f).
    $ git branch
    * dev
      master
    
    

    现在,就只剩下我们的 dev 分支和 master 分支了。

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

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

    相关文章

      网友评论

          本文标题:Git 笔记(七)分支管理策略和 bug 分支、Feature

          本文链接:https://www.haomeiwen.com/subject/uwdhpftx.html