Git 仓库结构 （一）***

Git 仓库 

    1.1Git 基本概念    

        在Git中，咱们将须要进行版本控制的文件目录叫作一个仓库（repository），每一个仓库能够简单理解成一个目录，这个目录里面的全部文件都经过Git来实现版本管理，Git都能跟踪并记录在该目录中发生的全部更新。

        如今咱们已经知道什么是repository（缩写repo）了，假如咱们如今创建一个仓库（repo），那么在创建仓库的这个目录中有一个“.git”的文件夹。这个文件夹很是重要，全部的版本信息，更新记录，以及Git进行仓库管理的相关信息

所有保存在这个文件夹里面。因此，不要修改/删除其中的文件，以避免形成数据的丢失。

        进一步的讲解请参考下面一张图，大概展现出了咱们须要了解的基本知识。

 　　　　

    根据上面的图片，下面给出了每一个部分的简要说明：

• Directory：使用Git管理的一个目录，也就是一个仓库，包含咱们的工做空间和Git的管理空间。
• WorkSpace：须要经过Git进行版本控制的目录和文件，这些目录和文件组成了工做空间，除了.git以外的都属于工做区。
• .git：存放Git管理信息的目录，初始化仓库的时候自动建立。
• Index/Stage：暂存区，或者叫待提交更新区，在提交进入repo以前，咱们能够把全部的更新放在暂存区。
• Local Repo：本地仓库，一个存放在本地的版本库；HEAD会只是当前的开发分支（branch）。
• Stash：是一个工做状态保存栈，用于保存/恢复WorkSpace中的临时状态。

     有了上面概念的了解，下面简单介绍仓库的文件结构。

 

        该目录下有可能还有其余文件，但这是一个全新的 git init 生成的库，因此默认状况下这些就是你能看到的结构。新版本的 Git 再也不使用 branches 目录，description 文件仅供 GitWeb 程序使用，因此不用关心这些内容。config 文件包含了项目特有的配置选项，info 目录保存了一份不但愿在 .gitignore 文件中管理的忽略模式 (ignored patterns) 的全局可执行文件。hooks 目录保存了客户端或服务端钩子脚本。

另外还有四个重要的文件或目录：HEAD 及 index 文件，objects 及 refs 目录。这些是 Git 的核心部分。

• objects 目录存储全部数据内容
• refs 目录存储指向数据 (分支) 的提交对象的指针,里面即有stash栈指针以及tag等
• HEAD 文件指向当前分支
• index 文件保存了暂存区域信息

    1.2 简单的代码提交流程

        这里不对每一条命令作详尽的解释，这些命令或相似命令贯穿咱们顺利的一个完整提交，关于其余状况以及这些命令的详细解释留待后面叙述。

        （1）git status //查看工做区代码相对于暂存区的差异，

        （2）git add . // 将当前目录下修改的全部代码从工做区添加到暂存区 . 表明当前目录

        （3）git commit -m “commit-message” //将暂存区的代码提交到本地版本库

        （4）git push origin master // 将本地版本库推送到远程服务器，origin是远程主机，master表示是远程服务器上的master分支，分支名是能够修改的。

　　1.3 GIT的基本操做：

　　

 

版本管理的挑战

虽然有这么优秀的版本管理工具，可是咱们面对版本管理的时候，依然有很是大得挑战，咱们都知道你们工做在同一个仓库上，那么彼此的代码协做必然带来不少问题和挑战，以下：

1. 如何开始一个Feature的开发，而不影响别的Feature？
2. 因为很容易建立新分支，分支多了如何管理，时间久了，如何知道每一个分支是干什么的？
3. 哪些分支已经合并回了主干？
4. 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员能够继续开发新的功能？
5. 线上代码出Bug了，如何快速修复？并且修复的代码要包含到开发人员的分支以及下一个Release?

大部分开发人员如今使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各类分支。这个在小项目规模的时候还勉强能够支撑，由于不少人作项目就只有一个Release, 可是人员一多，并且项目周期一长就会出现各类问题。

Git Flow

就像代码须要代码规范同样，代码管理一样须要一个清晰的流程和规范

Vincent Driessen 同窗为了解决这个问题提出了 A Successful Git Branching Model

下面是Git Flow的流程图

上面的图你理解不了？ 不要紧，这不是你的错，我以为这张图自己有点问题，这张图应该左转90度，你们应该就很用以理解了。

Git Flow经常使用的分支

• Production 分支

也就是咱们常用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其余分支合并，不能在这个分支直接修改

• Develop 分支

这个分支是咱们是咱们的主开发分支，包含全部要发布到下一个Release的代码，这个主要合并与其余分支，好比Feature分支

• Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，咱们合并回Develop分支进入下一个Release

• Release分支

当你须要一个发布一个新Release的时候，咱们基于Develop分支建立一个Release分支，完成Release后，咱们合并到Master和Develop分支

• Hotfix分支

