如何优雅地pullrequest
本⽂章主要⽤于阐述pr流程，以及可能遇到的情况和解决⽅案，帮助⼤家更好地协作开发。
提交更改是什么Pull Request请求通常由使⽤共享存储库协作的团队和组织使⽤。
Github上的许多开源项⽬使⽤pull request请求来管理来⾃贡献者的更改，因为它们提供了⼀种⽅式来通知项⽬维护者其他贡献者所做的更改，并且在合并到主分⽀之前，能对代码进⾏review和对此进⾏讨论。
主要有两种进⾏pull request的⼯作流程；
对⼀个forked仓库进⾏pull request；
对⼀个仓库⾥的分⽀进⾏pull request；
本⽂主要对第⼀种⽅式进⾏讲解。
1. Fork仓库
1. 将需要参与的项⽬仓库fork到⾃⼰的github中；
2. git clone这个fork的项⽬
1. 将⾃⼰的github中，到fork下来的项⽬，git clone 到本地。
3. 添加上游仓库
1. 接着上⼀步，在该项⽬中，执⾏以下操作，将上游仓库连接到本地仓库，即我们fork的地址：
git remote add <name> <url>复制代码
1. 其他辅助功能：
git remote -v  //查看所有上游仓库名字和git地址：复制代码
4. 保持与上游仓库的同步
1. 更新 "指定" remote 底下的分⽀：
git fetch <name> <branch>复制代码
2. 上⾯这个指令，⼀次只能更新⼀个remote，如果我们有多个remote时，可以使⽤：
git remote update
//或者
git fetch --all复制代码
3. 当我们使⽤pull命令拉取上游分⽀的最新代码时，如果本地分⽀落后于上游分⽀，会产⽣⼀个新的merge commit 多余信息，因此建
议使⽤：
git pull --rebase <remote> <branch>
//等同于以下两条命令
git fetch <remote> <branch>
git rebase <remote>/<branch>复制代码
5. 提出issue
issue对你的项⽬，提供了⼀种很好的⽅式去追踪，加强，修复bug。它有点像是邮件，但是它可以被⼀起讨论。
对于项⽬维护者
1. 建议项⽬维护者维护项⽬的issue模板，贡献者们按着这个模板提issue；
2. 有两种⽅式创建issue模板：
1. 通过github创建：/
2. 第⼆种⼿动创建⼀个issue模板：/
⽰例：
（1）在项⽬中，新增⼀个bug模板和⼀个feature模板⽂件:
其中bug_request模板的内容如下：
（2）此后，贡献则在github中打开issue可看到对应模板选项：
选择feature request，便可根据要求填写：
3. 必须要在默认分⽀中创建issue模板。
对于贡献者
1. 在new⼀个pull request之前，最好的做法是先提出⼀个issue，供⼤家讨论；
2. 请在issue中参照issue规范，提供⾜够多的信息来帮助别⼈理解；
3. 请为⾃⼰的issue添加对应的标签，以便可以⽅便对issues进⾏分类和过滤：
1. Assigns是受委托⼈——负责推进issue的⼈；
2. ⼀个issues可以有多个Label；
3. Milstone对应于项⽬，功能或时间段的issue组：⽐如版本号，具体截⽌时间，重构新功能等。
4. 可以对提交的issue进⾏订阅，得知issue的推进情况：
6. ⽣成⼀个新分⽀
1. 建议贡献者创建⼀个⾃⼰的新分⽀，在该分⽀上进⾏操作，最后通过pull request⽅式合并到主分⽀上。
git checkout -b feature_x //不加-b则是切换到某⼀分⽀上，加上-b就是创建且切换复制代码
1. 最后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
Breaking Changes：
如果当前代码与上⼀个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后⾯是对变动的描述、以及变动理由和迁移⽅法。这种使⽤较少，了解即可。
Issue部分：
通过commit关联issue：
如果当前提交信息关联了某个issue，那么可以在 Footer 部分关联这个 issue：
issue #2复制代码
默认分⽀时，提交信息⾥可以使⽤ fix/fixes/fixed , close/closes/closed 或者通过commit关闭issue，当提交到默认分⽀
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记录已经变为：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。