Question

这就是我现在所拥有的：

1 Github remote (origin)
2 Heroku (staging and production)

工作流程如下：

第一次（设置）：

1 - Fork public Github (upstream) into public Github <br>
2 - Clone from public Github into local

开发工作流程：

1 - Checkout feature-branch from local master
2 - After all commits, squash them
3 - Push that branch (with one commit) into origin
4 - Do a pull request to public Github
5 - Merge into public Github master
6 - Do a pull of master into local
7 - Do a rebase here??
8 - Push local master into Heroku Staging (do testing...)
9 - Push local master into Heroku Production

这是他们建议我做的，但我有些疑惑。在执行了pull请求并合并到公共Github master（上游）之后，我将master拉到本地，然后为什么rebase在这里有意义？在将功能分支推送到原点之前，我不应该执行rebase吗？

另一个疑问是，一旦我完成从上游主机到本地分支的拉动，我不应该将该主机推入原点（我的分叉存储库）吗？

编辑：您可以在此处以图表方式查看工作流程：Diagram workflow

感谢您澄清这些疑虑。

Answer 1

首先，git rebase对共享代码很危险。 Rebasing实际上是历史重写，它也会改变提交哈希值。这意味着git可能会认为过去提交的提交需要重新应用（当您共享代码时），这可能最终成为一个令人头疼的问题。我大部分时间都避免变质。

我希望有2个不同的远程网址来源。一个用于推送，一个用于提取。获取远程数据库将是主存储库，推送远程数据库将是分叉存储库。这样你从主存储库中提取最新的master，与你的分支合并，将master分支推入forked存储库，然后只是请求pull请求。

您可以将URL设置为主存储库，如下所示：

git remote set-url origin <main_repo_url_here>

然后，将forked url设置为仅用于推送：

git remote set-url --push origin <forked_personal_repo_url_here>

你可以检查这样的结果：

git remote -v

Git工作流程 - 在推送到公共回购之前或之后合并主人？

1 个答案: