4

したがって、GitHubには、PR のコミットをマージ + スカッシュする機能があります。

dev->からコードを PR するプロセスに従いますmaster。

以前は、PR を単に 'マージ' していましたが、それによって " Merge Pull Request #1 from foo/bar" という新しいコミットが生成されます。:( ブー...

Squash Commitsだから私はGHで新しいことを試してみようと思った. これにより、以前のすべてのコミットが押しつぶされた新しいコミットが作成されました。わかりました、これまでのところとても良いです。

それから私は自分のブランチ (私の開発者マシン上) に戻りましたdev.. プルダウンupstream/master(ここで PR と squash-merge が行われました))すると、私のローカル履歴に別のコミットが追加されました! 「ああ..うわー.あなたはラインから外れています..同期しましょう」には行きませんでした。マージしただけです。

したがって、Squash+Merge ボタンは 4 つのコミットを押しつぶし、それを 1 つに置き換えました...upstream/master私のローカルホスト マシンのプルには、まだ 4 つのコミットがあり、PR が実行した Squashed-commit と、新しいコミット " Merge branch master .. blah ... noise ..spam" commit :( : ( :(

ブランチが適切に同期されていることを確認するために、マージスカッシュが発生した後に実行する必要がある特別なトリック/ワークフローはありますか? dev.. 同様に、ローカルホストにプルダウンして (新しく作成された)ブランチに戻すdev前に、誰もがローカルホスト ブランチを削除するだけですか?upstream/masterdev

覚えておいてください: ここでの目標は、くだらない "Merge Pull Request #2.."マージ バブルメッセージを回避することです。

それとも、GitHubがこれを行う方法を学ぶまで、当面の間、CLI経由でこれを行うだけですか:(

4

3 に答える 3

5

問題はワークフローにあると思います。通常、プル リクエストをマージすると (どの方法を使用しても)、そのブランチは完了します。さらに変更を加えたい場合は、現在のアップストリーム/マスターから新しい機能ブランチを作成し、後で別のプル リクエストを開いてマージすることをお勧めします。

すべての開発で 1 つの長期的なブランチ ( devと呼ぶブランチ) に本当に固執したい場合は、覚えておく必要があるいくつかの注意事項があります。

  • そのブランチで作業しているのがあなただけではない場合は、履歴の書き換えを避ける必要があります。リベースも、スカッシュも、リセットも、コミットの修正もありません。これは基本的に、スカッシュ マージの使用を除外します。
  • そのブランチで作業しているのは自分だけであり、GitHub の squash オプションを使用してプル リクエストをマージする場合は、そこで作業を再開する前に、ローカルdevブランチを最新のアップストリーム/マスターにリセットする必要があります。これは、後で新しいプル リクエストを作成するためにアップストリームに強制的にプッシュする必要があることも意味します。

最後のポイントはエラーが発生しやすく、以前のコード レビューに影響するため、個人的には有効期間の短い機能ブランチのみを使用することを選択します。

于 2016-10-21T10:31:08.617 に答える
1

ブランチがマージされてつぶされた場合devは、もう必要ありません。にリセットするだけupstream/masterです。

新しい変更がある場合は、git rebase -i upstream/master代わりに呼び出して、マージされたすべてのコミットを削除し、残りをリベースできます。

于 2016-07-26T09:04:59.047 に答える
-1

"Merge Foo branch in Bar" という追加のコミットなしで、コミットをマージおよびスカッシュするためのより良い解決策があります。マージしてからスカッシュするよりも、常にリベースを優先する必要があります。したがって、リベースは、追加のコミットなしで 2 つのブランチをマージするのに役立ちます。マージする代わりに、ブランチをリベースしてみてください。ここに同じ詳細な説明があります here .

于 2016-07-25T05:14:55.283 に答える