Git 理论基础

• 在使用的任何的 git 命令前，都要切换到 git 项目目录下。

• Git 只是一个简单的内容跟踪工具

• 一张图（看懂git交互过程）：

-----------------------------------------------------------------------------------------------------------------------

• 一、访问控制：

• 1、Git 不提供访问控制，允许任何开发者拥有仓库的完整读写权限。在最外层，你通过登录控制来限制访问。我在自己的机器上开发，而你没有权限访问，因此你无法更改我的仓库。一旦我将仓库放在共享的区域，比如集中式代码托管服务器，我们需要共同协商如何管理仓库的访问权限。
• 2、下面三种最流行的访问模型。
  • 单一仓库共同维护模型：团队中的每个人都是维护者，有权限向项目仓库上传更改。
  • 并列贡献者仓库模型：提交贡献的开发者创建一个项目的远程副本，等待项目维护者接受他们的更改。
  • 分散贡献者仓库模型：代码通过文本格式的补丁包共享。
    +/3、为了让邮件发送补丁文件更加方便，Git 增加了 am 命令来支持通过邮件列表发送的补丁。
• 4、当 GitHub 创建一个派生的仓库时，它等同于使用 Git 命令 clone 来创建一个仓库的副本。一旦你创建了一个派生仓库，你就可以在 GitHub 的网页上直接将更改应用于仓库，但对于比较复杂的更改来说，这不是一个好习惯。相比之下，你更有可能会再克隆一次仓库，而这次是从派生出来的仓库克隆到本地的工作区。这个做法高效地建立了从一个仓库副本到另一个的克隆链。保持所有仓库同步有些费事，但是，与直接操作补丁相比，需要记忆的命令会少很多。
• 5、共同维护的模型：（每个人都拥有对该仓库的共享写入权限。）
  
• 6、Git 不提供权限控制，而是依赖其他系统来授权或阻止对项目的写入访问。如果你想要阻止别人将代码上传至共享仓库，需要使用托管系统的访问控制才能实现。
  -----------------------------------------------------------------------------------------------------------------------

• 二、分支策略：

• 1、分支总是起源于代码库中的某个特定节点。

• 2、分支允许你更改项目工作目录中可见的文件，并且一次只会有一个分支活跃。大多数分支策略是根据粗粒度的想法分隔项目中的工作。

• 3、决策一定要形成文档。

• 4、主线分支开发：（将所有提交保存在一个分支）

• 4、功能分支部署：

• 5、在 GitHub 流程的分支模型中，任何 master 分支上的代码都是可部署的。当编写新的代码时，GitHub 流程要求开发者创建一个语义化命名的分支，并将他们的工作定期提交到这个分支。这个分支与 master 同步，并定期推送到共享仓库中对应的分支，使得其他人可以看到哪些功能正在进行。当开发者认为工作已经完成，或者需要其他人的帮助时，他们会在 master 分支上发起一个拉取请求。工单系统将会出现关于工作方案的讨论。

• 6、GitHub 流程：（功能分支在审查后进行部署，然后被并入到 master 分支中）

• 7、状态分支

• 8、计划部署：

  • 使用计划部署策略具有以下四个优点。
    • 计划部署不要求你预先准备好全面的测试设施。
    • 软件的构建过程通常伴随着开发、质量保证、生产这些阶段。也就是说，一旦软件 开发者理解了分支约定中如何以及何时进行他们的日常任务，他们便会对 GitFlow 约定感到非常熟悉。
    • 通过严格遵守约定，开发者总能明确自己应该从哪个分支开始工作。
    • 这个模型同样适用于版本化管理的软件，如应用商店中下载的应用，这些应用不适合每隔几天部署一个新版本。

• 9、更新分支：

  • 更新分支时，可以选择其中一种策略：合并（merge）或 变基（rebase）。
    • 两种变基的方式：
      • 第一种，在相关分支上整合新的工作（更新一个分支）时用于代替合并。
      • 第二种，通过增删修改分支上的提交历史中的特定提交来更改现有分支上的历史，达到使历史更加精简的目的。本节指的是前一种方式。
        
      • 合并：
        
        阅读文档，运行 git help merge 命令。

• 合并还是变基（链接）提供了一个决策树来帮助你认清应该使用其中哪种策略。

•   ---------------------------------本文内容部分摘抄自《git团队协作》