10

私の 10 人ほどのチームは、開発プロジェクトに GitHub を使用しています。develop開発タスクを実行する機能ブランチを作成するメインブランチがあり、機能ブランチを にマージしdevelopます。プル リクエストを使用してコード レビューを行います。すべての標準的なもの。

ただし、気になることが 1 つあります。

開発者 A が という名前の機能ブランチを作成するとしmyFeatureます。このブランチで、彼は 1 つのファイルに 1 行の変更を加えますLoop.java。

その間、100 件の無関係なコミットがdevelop、他の開発者によって他のブランチからマージされます。

developここで、開発者 A は自分の変更をプッシュしてプル リクエストを発行する前に、自分の変更が最新のブランチで機能することを確認したいと考えています。したがって、彼は HEAD をdevelop自分のブランチにマージします。

git checkout develop
git pull
git checkout myFeature
git merge develop
# testing and stuff
git push origin myFeature

最後のコマンド ( git merge develop) は、常に新しいコミットになります。したがって、開発者 A が自分の変更をプッシュして のプル リクエストを発行すると、プル リクエストmyFeatureのレビュアーは 101myFeature個のコミットがブランチに追加さLoop.javaれたことを確認しdevelopます。ここでは、このブランチで developerA によって実際に変更されたものを隠すためのノイズとしてのみ機能します。

レビュアーが、開発者の A の変更だけで何が変更されたのかを簡単に確認し、何らかの形で とのマージからのコミットを「隠す」方法はありdevelopますか? 特に、プル リクエスト ビューの [Files Changed] タブについて考えています。(「コミット」タブを使用して、すべてのコミットを 1 つずつ調べて、何が変更されたかを確認できることを認識していますが、コミットが多数ある場合、これは面倒な場合があります。変更されたファイル」タブ)

EDIT :git rebase developオプションとして提案されていますが、私たちの目的には適切ではないと思います。多くの場合、複数の開発者が に取り組んでmyFeatureいるため、リベースは履歴を書き換えるため、全員を台無しにする可能性があります。

編集 2 : @kan が親切に以下で指摘したように、GitHub は実際にはうまく動作しています: はい、プル リクエストの [コミット] タブにマージ コミットが表示されますが (これはまったく問題ありません)、[変更されたファイル] タブの下に表示されます。 、このフィーチャー ブランチで変更されたファイルのみ (マージからのものではない) が一覧表示されます。これはまさに私が探しているものです。

4

2 に答える 2

7

1つの方法は、することではなく、することgit mergeですgit rebase develop。これにより、マージコミットが発生せず、開発中の新しいコミットの最後に新しいコミットが配置されます。

履歴には、プル リクエストで変更された 1 つの新しいコミットのみが表示されます。IMOこれにより、履歴がかなり直線的になり、追跡しやすくなります。

于 2013-05-01T21:03:15.083 に答える
1

はい、リベースでそれを行うことができます。

git checkout myFeature
git fetch
git rebase origin/develop
git checkout develop
git merge @{upstream}
git merge myFeature # it will do fast-forward, so no merge commit

ただし、リベースは myFeature が他の開発者間で共有されていない場合にのみ使用する必要があることに注意してください。

ところで、私たちは gerrit を使用しています。マージする前に変更セットをリベースできます。もちろん、競合がない場合にのみ機能する場合は、競合がある場合は、ローカルでリベースして変更セットを再送信する必要があります。

于 2013-05-01T21:06:48.073 に答える