git

Posted 2020-11-27 huao990928

目录

• git的基本操作

• git的分支管理

• GitHub的使用

git的基本操作

• git简介
  - git的产生历史
  - git的特点
  - 集中式分布式版本控制的区别
  - git的安装配置

• git版本库创建

    命令: git init 

• git版本的创建

     git add <name>
     git commit -m '版本描述'

• git版本回退

    git reset --hard HEAD^ 
    git reset --hard <版本号的部分>

• 查看版本记录

    git log 
    git log --pretty=oneline 

• 查看历史操作记录

    git reflog

• git工作区和暂存区 (

    git status 查看当前工作区的状态

• git管理修改

• git撤销修改

    git checkout -- <name>
    git reset HEAD <name>

• git文件对比

    git diff HEAD HEAD^ -- name
    对比两个版本之间相同文件的差别
  
    git diff HEAD --<name>
    对比最新版本和工作区相同文件的差别

• git删除文件

    rm name 
    git rm name

git分支管理

• git分支-基本操作

    git branch   
    查看当前所有的分支。 * 号后面接的那个分支就是目前正在使用的分支
  
    git branch <name>
    创建新的分支
  
    git checkout <name>
    切换分支
  
    git checkout -b <name>
    创建并切换新的分支
  
    git merge <name>
    快速     合并name分支到当前主分支
  
    值得注意的是前面讲的快速合并(Fast Forword)是
    直接将 master 直接移到当前分支指的提交的位置。是git合并一般默认快速合并
  
    有些分支的合并不能够用快速合并。需要注意。
  
    git branch -d <name>
    删除某分支       

• git分支-解决冲突

  • 产生冲突的原因

      不同分支修改同一文件并都在各自的分支上提交了版本

  • 产生冲突演示

  • 分支管理策略

  • 默认使用快速合并的时候

          在分支上提交完版本后，回到主分支上直接进行合并不做任何的修改

  • 禁用快速合并

          git merge --no-ff -m'版本描述' <分支>
    
          --no-f 的意思是no fast forword 

• git分支-bug分支

    git stash 保护现场
  
    git stash list  产看保护现场在哪儿
  
    git stash pop  恢复现场

文本低端

git简介

• gti的产生历史

  很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

  Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？

  事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！

  你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

  不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

  安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江 湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。

  Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：

  Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。

  Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，php，Ruby等等。

  历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。
  ---
• git的特点
  • 版本控制：
    可以解决很多人同时开发的问题。也可以解决找回历史代码的问题

  • 分布式：
    Git的分布式版本控制系统。

    关于分布式和集中式见 分布式和集中式区别

    同一个git仓库可以布置到不同的机器上，首先找一台电脑充当服务器的角色，24小时开机，其他人从这个“服务器”仓库中将代码克隆一份到自己的电脑上，修改完成后，再将代码提交到仓库中。也可以从仓库中提取别人的修改。可以自己搭建一个服务器，也可以使用现成的GitHub网站充当这个服务器的角色。

返回目录

---

集中式和分布式版本控制的区别

• 集中式：

  先说集中式版本控制系统。简单的说就是，版本库是集中的存放于中央服务器的。干活的时候，先要去中央服务器里领取最新的版本，然后在开始干活。干完活在将自己的版本上传到中央服务器。

  就好比要改一本书，先要从图书馆里将书籍借阅出来，然后改完了之后，在将图书归还给图书馆。然后别人看到的就是最新的版本了。
  
  缺点:

  缺点就是，一但没有网或者网络不好的话，自己写的东西就很难得传上去。别人也不能及时的看到。简单的说就是没有网就不能使用。

---

• 分布式：

  分布式版本控制系统。分布式版本系统没有绝对的所谓中央服务器，每个人的电脑上都有一个版本库，使用的时候就不需要进行联网了。直接自己进行修改就行。既然每个人的电脑上都有一个版本库，那么多个人如何进行写作呢，只需要把你修改的和同事修改的进行交换就行。

  比如说你修改了A文件，你的一个同事也修改了A文件。这个时候只要把自己修改的部分推给对方，对方就能够看到你的修改。

  和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

  在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。
  
  ---

• 最根本的区别：

  集中式和分布式最根本的区别就是：

  分布式每个人的电脑上都可以直接拷贝完整的代码版本。而集中式只能拷贝自己需要的。

  分布式的服务器挂掉之后，不会影响工作。而集中式的服务器挂掉之后，根本就没法进行工作。

---

当然，Git的优势不单是不必联网这么简单，后面我们还会看到Git极其强大的分支管理，把SVN等远远   抛在了后面。

CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于CVS自身设计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。

除了免费的外，还有收费的集中式版本控制系统，比如IBM的ClearCase（以前是Rational公司的，被IBM收购了），特点是安装比Windows还大，运行比蜗牛还慢，能用ClearCase的一般是世界500强，他们有个共同的特点是财大气粗，或者人傻钱多。

微软自己也有一个集中式版本控制系统叫VSS，集成在Visual Studio中。由于其反人类的设计，连微软自己都不好意思用了。

分布式版本控制系统除了Git以及促使Git诞生的BitKeeper外，还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点，但最快、最简单也最流行的依然是Git！

返回目录

---

Git最先开始只能够在linux和unix上面跑，但是后来慢慢的就迁移到了Windows和max上面了。

git的安装配置

• 在Linux下的安装
• 在Windows下的安装
• Mac os 下的安装

返回目录(返回总的目录)

---

##### 在Linux下的安装

首先：

先输入命令 git 看看电脑有没有安装git

如果和下图一样，出现了一堆使用的命令，说明电脑是安装了Git的。

如果和下面一样，出现了not installed 表明还没有进行安装

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

有些linux的版本很友好的提示了你，如何进行安装。

如果是Ubuntu或者Debian的话直接输入
sudo apt-get install git
就可以安装。非常的简单和实用

如果是其他的linux版本的，如cent，Redhat等则直接使用源码进行安装
在git官网上面下载源码，然后解压。然后依次输入命令
./config
make
sudo make install
这几个命令安装就好

---

• 注意：

  如果是老一点的Debian或Ubuntu Linux。就要把命令改为
  sudo apt-get install git-core

  因为以前有个软件也叫GIT（GNU Interactive Tools），结果Git就只能叫git-core了。
  后来由于Git名气实在太大，后来就把GNU Interactive Tools改成gnuit，git-core正式改为git。

  不过一般大家基本上很少用到老一点的linux版本

返回目录

---

##### 在Windows下的安装

如果是在Windows环境下面安装Git，直接在 官网下载，然后按照步骤一步一步的安装即可。

安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！

在安装完成后，还需要设置用户的姓名和邮箱地址。
输入下面的命令：

$ git config --global user.name "Your Name"
$ git config --global user.email "[e-mail]"

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。

• 注意：

  git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

返回目录

---

##### 在Mac os 下的安装

如果你正在使用Mac做开发，有两种安装Git的方法。

一是安装homebrew，然后通过homebrew安装Git，具体方法请参考homebrew的文档：http://brew.sh/

第二种方法更简单，也是推荐的方法，就是直接从AppStore安装Xcode.
Xcode集成了Git，不过默认没有安装，你需要运行Xcode，选择菜单“Xcode”->“Preferences”.
在弹出窗口中找到“Downloads”，选择“Command Line Tools”，点“Install”就可以完成安装了。

Xcode是Apple官方IDE，功能非常强大，是开发Mac和ios App的必选装备，而且是免费的！

返回目录

---

版本库的创建

先新建一个新的目录，然后在目录里面创建版本库。

    命令：git init

可以看到在新建的目录(git_text)下面有一个隐藏的目录.git 。这就是git的版本库目录(简称为仓库)。

Git就是通过这个目录对此项目下的所有的代码，项目进行管理的。

返回目录

---

版本创建

在原有的目录(git_text)下，任意创建一个文件，这里我创建的是 (helloword.py) 然后保存就行。

版本创建的命令：

    git add helloword.py        #这是添加文件的命令
    git commit -m "版本描述"      #这是创建版本号的命令

截图演示:

返回目录

---

查看版本记录

查看版本记录的命令：

    git log  
    查看详细的版本记录

    git log --pretty=oneline
    查看简略的版本信息

commit 后面接的才是真正的版本信息，也是版本序列号。相当于人的身份证一样。
而下面的 hello word 版本一 只是这个的描述信息。描述这个版本的。

简略的版本记录的查询只有版本号和版本描述

返回目录

---

版本回退

版本从上往下回退(如2.0到1.0)：

    版本回退的意思就是，回到之前的那个版本。

在项目的开发中，可能开发到4.0版本的时候又觉得之前的3.0版本比较好。就又去用之前的3.0版本。

这就是Git的一大利器的地方。版本控制，能够找回之前的历史版本，并且使用历史版本。

可以看到在原来的代码里添加了部分后，又重新创建了一个新的版本。然后查看版本记录后，可以看到有两个版本的。

如果要使用之前得版本一，可以使用版本退回命令：

       git reset --hard HEAD^   
    
         #这里的HEAD是指向目前位置的指针。

         如果HEAD是指向10.0的版本的话，那么
         
         (第一种表示方法)：   （第二种表示方法):
    
         HEAD^就是指向9.0      HEAD~1    就是指向9.0
         HEAD^^就是指向8.0     HEAD~4    就是指向6.0
         HEAD^^^就是指向7.0    HEAD~100  就是指向前100个版本

