git 学习随笔

      git 学习

     1.初始化

     初始化一个Git仓库，使用git init命令。

     添加文件到Git仓库，分两步：

          第一步，使用命令git add <file>，注意，可反复多次使用，添加多个文件；
          第二步，使用命令git commit，完成。

 

     2.查看状态

     要随时掌握工作区的状态，使用git status命令。

     如果git status告诉你有文件被修改过，用git diff可以查看修改内容

 

     

     3.版本回退

          HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

          穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
          要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

     

     4.暂存区

         

     5.撤销操作

          场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

          场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。

 

     6.删除

          命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

 

     7.远程仓库

          要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

          关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

          此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

 

     8.从远程仓库中克隆

          git clone 项目地址

          git 支持多种协议，默认的git:// 使用ssh，但是也可以使用https 等协议。

          使用https 除了速度慢之外，还有一个最大的麻烦就是每次推送都必须输入口令，但是某些只开放HTTP端口的公司内部就无法使用ssh 协议而只能使用https。

 

     9.创建分支与合并分支

          在版本回退里，每次提交，GIt 都把他们串成一条时间线，这条时间线就是一个分支。如果只有一条分支就是master 分支，HEAD 严格来说不是指向提交而是指向master，master 才是指向提交的，所以HEAD 指向的就是当前分支。

 

          

          每次提交，master 分支都会向前移动异步，这样随着不断调教，master 分支就会越来越长。

          当我们创建新的分支，例如是dev ，git 创建一个新的指针叫做dev，指向master 相同的提交，再把HEAD 指向dev 就表示当前的分支在dev上。

          

          Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

 

          

     

 

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

            

          合并完成以后甚至于可以删除dev 分支。

 

      

     10.解决冲突

          冲突产生的原因是在于不同的分支修改了相同的文件，以至于合并的时候会有冲突的产生，所以解决冲突就是把这些不同的分支上相同的修改进行人工整合。

 

          

     11.分支管理策略

          通常，合并分支时，如果可能，git 会用Fast forward 模式，但是这种模式下，删除分支后，会丢掉分支的信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

          不使用fast forward 模式，merge后就是这样：

          

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

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

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

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

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

              

 

          Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。