3

这是我现在所拥有的：

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

这是他们建议我做的，但我有一些疑问。在执行拉取请求并合并到公共 Github 主服务器（上游）之后，我将主服务器拉到本地，那么为什么在这里使用 rebase 有意义呢？在将功能分支推到原点之前，我不应该做 rebase 吗？

另一个疑问是，一旦我从上游 master 拉到本地分支，我不应该将该 master 推送到 origin（我的分叉存储库）吗？

编辑：在这里您可以以图表方式查看工作流程：图表工作流程

感谢您澄清这些疑问。

4

1 回答 1

2

首先， git rebase 对于共享代码是危险的。变基实际上是历史重写，它也会改变提交哈希。这意味着 git 可能认为需要重新应用过去所做的提交（当您共享代码时），这最终可能会令人头疼。大多数时候我都避免变基。

我希望有 2 个不同的远程 url 作为来源。一个用于推送，一个用于获取。获取远程将是主存储库，推送远程将是分叉存储库。通过这种方式，您可以从主存储库中提取最新的 master，与 squash 分支合并，将 master 分支推送到分叉的存储库中，然后只请求拉取请求。

您可以像这样将 url 设置到主存储库：

git remote set-url origin <main_repo_url_here>

之后，仅为这样的推送设置分叉 url：

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

您可以像这样检查结果：

git remote -v

于 2013-02-17T12:39:23.957 回答