如何优雅地pull request

时间 2019-11-06

标签如何优雅 pull request 繁體版

原文原文链接

本文章主要用于阐述pr流程，以及可能遇到的状况和解决方案，帮助你们更好地协做开发。html

若是须要了解git基础知识，请查看如下连接：git

[git协做经常使用命令](juejin.im/post/5b5596…)
github

Pull Request请求一般由使用共享存储库协做的团队和组织使用。 shell

Github上的许多开源项目使用pull request请求来管理来自贡献者的更改，由于它们提供了一种方式来通知项目维护者其余贡献者所作的更改，而且在合并到主分支以前，能对代码进行review和对此进行讨论。npm

主要有两种进行pull request的工做流程；bash
- 对一个forked仓库进行pull request；微信
- 对一个仓库里的分支进行pull request；工具

本文主要对第一种方式进行讲解。post

1. Fork仓库

将须要参与的项目仓库fork到本身的github中；测试

2. git clone这个fork的项目

将本身的github中，找到fork下来的项目，git clone 到本地。

3. 添加上游仓库

接着上一步，在该项目中，执行如下操做，将上游仓库链接到本地仓库，即咱们fork的地址：

git remote add <name> <url>复制代码

其余辅助功能：

git remote -v  //查看全部上游仓库名字和git地址：复制代码

4. 保持与上游仓库的同步

更新 "指定" remote 底下的分支：
```
git fetch <name> <branch>复制代码
```
上面这个指令，一次只能更新一个remote，若是咱们有多个remote时，可使用：
```
git remote update
//或者
git fetch --all复制代码
```
当咱们使用pull命令拉取上游分支的最新代码时，若是本地分支落后于上游分支，会产生一个新的merge commit 多余信息，所以建议使用：

git pull --rebase <remote> <branch>
//等同于如下两条命令
git fetch <remote> <branch>
git rebase <remote>/<branch>复制代码

5. 提出issue

issue对你的项目，提供了一种很好的方式去追踪，增强，修复bug。它有点像是邮件，可是它能够被一块儿讨论。

对于项目维护者

建议项目维护者维护项目的issue模板，贡献者们按着这个模板提issue；
有两种方式建立issue模板：
- 经过github建立：help.github.com/articles/cr…/
- 第二种手动建立一个issue模板：help.github.com/articles/ma…/
  示例：
  （1）在项目中，新增一个bug模板和一个feature模板文件:
  其中bug_request模板的内容以下：
  （2）此后，贡献则在github中打开issue可看到对应模板选项：
  选择feature request，即可根据要求填写：
- 必需要在默认分支中建立issue模板。

对于贡献者

在new一个pull request以前，最好的作法是先提出一个issue，供你们讨论；
请在issue中参照issue规范，提供足够多的信息来帮助别人理解；
请为本身的issue添加对应的标签，以即可以方便对issues进行分类和过滤：
- Assigns是受委托人——负责推动issue的人；
- 一个issues能够有多个Label；
- Milstone对应于项目，功能或时间段的issue组：好比版本号，具体截止时间，重构新功能等。
能够对提交的issue进行订阅，得知issue的推动状况：

6. 生成一个新分支

建议贡献者建立一个本身的新分支，在该分支上进行操做，最后经过pull request方式合并到主分支上。

git checkout -b feature_x //不加-b则是切换到某一分支上，加上-b就是建立且切换复制代码

最后push的时候，要使用：
```
git push --set-upstream origin <分支名>复制代码
```
将新分支提交到远程仓库中。
若是上游仓库也须要创建这个分支，这可使用：
```
git push --set-upstream <remote> <分支名>复制代码
```

7. 提交commit信息

在对项目做出更改后，咱们须要生成commit来记录本身的更改。如下是Angular对commit格式的规范：

(1) 格式

提交信息包括三个部分：Header，Body 和 Footer。

<Header>

<Body>

<Footer>复制代码

