GIT规范参考

git的权限管理

权限说明

仓库成员权限参考

1、对于需要该项目参考，阅读的成员。建议设置该成员为订阅者；对于该项目的开发者，建议设置相关开发人员为编写者；对于项目负责人，需要管理该项目的成员变动，以及分支管理等。建议设置该成员为管理者；项目仓库的创建工作应由相关部门领导负责。
2、建议设置项目主分支为受保护分支，坚决不允许向受保护分支提交代码。受保护分支的代码更新工作应为如下方式：从受保护分支最新节点分出分支，添加代码。提交分支合并请求，其他相关人员阅读请求，发表意见。无异议后，项目负责人着手解决冲突，合并分支（fast-forward模式）。删除开发分支，通知有关部门更新代码。

成员权限与分支管理示例

点击上图中的settings按钮，进入仓库设置界面

点击左侧的collaboration按钮

点击下方绿色add new collaborator按钮添加项目成员，点击成员管理write下拉选项选择对应的权限，进行成员权限管理。点击红色delete按钮，删除已添加成员。
点击左侧branches按钮，进行分支保护操作

如上图所示，第一个默认分支，设置该项以更改用于代码提交，合并请求和在线编辑的base分支。
第二个受保护分支，设置该项以保护对应的分支不被强制推送，意外删除和限制代码提交。受到保护的分支显示在该选项下方，图中为master。可设置多个受保护分支。

合并请求的创建及允许

点击合并请求，点击创建合并请求按钮

填写请求部分信息，标题为必填内容。可增加部分文件作为辅助说明，填写完毕后点击创建合并请求按钮创建一个新的合并请求。

然后可以在合并请求里看见之前创建的请求。点击该请求，进入请求详细界面。

请求界面显示该合并可以进行自动合并操作，不能进行自动合并操作的请更新至本地进行手动合并。

点击合并请求，合并即完成
返回master分支发现，该分支已被合并。

git-flow工作流

简介

git-flow工作流如下图所示：

如上图所示，git-flow的工作流有如下几个分支。

开发实例

创建develop分支

第一步是给默认的master配备一个develop分支。一种简单的做法是：让一个开发者在本地建立一个空的develop分支，然后把它推送到服务器。

git branch develop
git push -u origin develop

develop分支将包含项目的所有历史，而master会是一个缩减版本。现在，其他开发者应该克隆（clone）中央仓库，并且为develop创建一个追踪分支。

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

A和B开发新功能

分别开发新功能开始。他们俩各自建立了自己的分支。注意，他们在创建分支时，父分支不能选择master，而要选择develop。

git checkout -b some-feature develop

他们俩都在自己的功能开发分支上开展工作。通常就是这种Git三部曲：edit，stage，commit：

git status
git add <some-file>
git commit

A把他的功能开发好了

在提交过几次代码之后，A觉得他的功能做完了。如果她所在的团队使用“拉拽请求”，此刻便是一个合适的时机——她可以提出一个将她所完成的功能合并入develop分支的请求。要不然，她可以自行将她的代码合并入本地的develop分支，然后再推送到中央仓库，像这样：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

第一条命令确保了本地的develop分支拥有最新的代码——这一步必须在将功能代码合并之前做！注意，新开发的功能代码永远不能直接合并入master。必要时，还需要解决在代码合并过程中的冲突。
A开始准备一次发布

尽管B还在忙着开发他的功能，A却可以开始准备这个项目的第一次正式发布了。类似于功能开发，她使用了一个新的分支来做产品发布的准备工作。在这一步，发布的版本号也最初确定下来。

git checkout -b release-0.1 develop

这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似，不同之处在于它是专为产品发布服务的。
一旦A创建了这个分支并把它推向中央仓库，这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。
A完成了发布

一切准备就绪之后，A就要把发布分支合并入master和develop分支，然后再将发布分支删除。注意，往develop分支的合并是很重要的，因为开发人员可能在发布分支上修复了一些关键的问题，而这些修复对于正在开发中的新功能是有益的。再次提醒一下，如果A所在的团队强调代码评审（Code Review），此时非常适合提出这样的请求。

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支扮演的角色是功能开发（develop）与官方发布（master）之间的一个缓冲。无论什么时候你把一些东西合并入master，你都应该随即打上合适的标签。

git tag -a 0.1 -m"Initial public release" master
git push --tags

