我有一个拉取请求 ,我正在尝试删除此问题,包括拉取请求正文中的特殊关键字语法(例如“resolve #5”)。
github上的文档说:
很长一段时间以来,都可以通过提交来关闭问题,但有些问题比单个提交需要更多的工作才能关闭。这就是为什么您现在可以通过拉取请求关闭问题。您所要做的就是在 Pull 请求的正文中包含特殊的关键字语法(例如“fixes #5”)。
当 PR 合并到默认分支时,引用的问题将自动关闭。
在合并之前,您甚至会看到引用作为待处理的修复。
但是我在关闭问题的问题中没有信息“一旦拉取请求xxx合并到master中,这个问题就会关闭”,当我将此拉取请求合并到master中时,问题没有关闭。我的错误是哪一个?
我在 Github 上有两个包含相同项目的存储库,但它们不是另一个的分支。
有没有一种方法可以从一个存储库向另一个存储库发出拉取请求?有没有办法将这两个存储库声明为分叉?
我们有一组标准的审阅者,并且需要来自共享代码存储库的 3 个不同组的指定数量的批准。进入共享存储库的开发分支的任何代码都需要包含完整的审阅者列表,并且需要 3 个组中每组的 3 个人(总共 9 人)的批准。为了在 Bit Bucket 中实现这一目标,我们有 3 组审阅者,每组需要 3 名批准。这些规则适用于所有分支机构,并且该部分效果很好。
我们有一个例外,总共只需要 3 个批准,并且我们使用分支前缀 (translations/) 来进行那些更琐碎的更改。我可以使用该分支模式指定一组具有不同批准的不同默认审阅者,但在我们可以合并之前,Bit Bucket 仍然需要 9 个批准的默认要求,因为它适合其他 3 个要求的任何分支模式。
我如何配置 Bit Bucket,以便翻译拥有较小的审阅者集并且只需要 3 个批准,但每个其他分支将包括所有审阅者并需要 9 个批准(每组 3 个)。
是否有 github Pull 请求允许的 url 参数的完整列表?
我知道"w=1"可以用来忽略文件差异中的空白更改,并且类似的东西"ts=4"可以用来重置制表位宽度。
我已按照本文恢复了来自 GitHub 的拉取请求https://help.github.com/articles/reverting-a-pull-request/恢复了来自 GitHub 的拉取请求恢复了来自 GitHub 的拉取请求。现在,即使在恢复后,当我比较两个分支时,它也显示相同。我如何再次提出拉取请求?
\n\n这是我所做的
\n\n我做错了什么以及如何使release/13.0.0 恢复到与以前相同的状态?
\n我正在重新认识 git。我对变基不太熟悉,我想开始使用它。
我正在合作的团队不允许提交到我们的主分支。我们必须创建一个功能分支,然后创建一个拉取请求。
当我是唯一一个在功能分支上工作的人时,我希望让我的功能分支与主分支保持同步,并且我希望在创建拉取请求之前在最后添加我的提交。
因此,我的计划是继续研究我的功能分支,并定期与(在?)master 上进行 rebase。当我准备好提交拉取请求时,这会将我的所有提交保留在更改历史记录的末尾吗?
协作者在 Github 存储库上创建了基于master分支的拉取请求。我想将其合并到我当前正在处理的下一个发布分支 ( 2.0.3) 而不是master分支。正如几个答案所指出的,我可以通过单击拉取请求标题旁边的“编辑”,然后更改基本分支来完成此操作。
但是,当我这样做时,我收到一条警告“旧基础分支的一些提交可能会从时间线中删除”。Github帮助页面还指出,“当您更改拉取请求的基本分支时,某些提交可能会从时间线中删除。”
谁能解释一下这个警告指的是哪个提交,以及它们何时可以被删除?这些提交是在master分支、拉取请求还是新的基础分支 ( 2.0.3) 中?“从时间线中删除”是指 Github 上拉取请求的讨论页面,还是意味着从存储库中删除提交?
更新
正如 @RomainValeri 指出的,此过程不会从存储库中添加或删除任何提交,它只是更改拉取请求中显示的提交,因为其中一些可能不再位于分支的基础和提示之间。然而,尖端仍将与以前相同的最终状态。
就我而言,拉取请求 ( feature) 在我的请求之后分支出来master,如下所示:
A---B---C---D <<< master
\ \
\ E---F <<< feature (pull request)
\
G---H <<< 2.0.3
Run Code Online (Sandbox Code Playgroud)
因此,当我将拉取请求的基础从 更改为 时master,2.0.3它现在报告拉取请求包括提交 C、D、E 和 F,而不仅仅是 E 和 F。但是我不希望拉取请求中包含 C 和 D,所以我先合并master到2.0.3. 这给出了这个:
A---B---C---D ---<<< master
\ \ \
\ \ E---F <<< …Run Code Online (Sandbox Code Playgroud) 我已经向这个项目提出了 Pull 请求,该项目归 google 所有。因此,谷歌要求提供贡献者许可协议。我已经在这里签名了。我创建了 CLA。
首先,我认为我的 github 帐户中有两个电子邮件地址。因此,我还为这两个电子邮件 ID 创建了 CLA。
为了提交代码,我使用简单的方法: git add 。git commit -m '消息' git push -u origin 分支名称
谷歌机器人仍然无法验证我的 CLA。它给了我如下错误:
错误消息:我们为您(此拉取请求的发送者)找到了贡献者许可协议,但无法找到所有提交作者或共同作者的协议。如果您创作了这些内容,也许您在 git 提交中使用的电子邮件地址与签署 CLA 时使用的电子邮件地址不同(在此处登录以仔细检查)?如果这些内容是由其他人创作的,那么他们也需要签署 CLA,并确认他们同意将这些内容贡献给 Google。为了通过此检查,请解决此问题并让拉取请求作者添加另一个评论,机器人将再次运行。如果机器人不发表评论,则意味着它认为没有任何变化。
我已经为与我的 Github 帐户关联的两个电子邮件 ID 创建了 CLA。
我已启用双因素身份验证。
我已经一再承诺检查。我在 PR 上发表了评论,以检查 google-bot 是否解决了问题。
git add .
git commit -m 'Message'
git push -u origin branch_name
Run Code Online (Sandbox Code Playgroud)
如果有人过去遇到过此问题并成功解决,请描述完整的解决方案。
在拉取请求中,如果我添加了超过 15 个审阅者,一些现有的审阅者将从拉取请求中删除。这是已知行为吗?如果是这样,我找不到支持此操作的 Github 官方文档。
pull-request ×10
git ×7
github ×6
azure-devops ×1
bitbucket ×1
commit ×1
git-commit ×1
git-fork ×1
git-revert ×1
github-api ×1
googlebot ×1
pull ×1
rebase ×1