当咱们在Production发现新的Bug时候，咱们须要建立一个Hotfix, 完成Hotfix后，咱们合并回Master和Develop分支，因此Hotfix的改动会进入下一个Release

Git Flow如何工做

初始分支

全部在Master分支上的Commit应该Tag

Feature 分支

分支名 feature/*

Feature分支作完后，必须合并回Develop分支, 合并完分支后通常会删点这个Feature分支，可是咱们也能够保留

Release分支

分支名 release/*

Release分支基于Develop分支建立，打完Release分以后，咱们能够在这个Release分支上测试，修改Bug等。同时，其它开发人员能够基于开发新的Feature (记住：一旦打了Release分支以后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，而后能够删除Release分支了。

维护分支 Hotfix

分支名 hotfix/*

hotfix分支基于Master分支建立，开发完后须要合并回Master和Develop分支，同时在Master上打一个tag

Git Flow代码示例

a. 建立develop分支

git branch develop
git push -u origin develop 

b. 开始新Feature开发

git checkout -b some-feature develop
# Optionally, push branch to origin: git push -u origin some-feature # 作一些改动 git status git add some-file git commit 

c. 完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature git push origin develop git branch -d some-feature # If you pushed branch to origin: git push origin --delete some-feature 

d. 开始Relase

git checkout -b release-0.1.0 develop # Optional: Bump version number, commit # Prepare release, commit

e. 完成Release

git checkout master
git merge --no-ff release-0.1.0 git push git checkout develop git merge --no-ff release-0.1.0 git push git branch -d release-0.1.0 # If you pushed branch to origin: git push origin --delete release-0.1.0 git tag -a v0.1.0 master git push --tags

f. 开始Hotfix

git checkout -b hotfix-0.1.1 master 

g. 完成Hotfix

git checkout master git merge --no-ff hotfix-0.1.1 git push git checkout develop git merge --no-ff hotfix-0.1.1 git push git branch -d hotfix-0.1.1 git tag -a v0.1.1 master git push --tags

Git flow工具

实际上，当你理解了上面的流程后，你彻底不用使用工具，可是实际上咱们大部分人不少命令就是记不住呀，流程就是记不住呀，肿么办呢？

总有聪明的人创造好的工具给你们用, 那就是Git flow script.

安装

• OS X

brew install git-flow

• Linux

apt-get install git-flow

• Windows

wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

使用

• 初始化: git flow init

• 开始新Feature: git flow feature start MYFEATURE

• Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE

• 获取Publish的Feature: git flow feature pull origin MYFEATURE

• 完成一个Feature: git flow feature finish MYFEATURE

• 开始一个Release: git flow release start RELEASE [BASE]

• Publish一个Release: git flow release publish RELEASE

• 发布Release: git flow release finish RELEASE
  别忘了git push --tags

• 开始一个Hotfix: git flow hotfix start VERSION [BASENAME]

• 发布一个Hotfix: git flow hotfix finish VERSION

Git Flow GUI

上面讲了这么多，我知道还有人记不住，那么又有人作出了GUI 工具，你只须要点击下一步就行，工具帮你干这些事！！！

SourceTree

当你用Git-flow初始化后，基本上你只须要点击git flow菜单选择start feature, release或者hotfix, 作完后再次选择git flow菜单，点击Done Action. 我勒个去，我实在想不到还有比这更简单的了。

目前SourceTree支持Mac, Windows, Linux.

这么好的工具请问多少钱呢？ 免费!!!!

Git flow for visual studio

广大VS的福音
GitFlow for Visual Studio

 GIT基础知识：

1.文件系统：咱们能够把硬盘理解成一本汉语词典，词典前面的目录索引就是文件系 统，能帮助咱们快速找到文件内容的具体位置，一般咱们也只会经过索引去找文件，windows中的个人电脑就是一个索引系统，索引里面没有的文件咱们就 “找不到”。咱们知道从操做系统删除文件，其实只是删除了索引，具体文件内容仍是存在硬盘上的，虽然咱们经过索引找不到，可是咱们能够经过内容去查找（利 用一些恢复工具）。

2.git仓库：就是用来存放备份文件的地方，可是备份文件存入仓库的时候会压缩， 这些压缩的备份文件存放在.git/objects目录中，直接打开是乱码，并且为了节省空间，仓库不会存放重复的文件，只有新增和修改过的文件才会存入 git仓库，删除的时候并不会从仓库移除文件，否则咱们怎么恢复呢。

3.HEAD：git的版本日志或版本号，经过git log 咱们能够看到不少的编号，咱们经过修改head指针来切换版本，每一个版本关联一份快照，每一个关照关联一系列文件，就是“HEAD->快照->仓库文件”这样一个关系链，咱们能够很轻松的经过移动HEAD指针来改变咱们的工做区文件。

4.暂存区/缓冲区：暂存区并不存放文件内容，暂存区仅仅是一份处于编辑状态的快照（索引文件），这份快照没有编号。commit就是把暂存区保存到版本库，并给版本日志新增一个编号（HEAD/版本号）指向这个快照副本。

5.git快照：咱们知道git是经过快照来管理版本的，快照就是git的文件系统，就是咱们说的汉语词典的索引，每次commit就是建立一份快照，并给快照起一个编号，这个编号就是HEAD。

6.工做区：工做区就是除开.git目录的其余东西。经过操做系统的文件索引来管理的内容。就是咱们正常使用电脑的时候所看到，能编辑的内容。

7.分支：分支其实就是上面说到的版本日志,一个分支就是一个版本分组，每一个分支记录该分支上的全部HEAD，“分支->HEAD->快照->仓库文件”

同窗们能够经过下面的图片来理解以上几个概念，下图中的每一个方块都是存放在硬盘上的文件,git就是创建了这样一个关系库来管理版本的（途中的缓冲区就是暂存区）。

你们不要被上图的复杂线条缩困扰，你只须要弄清HEAD就好了，咱们移动HEAD指针其实就是经过HEAD编号找到快照，再经过快照找到这个HEAD的全部文件。

git命令的理解：

一、status

1.一、对比暂存区跟工做区，对比结果主要存在3种状况：

1.1.一、【删】暂存区记录的文件在工做区没有，add的时候会从暂存区移除对应的文件索引，但并不影响git仓库的内容。

1.1.二、【增】工做区已有的文件在暂存区没有记录的，add的时候会把对应的文件拷贝到仓库中，并在暂存区创建一条索引指向仓库中对应的文件。

1.1.三、【改】对工做区的文件内容进行算法得出校验值与暂存区记录的校验值不一样，add的时候会把对应的文件拷贝到仓库中，并更新暂存区该条索引的信息。

1.二、对比暂存区与当前HEAD所指向的快照，对比结果也是增、删、改3种状况

二、add

add会执行2个任务，第一是把【增】【改】的文件拷贝到仓库，第二个是维护暂存区索引，保证暂存区索引跟操做系统的文件索引内容一致，快照索引指向的是仓库中的文件，操做系统索引指向的是工做区的文件。

三、commit

commit作的事情就简单些了，先对比暂存区与工做区，当暂存区与工做区内容相同的时候，直接保存暂存区为一份新的快照、并给这个快照生成1个编号，并把当前分支HEAD改为这个编号。

四、reset

reset分2状况：

4.一、reset文件：reset    b86563   b.txt ，将b86563这份快照中b.txt索引复制到暂存区的b.txt的索引。仅仅是对暂存区的索引进行修改，不影响文件内容，仅仅是修改了文件的关联。

4.二、reset HEAD：reset    b86563

4.2.一、参数–soft：仅仅修改HEAD/版本号。

4.2.二、参数–mixed：默认参数，修改当前HEAD/版本号，而后用指定的快照覆盖暂存区，工做区不变。

4.2.三、参数–hard：修改当前分支HEAD，用参数HEAD关联 的快照覆盖暂存区，并把工做区恢复到快照建立时的工做区状态，实际就是对比这份“历史快照”与工做区，快照中没有的文件，从工做区删除，校验码不一样以及工 做区没有的文件，经过快照找到关联的文件（仓库中的），并复制到工做区。

五、checkout

reset分2状况：

4.一、checkout HEAD：用HEAD关联的快照覆盖暂存区，并把工做区恢复到快照建立时的工做区状态，checkout 快照与reset –hard的区别就是：checkout是可恢复，reset是不可恢复（后期会删除仓库中的文件，checkout不会）

4.二、checkout分支：checkout   dev ，切换到dev分支，并修改当前版本号为dev上最后一个版本号。若是dev分支不存在，建立一个名为dev的分支，版本号不变。

六、revert

revert就是建立一个新快照，并把分支HEAD修改成新建立快照的编号，用该快照覆盖暂存区，并把工做区恢复到快照建立时的工做区状态。checkout和reset会“丢弃”一些版本日志，cover不会。

总结：

1.暂存区、快照=git的文件系统=索引；仓库、工做区=咱们真正须要的文件内容。

2.安全性：revert>checkout>reset，revert不会影响过去，checkout会丢弃掉一些版本号，reset会丢弃版本号和仓库中的某些备份文件。

七、远程仓库

工做区的文件是能够编辑的，git仓库的文件是不能编辑的，git上传到远程仓库或从远程仓库下载的时候，并非下载或上传所有文件。

7.一、上传的时候，远程仓库的最新快照编号确定是包含在本地的快照日志中的， 若是不存在，则证实远程仓库在上次下载后有改动，这时候要求先pull。反之，git会把本地新增的文件上传到远程仓库，并把新增的快照上传到远程快照。 经过图1，咱们能够看出git是怎么经过HEAD轻松的找到新增的快照和文件的。

7.二、下载的时候与上传同理…