（六）GIT-分支管理_gitlab测试bug是针对分支的码

分支介绍(来自廖雪峰老师教学文档)

      分支在实际中有什么⽤用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你 写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再⼀次提交，又存在丢失每天进度的巨大⻛风险。 现在有了分⽀支，就不⽤用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。 其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。 但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
 

1、一开始的时候只有master分支，是一条线，Git⽤用master指向新的提交，再⽤用HEAD指向 master，就能确定当前分支，以及当前分支的提交点：每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

            

2、当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交， 再把HEAD指向dev，就表示当前分支在dev上：.你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

              

3、不过从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev 指针往前移动一步，而master指针不变：

               

4、假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

              

5、所以Git合并分支也很快！就改改指针，工作区内容也不变！ 合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分⽀支：

                   

分支管理策略

通常，合并分⽀支时，如果可能，Git会⽤用“Fast forward”模式，但这种模式下，删除分支 后，会丢掉分支信息。 如果要强制禁⽤用“Fast forward”模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。 下面我们实战一下--no-ff⽅方式的merge： 
1、⾸首先，仍然创建并切换dev分支： 
        git checkout -b dev
2、修改readme.txt⽂文件，并提交一个新的commit
        git add readme.txt 
        git commit -m "add merge" 
3、现在，我们切换回master： 
        git checkout master
4、准备合并dev分支，请注意--no-ff参数，表示禁用“Fast forward”： 因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。 
        git merge --no-ff -m "merge with no-ff" dev 
5、合并后，我们用git log看看分支历史： 可以看到，不使用“Fast forward”模式，merge后就像这样：
        git log --graph --pretty=oneline --abbrev-commit 

         

          

 

6、实际工作总看起来就像这样

                

 

bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的 强大，所以，每个bug都可以通过⼀个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。 当你接到一个修复代号101的bug的任务时，很自然地，你想创建一个分支issue -01来修复它，但是，等等，当前正在dev上进行的工作还没有提交： 并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是， 必须在两个小时内修复该bug，怎么办？ 幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后 继续工作

1、此时在dev分支，先执行git命令储存分支：git stash

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

2、首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

          git checkout master
          git checkout -b issue-01

3、修改完bug后提交：git commit -m "fix bug 10"  test.txt

4、修复完成后，切换到master分支，并完成合并，后删除issue-01分支，bug修复完成

         git checkout master
         git merge --no-ff -m "merged bug fix 101" issue-01
         git branch -d issue-01

5、bug修复完成之后，是时候回到dev分支去干活了

         git checkout dev：工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看
         git stash list  ： stash@{0}: WIP on dev: 6224937 add merge
         工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法： 一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除； 另一种方式是用git stash pop，恢复的同时把stash内容也删了

          git stash pop

6、你可以多次stash，恢复的时候，先⽤用git stash list查看，然后恢复指定的stash

         git stash apply stash@{0}

 

Feature分⽀支

软件开发中，总有无穷无尽的新的功能要不断添加进来。 添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，好新建一个feature分支，在上面开发，完成后，合并后，删除该 feature分⽀支。 现在，你终于接到了一个新任务：开发代号为Vulcan的新功能。 于是准备开发：

1、git checkout -b feature-vulcan

2、开发完毕：切回dev，准备合并：

        git checkout dev 

3、⼀切顺利的话，feature分支和bug分支是类似的，合并，然后删除。 但是， 就在此时，接到上级命令，因经费不足，新功能必须取消！ 虽然白干了，但是这个分支还是必须就地销毁 

         git branch -d feature-vulcan 

        

4、销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改， 如果要强行删除，需要使用命令

         git branch -D feature-vulcan

 

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。 
要查看远程库的信息，用git remote： 
       $ git remote 
          origin 
或者，⽤用git remote -v显⽰示更详细的信息： 
       $ git remote -v 
          origin  git@github.com:michaelliao/learngit.git (fetch) 
          origin  git@github.com:michaelliao/learngit.git (push) 
上⾯面显⽰示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

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

        git push origin master 

如果要推送其他分⽀支，⽐比如dev，就改成

        git push origin dev 

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
       • master分支是主分支，因此要时刻与远程同步； 
       • dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； 
       • bug分支只⽤用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug； 
       • feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。 
    总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

 

抓取分支：多人协作时，大家都会往master和dev分支上推送各自的修改。 现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

         git clone git@github.com:michaelliao/learngit.git 

当你的⼩伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分⽀支。可以⽤用git branch命令看看：

        git branch

        * master 

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

        git checkout -b dev origin/dev 

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程： 

如果git pull失败

      

原因是没有指定本地dev分⽀与远程origin/dev分支的链接，根据提示， 设置dev和origin/dev的链接，再pull就可以了： 

      git branch --set-upstream dev origin/dev

因此，多人协作的工作模式通常是这样： 
      1. ⾸首先，可以试图⽤用git push origin branch-name推送自己的修改； 
      2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并； 
      3. 如果合并有冲突，则解决冲突，并在本地提交； 
      4. 没有冲突或者解决掉冲突后，再⽤用git push origin branch-name推送就能成功！
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，⽤用命令git branch --set-upstream branch-name origin/branch-name。这就是多人协作的工作模式，一旦熟悉了，就非简单。
 

 在远程又创建了一个remotetest分支执行一下命令

        git fetch origin remotetest     和远程的remotetest 分支联系（没有这步貌似也可以）
        git checkout -b remotetest origin/remotetest
        git push origin/remotetest

在本地dev分支的基础上创建一个mytest分支然后将此分支推送到git上
        git branch mytest  ：创建mytest分支
        git checkout mytest ：切换到mytest分支
        git push origin mytest ：将本地mytest分支推送到远程
直接拉取远程dev分支  
        git clone -b dev https://git.oschina.net/search/bigpay.git

 

注意：

我本地有master分支关联远程master分支，和test分支关联test分支，本地master分支有修改，本地test分支也有修改；

此时我本地在test分支，在test分支执行 git push 或者git push origin test都可表示把本地test分支上的修改推送到远程test分支，如果在本地test分支下执行git push origin master则是将本地master分支下的修改推送到远程master分支上，而不是把本地test分支上的修改推送到远程的master分支，但即便是这样如果想推送本地master分支上的修改，还是建议切换到本地master分支后再去推送。