使用了命令后看到目前位于版本一的位置，使用git log 命令进行查看也是位于版本一。

然后打开版本里面的内容也是发现，内容还是版本一的一句话，而不是版本二得函数。

原理：

HEAD就是指向当前位置的指针。HEAD^表示的就是将指针进行下移一位，然后指向下面的一个版本。版本2实在版本1的基础上进行的，是直接打开进行写的，而不是将代码整个的复制一份，然后再写在进行保存的。

---

从下向上回退(1.0到2.0)

• 命令：

       git reset --hard 版本号   
  
       注意是版本号，而不是commit时候的版本描述。
  
       复制版本号得时候，不需要将全部复制下来，只需要复制前面得几个数字就行

• 截图：
  
  可以看到版本一和版本02都回来了。而且里面的文件也回来了。

返回目录

---

查看历史操作记录

查看历史操作记录的作用在于，当处于1.0版本的时候，万一突然退出了git

在进去的时候位于版本1.0，想要回到版本3.0或者更高的时候，不知道版本号就无法操作。

而这个查看历史操作记录可以看到所有的操作，也能够看到版本号。

• 命令：

         git reflog

• 截图:
  
  最前面的就是版本号的前几位。可以到版本号的回退的操作。

返回目录

---

git工作区和暂存区

• 工作区
• 缓存区
• 工作区和缓存区的相互作用
• 查看当前工作区的状态

