Git 学习笔记 —— Git Flow、Git Commit 规范

目录

Git相关名词解释

Pull Request

Issue

各个分支的解释及其使用

主分支 Main Branch

辅助分支 Supporting Branch

关于Fast Forward

关于常用命令及SourceTree

下载SourceTree

SourceTree的使用

常见问题解决方案

Git commit 规范

格式

Header

type

scope

Subject

Body

Footer

Revert

---

Git相关名词解释

Pull Request

我尝试用类比的方法来解释一下 pull reqeust。想想我们中学考试，老师改卷的场景吧。你做的试卷就像仓库，你的试卷肯定会有很多错误，就相当于程序里的 bug。老师把你的试卷拿过来，相当于先 fork。在你的卷子上做一些修改批注，相当于 git commit。最后把改好的试卷给你，相当于发 pull request，你拿到试卷重新改正错误，相当于 merge。

——From 知乎

自己的部分完成之后，Push上去，并创建Pull Request，等待合并

 

Issue

项目中遇到什么问题、或者发现什么好的工具，全都放到自己的ISSUE下

1. Labels，标签。包括 enhancement、bug、invalid 等，表示 issue 的类型，解决的方式。除了自带的以外，也可以去自定义。
2. Milestone，里程碑。几经修改后，它现在已经与git tag和Github release区分开来，仅仅作为issue的一个集合。通常用来表示项目的一个阶段，比如demo、release等，保护达成这些阶段需要解决的问题。有时候，也会与版本计划重合，比如v1.0、v2.0等。issue不能设置截止时间，但是milestone可以。
3. Assignee，责任人。指定这个 issue 由谁负责来解决。

充分利用这些功能，让每一个 commit 的意义更加明确，可以起到了良好的过程管理作用，使得这个 Git 库的项目进度更加显然。而且，这也是项目后期，写文档的绝佳素材。

各个分支的解释及其使用

整体参照

主分支 Main Branch

在Git分支模型中存在两个主分支，这两个分支是不可或缺的：

主分支 Main Branch

 

1. 生产分支 Master Branch

master作为Git中默认的主分支。在Git分支开发模型中，master分支的HEAD节点始终处于“准备好进行生产的状态”，即master分支的HEAD节点所指向的版本始终是可以用于生产环境的正式版本。当其他分支的代码版本合并到master分支时（随后打上版本标签，所有在Master分支上的Commit应该Tag），通常意味着一个新的正式版本已经发布。

1. 开发分支Develop Branch

develop分支作为另一个主分支，其HEAD节点总是指向下一个待发布版本的最新变化。develop分支的版本变更通常来源于辅助分支的合并，因为develop分支也常被称为“整合分支”。当develop分支达到某一稳定点，可进行新版本的发布时，develop分支上的所有变更应该被合并到master分支并打上tag标签。

辅助分支 Supporting Branch

除了master分支和develop分支这两个主分支以外，Git分支模型中拥有一些“辅助分支”，在团队开发中对develop分支和master分支进行帮助，例如对新需求的研发（feature），新版本发布前的准备工作（release）以及新版本bug的紧急修复（hotfix）等。和主分支不同的是，这些分支的生命周期都是很有限的，最终都将会被删除

1. 需求分支 Feature Branch

需求分支 Feature Branch

分支意义	需求分支用于为未来的软件版本开发新的功能需求。当进行一个需求的研发时，该需求将被整合进正式版本是未知，所以需要单独创建分支对该需求进行研发，只要该需求尚在开发中，该需求分支就会一直存在。需求分支最终会被合并到develop分支中作为下一个待发布版本的功能之一，或者由于该需求无法实现从而被抛弃。
分支来源	develop
分支去向	develop
分支命名	任意名称，除master，develop，以“release-”开头，以“hotfix-”开头的分支以外
创建命令	创建需求分支时，该分支必须从develop分支得到 git checkout -b feature_branch develop git branch feature_branch develop git checkout feature_branch 以上两种创建方式等价
合并命令	git checkout develop           #切换到develop分支 git merge --no-ff feature_branch #合并分支 git branch -d feature_branch    #删除需求分支 git push origin develop         #推送 --no-ff表示No Fast Forward，必须加此参数（Fast Forward的解释放在后面）
注意点	需求分支通常仅仅存在于开发者的本地代码仓库中，并不上传到远程分支。 上述命令中的feature_branch不代表一定要使用这个名字来创建需求分支

1. 发布分支 Release Branch

发布分支 Release Branch