其中，Header 是必需的，Body 和 Footer 能够省略。

1> Header

Header部分只有一行，包括俩个字段：type（必需）和subject（必需）。

<type>: <subject>复制代码

type

type用于说明 commit 的类别，可使用以下类别：

feat：新功能（feature）
fix：修补bug
doc：文档（documentation）
style：格式（不影响代码运行的变更）
refactor：重构（即不是新增功能，也不是修改bug的代码变更）
test：增长测试
chore：构建过程或辅助工具的变更

subject

subject是 commit 目的的简短描述。

以动词开头，使用第一人称如今时，好比改变，而不是改变了。
结尾不加句号（。）

2> 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复制代码

注意：应该说明代码变更的动机，以及与之前行为的对比。

3> Footer

Footer 部分应该包含：(1)Breaking Changes; (2)关闭issue；

Breaking Changes：

若是当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变更的描述、以及变更理由和迁移方法。这种使用较少，了解便可。

Issue部分：

经过commit关联issue：
若是当前提交信息关联了某个issue，那么能够在 Footer 部分关联这个 issue：
```
issue #2复制代码
```
经过commit关闭issue，当提交到默认分支时，提交信息里可使用 fix/fixes/fixed , close/closes/closed 或者 resolve/resolves/resolved等关键词，后面再跟上Issue号，这样就会关闭这个Issue：

Closes #1复制代码

注意，若是不是提交到默认分支，那么并不能关闭这个issue，可是在这个issue下面会显示相关的信息表示曾经想要关闭这个issue，当这个分支合并到默认分支时，就能够关闭这个issue了。

以下图所示，为向默认分支提交关闭issue的commit：

而在别的分支想要关闭时：

4> 例子

下面是一个完整的例子：

feat: 添加了分享功能

给每篇博文添加了分享功能

- 添加分享到微博功能
- 添加分享到微信功能
- 添加分享到朋友圈功能

Issue #1, #2
Closes #1复制代码

上面的提交信息应该可以解释本身的意思了。

8. 整合commit信息，保持commit信息的干净度

(1) 经过git rebase -i清洗commit记录

咱们能够经过rebase -i完成如下目的：

编辑之前的commit信息；
将多个commit信息整合到一个；
删除commit信息。

注意这些commit都是还未被push的信息；

使用rebase -i进入交互模式

rebase 有6个选项能够选择：

pick ： pick意味着采用该commit；
reword：reword选项能够修改commit信息；
edit：能够修改commit的提交信息，不一样于reword，这个选项能够暂停rebase过程，使得你能够添加更多的commit信息，这容许您将大型提交拆分为较小的提交，或者删除提交中所作的错误更改；
squash：此命令容许您将两个或多个提交组合到一个提交中。提交被压缩到它上面的提交中。 Git让您有机会编写描述这两个更改的新提交消息。
fixup：这与squash相似，但要合并的提交会丢弃其消息。提交只是简单地合并到它上面的提交中，而且先前的提交消息用于描述这两个更改。
exec：这容许您针对提交运行任意shell命令。

例子讲解

如下是一个squash的示例：

如图，有三个commit记录：

执行git rebase -i：

进入编辑界面，若是咱们是想要合并两个commit记录则能够进行以下编辑：

commit记录已经变为：

(2) 撤销rebase 操做

执行git reflog找到commit ID；
- reflog能够查看从本地仓库建立之日起，本地所进行的与项目更改有关的操做，好比说commit，clone，rebase等操做。git log是查看当前版本库及其以前的全部commit。
- git reflog默认实际上是git reflog show Head;可使用git reflog show --all来查看全部分支的状况；
执行git reset --hard <commit ID>;

(3) 回退到某一commit状态

当想撤回某一commit记录时，能够采用回退的方式，可是注意这种方式也将使你的后续更改丢失。