Git支持钩子（hook）的功能，也就是说，在代码仓库里某些特定的事件发生的时候，可以执行一些预定义的脚本。因此，一种可行的做法是：在服务器端配置一个钩子，当你把master推送到中央仓库或者推送标签时，Git服务器能为产品发布进行一次自动的构建。
用户发现了一个bug

当一次发布完成之后，A便回去与B一起开发其他功能了。突然，某个用户提出抱怨说当前发布的产品里有一个bug。为了解决这个问题，A（或者B）基于master创建了一个用于维护的分支。她在这个分支上修复了那个bug，然后把改动的代码直接合并入master。

git checkout -b issue-#001 master
# Fix the bug
git checkout master
git merge issue-#001
git push

跟用于发布的分支一样，在维护分支上的改动也需要合并入develop分支，这一点是很重要的！因此，小马务必不能忘了这一步。随后，她就可以将维护分支删除。

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

上面介绍的是git flow 的详细过程，但是这样开发起来会接的是否麻烦，git flow对其进行了封装简化。

git-flow使用参考

• 初始化: 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 init
  

  这个命令会进行一些默认的配置，可以自动创建上面介绍的所有分支：master、develop、feature、relase、hotfix等分支。
  完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始:
  当进行新功能开发的时候：

  git flow feature start some_awesome_feature
  

  完成功能开发之后:

  git flow feature finish some_awesome_feature
  

  该命令将会把feature/some_awesome_feature合并到develope分支，然后删除功能(feature)分支。
  将一个 feature 分支推到远程服务器

  git flow feature publish some_awesome_feature 或者 git push origin feature/some_awesome_feature
  

  当你的功能点都完成时（需要发布新版本了），就基于develop创建一个发布(release)分支。

  git flow release start v0.1.0
  

  当你在完成（finish)一个发布分支时，它会把你所作的修改合并到master分支，同时合并回develop分支，所以，你不需要担心你的master分支比develop分支更加超前。
  当系统出现问题的时候，需要进行紧急修改的时候，就好基于master创建一个维护（hotfix）分支。
  

  git flow hotfix start v0.1.0
  

  当你在完成（finish)一个维护分支时，它会把你所作的修改合并到master分支，同时合并回develop分支。

  git原理简介

  git存储信息简介

  Git 是一个内容寻址文件系统。 这意味着，Git 的核心部分是一个简单的键值对数据库（key-value data store）。 你可以向 Git 仓库中插入任意类型的内容，它会返回一个唯一的键，通过该键可以在任意时刻再次取回该内容。
  git存储的文件信息包括：文件，目录结构，提交节点，标签。
  文件（data）：储存对应文件的文件内容，不包括文件名等其他信息。然后将这些信息经过SHA1哈希算法得到对应的哈希值，作为这个object在git仓库中的唯一身份证。
  目录结构（tree）：工程的目录结构，每个文件及子文件夹的权限，类型，对应的身份证（SHA1值）、以及文件名
  提交节点（commit）：对应目录结构的快照tree的哈希值，上一个提交的哈希值，提交的作者以及提交的时间，最后是改提交的信息。
  标签：tags，标签引用类似提交节点。但区别在于标签引用并非一定要指向树对象，一般指向提交节点。但也可设定让其指向其他git对象。
  

  更改一个文件示例

  当文件更改时，首先会在git仓库生成一个新的blob文件用于储存更改过的文件信息。（git add .命令时进行此步骤）
  然后根据当前的索引，生产一个tree object（目录结构），充当一个新的提交快照。创建一个新的commit object（提交节点），将本次commit的信息储存起来，并且parent指向上一个commit，组成一条链记录变更历史。将master分支的指针移到新的commit结点。
  git更新文件图例

git引用

分支（branch）：一个指向某一系列提交之首的指针或引用。新创建的分支将包含当前提交节点及之前的提交记录。
HEAD：HEAD文件通常是一个符号引用，指向目前所在的分支。所谓符号引用，表示它是一个指向其他引用的指针。在某些罕见的情况下，HEAD文件可能会包含一个git对象的SHA-1值。当你在检出一个标签，提交或远程分支，让仓库变成“分离HEAD”状态时，就会出现这种情况。
远程引用：远程引用和分支（位于 refs/heads 目录下的引用）之间最主要的区别在于，远程引用是只读的。 虽然可以 git checkout 到某个远程引用，但是 Git 并不会将 HEAD 引用指向该远程引用。因此，你永远不能通过 commit 命令来更新远程引用。 Git 将这些远程引用作为记录远程服务器上各分支最后已知位置状态的书签来管理。