返回目录(返回总的目录)

---

##### 工作区

• 说明:

  工作区的概念比较简单。就是工作的目录所在的位置就是工作区。

  如我们之前创建的git_text就是一个工作区。

---

版本库/缓存区

• 说明：

  工作区里有一个隐藏目录 .git

  这个不是工作区而是git的版本库。

  git的版本库里存了很多的东西，其中最为重要的就是称为stage(或者叫index)的缓存区

  还有为我们创建的 第一个分支master 以及 指向master的指针 HEAD

---

工作区和缓存区的相互作用

• 图解:
  

• 解释:
  在前面我们创建版本的时候使用的命令：

    git add
    git commit -m '版本描述'

  由图可以看到在工作区书写的代码

  需要通过两步进行提交：

  第一步使用 git add 把文件添加进去，实际上就是把文件修改添加到暂存区。
  第二步使用 git commit 提交更改，实际上就是把当前暂存区所有的内容提交到当前的分支。

• 注意:

  并不是每一次添加都需要立即使用commit进行提交，可以先将多个文件放在缓存区里进行缓存

  然后在一次性进行提交。

返回目录

---

查看当前工作区的状态

• 命令

        git status  #查看当前工作区的状态

• 截图:
  

• 分析:
  可以看到的是

  工作区里面的文件记录hello.py 刚刚修改完的。

  huao.py 刚新建的，但是由于没有add添加到缓存区所以显示的是尚未加入提交，未跟踪的文件。

  添加完成后再将所有的文件同一进行提交即可

