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 マスター (アップストリーム) にマージした後、マスターをローカルにプルします。機能ブランチをオリジンにプッシュする前にリベースを行うべきではありませんか?

もう 1 つの疑問は、アップストリーム マスターからローカル ブランチへのプルを実行したら、そのマスターをオリジン (フォークされたリポジトリ) にプッシュすべきではないかということです。

編集: ここでは、ワークフローを図で見ることができます:ダイアグラム ワークフロー

これらの疑問を明確にしていただきありがとうございます。

4

1 に答える 1

2

まず第一に、git rebase は共有コードにとって危険です。リベースは実際には履歴の書き換えであり、コミット ハッシュも変更されます。これは、過去に行われたコミットを (コードを共有しているときに) 再適用する必要があると git が考える可能性があり、これが大きな頭痛の種になる可能性があることを意味します。ほとんどの場合、リベースは避けます。

オリジンには 2 つの異なるリモート URL が必要です。1 つはプッシュ用、もう 1 つはフェッチ用です。フェッチするリモートがメイン リポジトリになり、プッシュするリモートがフォークされたリポジトリになります。このようにして、メイン リポジトリから最新のマスターをプルし、ブランチをスカッシュしてマージし、マスター ブランチをフォークされたリポジトリにプッシュしてから、プル リクエストを要求するだけです。

次のように、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 に答える