分支意义	修复分支用于正式版本的紧急修复，在紧急修复完成以后必须同时被合并到master分支和develop分支，这是修复分支和发布分支不同之处(二者的来源也不同)，和发布分支类似，修复分支在修复bug，提交，被合并以后，也要进行tag操作。
分支来源	develop
分支去向	develop、master
分支命名	以"hotfix-"开头
创建命令	git checkout -b hotfix-1.2.1 master     #从master创建hotfix分支 vim file                          #表示修复bug git commit -a -m "修复bug"         #提交到本地 vim file                          #表示更新版本号 git commit -a -m "版本更新为1.2.1"  #每次提交都应该附上变动内容
合并命令	git checkout master                #从hotfix分支切换到master分支上 git merge --no-ff hotfix-1.2.1        #执行merge操作，记得使用--no—ff参数 git tag -a 1.2.1                    #打tag操作 git checkout develop               #也要切换到develop分支，进行hotfix的合并 git merge --no-ff hotfix-1.2.1        #执行merge，记得使用--no—ff参数 git branch -d hotfix-1.2.1           #完成修复后必须要做的是删除分支
注意点	如果在发布分支进行小型bug的修改，则需要将提交后的代码合并到develop中

关于Fast Forward

当前分支合并到另一分支时，如果没有分歧解决，就会直接移动文件指针。这个过程叫做fast forward。

例如，开发一直在master分支进行，但忽然有一个新的想法，于是新建了一个develop的分支，并在其上进行一系列提交，完成时，回到 master分支，此时，master分支在创建develop分支之后并未产生任何新的commit。此时的合并就叫fast forward，如下图：

其中--squash用于将几个提交合并为一个

很明显使用--no-ff合并时，在删除develop分之后，该分支的合并信息仍然被保留，在以后的代码分析中可以便捷的查看到历史信息，而fast forward方式则无法辨识代码的合并信息。 所以务必在提交时使用--no—ff

 

关于常用命令及SourceTree

下载SourceTree

下载链接

SourceTree的使用

1. Clone仓库

1. Push推送分支

点击 

请推送的自己负责的相关分支上，不要触及其他分支（特别是develop与master）

1. Fetch获取分支

使用Fetch获取远端仓库（pull与fetch的区别详解）

点击顶部的这个 获取 按钮

 然后再确定

常见问题解决方案

Q:出现SSH密钥认证失败 

 

A:git克隆仓库时，代码托管平台识别身份不是通过账号密码登录，而是私钥，点击是打开SSH代理

然后会显示如下信息

去托盘寻找一个小电脑图标 ，双击它，在弹出的窗口中点击Add Key

添加密钥，密钥不一定要存放在这个文件夹，放在哪里都可以

 

找到你自己账号下的私钥，进行导入。密钥生成往后看

Q:要去哪里生成自己的密钥

A:安装好SourceTree后，电脑会带有ssh、git（如果没有则请安装git）以及PuTTY，我们需要使用ssh工具来生成密钥，并通过PuTTY的一个PuTTYgen转化为SourceTree需要的密钥

打开CMD/Powershell/Bash其一，输入ssh-keygen并回车

不设置文件路径的话（路径需要包括名字），就会在默认路径下生成默认文件名的密钥文件如下

打开PuTTYgen，点击Conversions -> Import Key，找到刚刚生成的无后缀的文件（也就是上面的id_rsa文件，这个是私钥），双击导入，图示如下

选择一个位置保存好PuTTY转换的私钥文件（只有.ppk结尾的私钥文件才能导入到PuTTY的密钥代理里）

Q:那公钥有什么用呢？

A:放到各个代码托管平台上，用来与私钥进行验证，公钥设置步骤如下（以Gitee为例）

 

 

Git commit 规范

格式

(): // 空一行 // 空一行

Header

包含三个字段：type（必需）、scope（可选）、subject（必需）

type

内容	含义	备注
feat	新功能	feature
fix	修补bug
docs	文档	documentation
style	格式	不影响代码运行的变动
refactor	重构	既不新增功能，也无bug修复
test	增加测试
chore	构建过程或辅助工具的变动

scope

scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

Subject

• subject是 commit 目的的简短描述，不超过50个字符。

• 以动词开头，使用第一人称现在时，比如change，而不是changed或changes，第一个字母小写，结尾不加句号（.）

Body

Body 部分是对本次 commit 的详细描述，可以分成多行。下面是一个范例。

More detailed explanatory text, if necessary.  Wrap it to about 72 characters or so.   Further paragraphs come after blank lines.   - Bullet points are okay, too - Use a hanging indent

注意

• 使用第一人称现在时，如使用change而不是changed或changes
• 应当说明代码变动的动机，以及与以前行为的对比

Footer

Footer部分只用于两种情况

• 不兼容的变动

如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。

BREAKING CHANGE: isolate scope bindings definition has changed.       To migrate the code follow the example below:       Before:       scope: {       myAttr: 'attribute',     }       After:       scope: {       myAttr: '@',     }       The removed `inject` wasn't generaly useful for directives so there should be no code using it.

• 关闭ISSUE

如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。

Closes #234

也可以一次关闭多个 issue 。

Closes #123, #245, #992

Revert

还有一种特殊情况，如果当前 commit 用于撤销以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header。

revert: feat(pencil): add 'Width' option   This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Body部分的格式是固定的，必须写成This reverts commit . 其中的hash是被撤销 commit 的 SHA 标识符。

注意：如果当前 commit 与被撤销的 commit，在同一个发布（release）里面，那么它们都不会出现在 Change log 里面。如果两者在不同的发布，那么当前 commit，会出现在 Change log 的Reverts小标题下面。