Git经常使用命令（二）

1、分支管理：

    分支在实际中有什么用呢？假设你准备开发一个新功能，可是须要两周才能完成，第一周你写了50%的代码，若是马上提交，因为代码还没写完，不完整的代码库会致使别人不能干活了。若是等代码所有写完再一次提交，又存在丢失天天进度的巨大风险。如今有了分支，就不用怕了。你建立了一个属于你本身的分支，别人看不到，还继续在原来的分支上正常工做，而你在本身的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工做。

1. 建立与合并分支：

• 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能肯定当前分支，以及当前分支的提交点：；每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也愈来愈长。
•            
• 当咱们建立新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上

            

• 从如今开始，对工做区的修改和提交就是针对dev分支了，好比新提交一次后，dev指针往前移动一步，而master指针不变：

        

• 在dev上的工做完成了，就能够把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
  

        

    1）建立dev分支，而后切换到dev分支：git checkout命令加上-b参数表示建立并切换，而后，用git branch命令查看当前分支。git branch命令会列出全部分支，当前分支前面会标一个*号。而后，就能够在dev分支上正常提交。

$ git checkout -b dev

    2） 切换回master 分支后，提交在dev分支上的内容并无添加到master分支上， 把dev 分支的工做成果合并到master 分支上：git merge 命令用于合并指定分支到当前分支。

    3）合并完成后，就能够放心地删除dev分支了：

$ git branch -d dev

    4） 由于建立、合并和删除分支很是快，因此Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master 分支上工做效果是同样的，但过程更安全。

• 查看分支：git branch

• 删除分支：git branch -d <name>

• 合并某分支到当前分支：git merge <name>

• 建立+切换分支：git checkout -b <name>

• 切换分支：git checkout <name>

• 建立分支：git branch <name>

2、解决冲突

• 当Git没法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
• 用git log --graph命令能够看到分支合并图。

1.  分支管理策略：一般，合并分支时，若是可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

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

• --no-ff方式的git merge：请注意--no-ff参数，表示禁用Fast forward，由于本次合并要建立一个新的commit，因此加上-m参数，把commit描述写进去。

  $ git merge --no-ff -m "merge with no-ff" dev

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

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

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

  你和你的小伙伴们每一个人都在dev分支上干活，每一个人都有本身的分支，时不时地往dev分支上合并就能够了。

2.  bug分支：当接到一个修复一个代号101的bug的任务时，很天然地想建立一个分支issue-101来修复它，可是，等等，当前正在dev上进行的工做尚未提交，Git提供了一个stash功能，能够把当前工做现场“储藏”起来，等之后恢复现场后继续工做。（$git stash），bug修复完成以后能够回到dev分支使用一下命令恢复工做现场：

• 可使用git stash apply恢复，可是恢复后，stash内容并不删除，你须要用git stash drop来删除；

• 另外一种方式是用git stash pop，恢复的同时把stash内容也删了

3.  feature分支：每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。若是在feature完成后没有合并以前，须要删除feature分支，采用强行删除：

$ git branch -D feature-vulcan

• 若是要丢弃一个没有被合并过的分支，能够经过git branch -D <name>强行删除。

4.  远程：当从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，而且，远程仓库的默认名称是origin。要查看远程库的信息，用git remote。

• 推送分支：就是把该分支上的全部本地提交推送到远程库：

  $ git push origin master

• 并非必定要把本地分支往远程推送：

  • master分支是主分支，所以要时刻与远程同步；

  • dev分支是开发分支，团队全部成员都须要在上面工做，因此也须要与远程同步；

  • bug分支只用于在本地修复bug，就不必推到远程了，除非老板要看看你每周到底修复了几个bug；

  • feature分支是否推到远程，取决于你是否和你的小伙伴合做在上面开发。

• 抓取分支：多人协做时，你们都会往master和dev分支上推送各自的修改。从远程库clone时，默认状况下，你的小伙伴只能看到本地的master分支。要在dev分支上开发，就必须建立远程origin的dev分支到本地，因而他用这个命令建立本地dev分支：

  $ git checkout -b dev origin/dev

  如今，他就能够在dev上继续修改，而后，时不时地把dev分支push到远程。
• 你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对一样的文件做了修改，并试图推送：

  $ git push origin dev

  推送失败，由于你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示咱们，先用git pull把最新的提交从origin/dev抓下来，而后，在本地合并，解决冲突，再推送。

  $ git pull

• git pull也失败了，缘由是没有指定本地dev分支与远程origin/dev分支的连接，根据提示，设置dev和origin/dev的连接

  $ git branch --set-upstream dev origin/dev

5.  多人协做的工做模式一般是这样：

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。

3、标签管理：发布一个版本时，一般先在版本库中打一个标签，这样，就惟一肯定了打标签时刻的版本。未来不管何时，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。因此，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（可是分支能够移动，标签不能移动）

• 命令git push origin <tagname>能够推送一个本地标签
• 命令git push origin --tags能够推送所有未推送过的本地标签
• 命令git tag -d <tagname>能够删除一个本地标签
• 命令git push origin :refs/tags/<tagname>能够删除一个远程标签