• 截图:
  

• 分析:

  当所有的提交完成后，下次查看工作区的状态会发现工作区变成了干净的工作区。

返回目录

---

管理修改

git 的文件修改：

它只会提交暂存区的修改来创建版本

• 解释:
  如果有一个文件在修改完毕后添加了进了缓存区

  然后在对这个文件进行修改并保存

  修改完后直接用commit创建版本。

  结果就是，工作区还没彻底清空，最终修改的部分也没有添加进版本里。
  添加进版本里的是原来修改完毕加入发到暂存区的文件。

• 图解:
  
  

• 结果:

  所以无论什么时候修改，一定要添加到暂存区，否则只会功亏一篑。

  创建的版本只会用暂存区的来进行创建。没有加入进暂存区的修改都是白白浪费力气。

返回目录

---

撤销修改

撤销修改有几种不同的情况。

1. 在工作区中完成了但没有提交到暂存区
2. 在缓存区中但没有创建版本
3. 已经形成了版本

返回目录 (返回的总的目录)

---

在工作区中并未到缓存区中

• 命令

                    git checkout -- '文件名'

• 截图:
  

• 解释:

  对文件hello.py修改了后，产看当前得工作区得状态可以看到，命令给的已经很清楚了。

  这里我们用撤销修改。

  使用后查看文件，修改的部分都回来了。工作区也干净了。

  都回到了之前的状态。

返回目录

---

在缓存区但没有创建版本

• 命令:

                git reset HEAD <文件>
  
                返回工作区后，再按照工作区的进行就行
  
                git checkout -- <文件>

  截图我就不演示了。大家自行在linux里面进行演示就行。

  在master已经创建了版本

  参照之前的 版本退回

然后再向上面一样依次递推就行。

返回目录

---

文件对比

• 命令:

    git diff HEAD HEAD^ -- name
    对比两个版本之间相同文件的差别
  
    git diff HEAD --<name>
    对比最新版本和工作区相同文件的差别