执行git log命令，查看commit记录：
如上图，能够看到commit的哈希值；
若是增长--pretty=oneline参数，则能够只显示版本号和提交时的备注信息。
执行git reset --hard commit_id ：
例如咱们须要回退到新增MVC模式的上一个版本，则执行：
```
git reset a5f2a27f02d32b666e01c24ed2218598db57a183 //此为默认方式，不带任何参数的git reset它回退到某个版本，只保留源码，回退commit和index信息复制代码
```
若是是--hard参数，则完全回退到某个版本，本地工做区也会变为上一个版本的内容：
```
git reset --hard a5f2a27f02d32b666e01c24ed2218598db57a183复制代码
```
若是是--soft参数，会保留工做区和暂存区的记录，在下次能够直接commit：
```
git reset --soft a5f2a27f02d32b666e01c24ed2218598db57a183复制代码
```
这种状况下在push时，要执行：
```
git push --force 复制代码
```

9. Push到远程仓库

在push以前，应该再pull一次上游仓库，将本地commit与远程commit对比，若是远程仓库已经有个新的更新，而且与本地仓库产生冲突，那么就须要先解决冲突，接着在git add && git commit；

10. new 一个 pull request

在本身的项目中new 一个 pull request，选定哪个分支要合并到哪个分支：

选择审阅者，委托人，标签等信息；

11. 审阅者进行审阅

若是新增代码不须要运行，审阅者审阅后可进行是否merge的评定；
代码审阅者能够将该pull request的来源仓库设为上游仓库，拉取被审阅的代码，再运行，以运行结果断定是否merge；
有三个merge行为，可根据具体状况选择：

其余状况

丢弃本地全部修改（已经commit）；

git reset Head^   //可加参数--hard或者--soft 复制代码

取消已经暂存的文件，即，撤销先前"git add"的操做
```
git reset Head 复制代码
```
(未被追踪的文件不会获得更改，也就是没有执行git add的文件)

将本地状态回退到和远程的同样：

git fetch origin/master
git reset origin/master //可加参数--hard或者--soft复制代码

查看某次commit记录具体内容：

git show <commit ID> 
//也能够用
git show Head^^复制代码

cherry-pick
cherry-pick 就是挑选一个咱们须要的 commit 进行操做。它能够用于将在其余分支上的 commit 修改，移植到当前的分支，可是移植的只是一个副本，会生成一个新的commit记录。
```
1.切换到 develop 分支。
2.经过 git log,找到 C 的 SHA1 值。
3.经过 git cherry-pick <C的SHA1> ，将 C 的修改内容合并到当前内容分支 develop 中。
4.若无冲突，过程就已经完成了。若是有冲突，按正常冲突解决流程便可。复制代码
```
关于cherry-pick的其余操做能够查看后面给出的参考连接。

使用changlog打印commit信息（前提是按照angular规范书写commit信息）

npm install -g conventional-changelog-cli //安装全局包；
conventional-changelog -p angular -i CHANGELOG.md -s -r 0 //第一次使用时，执行此命令，会生成一个CHANGELOG.md文件
conventional-changelog -p angular -i CHANGELOG.md -s  //以上生成的更改日志基于自上一个semver(语义化版本)标记以来的提交。复制代码

通常在发包（release）的时候打印changlog信息，changelog其实是release的一个步骤之一。

更多操做指令请查看另外一篇git经常使用命令文档。

参考连接

pr：www.thinkful.com/learn/githu…

commit&changelog规范：www.ruanyifeng.com/blog/2016/0…

angular规范：docs.google.com/document/d/…#

github issue API：developer.github.com/v3/issues/#…

git reflog：www.atlassian.com/git/tutoria…

git rebase : help.github.com/articles/ab…/

www.cnblogs.com/dracohan/p/…

issue模板：github.com/devOpenDoce…

commit中的issue：help.github.com/articles/cl…/

changelog：www.npmjs.com/package/con…

约定式提交：conventionalcommits.org/lang/zh-Han…

Cherry-pick：blog.csdn.net/qq_32452623…