Git 学习笔记

起步

起步 - 关于版本控制

  什么是“版本控制”？我为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。在我们日常工作当中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。

起步 - Git 基础

  在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。因为你在本地磁盘上就有项目的完整历史，所以大部分操作看起来瞬间完成。

  举个例子，要浏览项目的历史，Git不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改，Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。

起步 - Git 状态

  Git有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。

• 已提交表示数据已经安全的保存在本地数据库中。
• 已修改表示修改了文件，但还没保存到数据库中。
• 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。

由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。

起步 - Git基本工作流程

1. 在工作目录中修改文件。
2. 暂存文件，将文件的快照放入暂存区域。
3. 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。

Git 基础

Git 基础 - 记录每次更新到仓库

  现在我们手上有了一个真实项目的 Git 仓库，并从这个仓库中取出了所有文件的工作拷贝。 接下来，对这些文件做些修改，在完成了一个阶段的目标之后，提交本次更新到仓库。

  请记住，你工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。已跟踪的文件是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它们的状态可能处于未修改，已修改或已放入暂存区。工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。初次克隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。

  编辑过某些文件之后，由于自上次提交后你对它们做了修改，Git将它们标记为已修改文件。我们逐步将这些修改过的文件放入暂存区，然后提交所有暂存了的修改，如此反复。

Git 基础 - 忽略文件

  一般我们总会有些文件无需纳入Git的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。

  文件 .gitignore 的格式规范如下：

• 所有空行或者以 ＃ 开头的行都会被 Git 忽略。
• 可以使用标准的 glob 模式匹配。
• 匹配模式可以以（/）开头防止递归。
• 匹配模式可以以（/）结尾指定目录。
• 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。

Git 分支

Git 分支 - 分支简介

  几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。Git处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。与许多其它版本控制系统不同，Git鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。

Git 分支 - 分支管理

  Git 最显著的优点之一：版本的分支(branch)和合并(merge)。

1. 主分支Master

  代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

  Git主分支的名字，默认叫做Master，是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

1. 开发分支Develop

  主分支： 用来分布重大版本。开发( Develop )： 在另一条分支上完成。

1. 功能分支

   功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

1. 预发布（预览）分支

  预发布分支，在发布正式版本之前（即合并到Master分支之前），对预发布的版本进行测试。预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。

1. 修补bug分支

  软件正式发布以后，难免会出现bug。要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的，修补结束以后，再合并进Master和Develop分支。

使用规范

分支命名规则

名称	作用	描述
master	主干分支	用于部署生产环境的分支，对外提供使用的正式版本，都在这个主分支上。 master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码。
develop	开发分支	始终保持最新完成以及bug修复后的代码，永远是功能最全最新的分支。
feature	需求分支	源于开发分支独立新功能，开发完成后合并到develop分支或者抛弃。分支命名: feature/ 开头的为特性分支,例如: feature/user_module
release	发布(预上线)分支	发布提测阶段，会release分支代码为基准提测。
hotfix	修复分支	master分支出现bug，创建hotfix分支，修复完成后，需要合并到develop分支。分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似

  当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

基础操作命令

本地操作基础命令

• 查询状态

  git status
  

远程仓库操作

• 查看项目的地址

  git remote -v 
  

• 从远程仓库拉取数据

  git pull
  

> 自动拉取数据，然后将远程分支自动合并到本地仓库中的当前分支

• 分支操作
  • 查看

    git branch
    

  • 创建分支

    git branch 分支名称
    

  • 切换到分支

    git checkout 分支名称
    

  • 新建并切换到新分支

    git checkout -b 分支名称
    

  • 分支合并

    git checkout 合并的分支
    git merger 被合并的分支
    

开发任务处理流程

1. 确定开发版本分支
2. 从对应的版本分支中新建任务分支
   1. 如果任务单中没有指定分支名称，则以任务单号命名。其中prefix前缀用于区分是功能分支(feature)还是bug分支(hotfix)
3. 在任务分支中完成开发任务
   1. 为减少冲突，在任务分支开发过程中需要定期更新版本分支代码到任务分支
   2. 切换到版本分支，合并（Merge）版本分支到任务分支，并解决可能的冲突。
4. 合并到对应的版本分支
   1. 在完成任务分支时，然后切换到版本分支，合并（Merge）任务分支到版本分支。

GIT操作要点

• 不要在master分支做开发；没有特定的理由，不在主分支做开发，不在主分支处理冲突。
• 建立新的任务分支做开发，在合并到主分支前，定期将主分支合并到任务分支并解决冲突。
• 切换分支前，确保Working Tree是干净的，先做好本地提交，以免和切换分支之后的代码产生冲突。
• Commit前，确保先解决了冲突，并将所有需要Commit的文件Stage到了Index暂存区。
• 合并分支之前，先执行Pull更新代码，再执行合并操作。如果不pull，并且远程仓库代码有更新的话，Push就会产生冲突，甚至会覆盖远程仓库代码
• 如果Push不上去，不要强行操作，仔细阅读提示信息，确保安全操作。