合并到 GitHub 拉取请求中,可能首先对其进行更改
我最近开始在 GitHub 上管理一个项目,人们一直在其中提交拉取请求。我希望能够:
首先审查它们以确保它们确实有效
在合并到 master 之前可能会进行一些风格上的更改, 而不是将它们合并到 master 中master
我该怎么做?
您是否必须创建一个单独的分支,例如“dev”,并指导人们在合并到 master 之前针对该分支进行编码?
I recently started managing a project on GitHub where people have been submitting pull requests. Rather than merge them to master, I would like the ability to:
First vet them to make sure they actually work
Possibly making some stylistic changes before merging to master
How can I do this?
Do you have to make a separate branch, such as "dev", and instruct people to code against that before you merge to master?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
使用 GitHub 进行操作的更快方法是使用 Zach Holman 在他的 GitHub Secrets II 演讲 (视频)。
其中
id
是拉取请求 ID,head
是远程分支(在分支上),name
是您要为其指定的名称当地分支机构。例如:将拉取请求 #12 提取到名为 pr 的分支中。
如果你经常使用它,你可以将其添加为 git 中的别名。
A faster way of doing things with GitHub is to use this GitHub feature presented by Zach Holman in his GitHub Secrets II Talk (video).
Where
id
is the pull request id,head
is the remote branch (on the fork), andname
is the name you want to give the local branch. For example:Fetches pull request #12 into a branch named pr.
You can add this as an alias in git if you use this a lot.
有一个 github 帮助页面,详细介绍了如何进行更改通过在本地检查拉取请求来处理拉取请求。
我可能尝试的是首先为拉取请求提交者创建一个远程(我使用上页中的示例):
获取更改:
查看有问题的分支(例如 master):
根据您的喜好对它们进行审查,因为那里的代码将是拉取请求代码。运行测试等。
如果你准备好了,请将它们合并:
此外,这里有一个关于 git 的非常好的页面 项目管理工作流程,其中详细介绍了协作集成可以采用的各种工作流程。
There is a github help page on this which details how to make changes to a pull request by checking out pull requests locally.
What I might try is first creating a remote for the pull request submitter (I'm using the examples from the above page):
Fetch the changes:
Check out the branch in question (ex. master):
Vet them however you like, since the code that will be there will be the pull request code. Run tests, etc.
Merge them in if you're good to go:
Further, here is a very good page on git project management workflows which details the various workflows one can take on collaboration integration.