• 版本之间对比截图:

  1. 版本1.0里面的huao.py文件
     

      可以看到的是文件内容就是一句话 
      print('你好全世界!')

  ---

  1. 版本2.0里面的huao.py文件
     

      可以看到里面有两句话
      print('你好全世界!')
      print(你好我叫胡澳!")

  ---

  1. 两者进行比较
     

      ---a/huao.py对应的一般是两个比较文件的第一个
      +++b/huao.py 对应的一般是两个比较文件的第二个
     
      下面是比较结果:
     
      前面既没有 + 号也没有 - 号的是两个文件所共有的
      有+号或者-号的是  +或 - 文件所特有的
     
      所以比较结果就是版本2.0比版本1.0多一句话
      print('你好我叫胡澳！')
     
      这和我们写的文件内容是相符的。

     ---

  2. 将两个文件反过来进行比较：

      可以看到结果也是版本2.0比版本1.0多一句话。
      结果都是一样的。

     ---

• 工作区和版本之间对比截图:

1. 可以看到工作区比版本多了几句话
   

返回目录

---

删除文件

• 命令:

      rm <文件名>       # 这是使用Linux自带的命令进行删除
  
      git rm <文件名>   # 这是  git 的删除文件

• rm

  • 截图:
    
    按照Linux的删除文件的方法就能够删除文件。(如截图)

    由于删除也是在工作区里面。所以查看工作区的状态也是显示的删除文件。

    如果误删:

    按照暂存区文件的 撤销修改 来就行。

• git rm <文件>：
  • 截图:
    
    使用 git rm 进行删除直接就放到暂存区了。并不需要 git add 进行添加到暂存区。

  误删的修复也是从暂存区开始

            git checkout -- <文件>
            git reset HEAD <文件> 

  注意:

  git rm <文件> 只是用于删除一个文件。

  如果你的文件添加到版本库中了的话，永远不用担心会被删除。

  但是要小心，因为只能回复到最新版本。你会丢失最近一次提交后你修改的内容。

  特别注意:

  如果仅仅只是刚刚创建的文件，从来没有添加到暂存区或者形成版本。一旦删除后。就只能够用
  一些修复硬盘的工具来恢复了。前面讲的撤销恢复就不适用了。

  如图:
  

返回目录

---

分支管理

• 分支管理的概念
• git分支的详细讲解及原理
• 分支有关的命令

返回目录 (返回总目录)

---

• 分支管理的概念

  分支就好比做一个房子。水电和室内的装修可以同时进行，分两个不同线路进行，最后汇合将房子做成。
  
  所以分支也就是几条可以独立运行的线路互相之间不会影响。最后可能会汇合将工作完成。

  分支的应用:

  分支在实际应用中还挺广泛的。比如说你要一个做一个项目，每个人完成25%的项目，但是需要两周才能够完成。第一周你只写了50%的代码，如果提交上去的话，不完整的代码会导致别人的无法正常运行。如果等到代码写完了在提交的话又可能会导代码丢失进度的风险。

  但是现在有分支之后就好多了，你有了一个属于自己的分支别人看不到，别人还继续在原来的分支上进行工作。但是你在自己的分支上，想提交就提交，直到开发完毕后，在一次性将代码合并到原来的分支上。这样既安全，又不影响别人的工作。

返回目录

---

• git分支的详细讲解及原理

  • 讲解

    git 把我们之前每次提交的版本串成一条时间线，这个时间线就是一个分支。
    在没有创建分支之前都只有一条分支。
    在git里面叫做 主分支，即 master分支

    HEAD严格来说不是 指向提交，而是指向master
    而master才是指向提交的。所以HEAD指向的就是当前分支。

    结论就是:
    HEAD<指向>分支名<指向>提交
    所以HEAD不是直接指向提交得版本的，是间接的指向的。
    ---
  • 原理：
  1. 一开始的时候，只有 master 一条主分支，此时的 HEAD指针 指向 master。master 又指向最新的提交
     
     所以每次提交一次版本，它就往前面移动，指向最新的提交。所以这个主线也就越来越长。
     ---
  2. 当创建一个分支 dev 的时候，只是创建了一个 指针dev 并指向与 master相同 的提交。然后将 HEAD 指向 dev指针 。就表示当前的分支在dev上面
     
     所以git创建一个分支很快。只是添加一个 dev 指针，然后修改 HEAD 的指向，整个工作区都没有任何的变化。
     ---
  3. 后面再创建的版本就和 master 没有关系了，是在 dev 分支上的。而 master 指针还是在原来的位置。往后面添加的始终只是 dev 指针
     
     ---
  4. 当 dev 分支上面的工作做完了的时候。要合并分支，只需要将 master 分支移到 dev 所指的最新提交上面来。在将借来的HEAD还给 master 指针就行。后面再添加就和 dev 没有关系了。
     
     git 合并分支也很快，也就是改改指针，工作区的内容还是不变。
     ---
  5. 分支合并完成后。甚至可以删除 dev 分支 删除dev分支也就是删除dev指针而已。
     删除了后，就只剩下一条master 分支
     

返回目录

---

• 分支有关的命令

1. 命令:

        git branch   
        查看当前所有的分支。 * 号后面接的那个分支就是目前正在使用的分支
   
        git branch <name>
        创建新的分支
   
        git checkout <name>
        切换分支
   
        git checkout -b <name>
        创建并切换新的分支
   
        git merge <name>
        快速     合并name分支到当前主分支
   
        值得注意的是前面讲的快速合并(Fast Forword)是
        直接将 master 直接移到当前分支指的提交的位置。是git合并一般默认快速合并
   
        有些分支的合并不能够用快速合并。需要注意。
   
        git branch -d <name>
        删除某分支

   ---

2. 使用:

   • 查看当前所有的分支
     
   1. 创建分支并查看
      
   2. 切换分支
      
   3. 在新分支中修改文件并提交版本
      

   4. 切换回master主分支
      
      切换回master分支发现并没有之前提交的 dev版本1.0 是因为两个分支还有进行快速合并

   5. 合并dev和master分支
      
      合并完成后可以看到出现了dev版本1.0

   6. 删除dev分支
      
      删除分支后发现只有主分支 master 了

返回目录

---

产生冲突的原因

• 原因:

  两个分支同时修改了同一个文件并提交了相应的版本。进行merge的时候出现冲突。需要手动进行合并，再进行提交。如图所示：
  
  只要不是上面的条件都不会造成冲突

返回目录

---

产生冲突的演示

• 原因很简单，同一个文件被两个分支同时修改，并都提交了相应的版本
• 解决的方法也很简单，直接手动进行融合，然后再提交就行

• 截图演示:

  1. 在master分支中提交版本1.0
     
  2. 在dev分支中提交版本dev1.0
     
  3. 切换回master分支中创建版本2.0
     

  4. 将master分支和dev分支进行合并，出现冲突
     
     可以看到出现冲突 的文件是 hu.txt

  5. 查看冲突出现文件的内容
     
     可以看到是HEAD中的一句话和dev中的一句话不一样，造成的。
     ---

• 解决方法
  解决方法就是自己手工进行柔和。然后再提交。

  1. 将<<<<>>>>dev删除
     进行自己手工柔和
     

  2. 提交版本
     
     这样冲突就解决了。

  3. 冲突解决完了后，就可删除dev分支了
     

返回目录

---

分支管理策略

• 说明

    通常合并分支的时候，git回自动采取Fast Forword也就是快速合并模式。
  
    但是有些时候快速合并并不能够成功，而且合并的时候还没有出现冲突，一片和谐。
  
    这个时候会合并之后做一次新的提交。但是这种模式下，删除分支之后，对丢掉分支的信息

  如图所示：

    当切换到 dev 分支修改 code.txt 文件并提交版本结束后。
  
    又回到原来的 master 分支修改 huao.txt 文件并提交了版本的时候。
  
    这两个文件一定不是同一个文件，不然就冲突来了。

  

• 演示:
  1. 在env的分支下编辑code.txt文件并创建版本6.0
     
  2. 切换回master分支，修改并提交文件huao.txt
     

  3. 将两个分支进行合并。
     
     框框中的是对合并后的文件进行重新描述的地方。描述完后直接退出就行。下面有提示的命令

  4. 合并后可以看到，合并的方式不是fast forword.而是 recursive方式进行合并的。
  5. 合并之后也是提交了一个新的版本。
     

  6. 然后将env分支删掉就行
     

• 分支策略

    在实际开发中，我们应该按照几个基本原则进行分支管理：
  
    首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
  
    那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，
  
    到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
  
    你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，
  
    时不时地往dev分支上合并就可以了。

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

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

返回目录

---

• 快速合并

  • 快速合并

    在merge命令中讲解的很清楚，就不再进行多的赘述了

      简单的说就是在 dev 分支中提交了版本后
    
      切换回  master 版本就不再修改啥，直接合并。就默认是快速合并

返回目录

---

禁止快速合并

• 命令

            git merge --no-ff -m '版本描述' <分支名>

• 演示:

1. 切换到dev分支并修改huao.py并提交
2. 切换回master分支直接使用命令合并
   
3. 查看结果
   
   显示的不是fastforword 。而且也很明显的看到有一个自动合并提交的过程。

返回目录

---

bug分支

• 命令

        git stash 将工作现场存储起来，等以后恢复现场再进行工作
  
        git stash list  用于查看刚刚存储的工作现场的位置
  
    一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
  
    另一种方式是用git stash pop，恢复的同时把stash内容也删了，一举两得。

• 原因
  在做开发的时候，很可能写代码写到一半，突然出了BUG要回去修复。所以就需要将工作区临时存放起来，把bug修改完成后再回来继续写代码。所以这个功能的重要性就不言而喻了。

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？

有木有更简单的方法？

有！

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch

• dev
  master
  $ git cherry-pick 4c805e2
  [master 1d4b803] fix bug 101
  1 file changed, 1 insertion(+), 1 deletion(-)
  Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

返回目录

---

文本低端

文本顶端

---