web-dev-qa-db-ja.com

コードレビュー後にプルリクエストを更新するための優先Githubワークフロー

Githubのオープンソースプロジェクトに変更を送信し、コアチームメンバーの1人からコードレビューコメントを受け取りました。

レビューコメントを考慮してコードを更新し、再送信したいと思います。これを行うための最良のワークフローは何ですか？ git/githubに関する私の限られた知識から、次のいずれかを行うことができました。

  1. コードを新しいコミットとして更新し、最初のコミットと更新されたコミットの両方をプルリクエストに追加します。

  2. どういうわけか（??）リポジトリから古いコミットをロールバックし、すべてを含む単一の新しいコミットを作成してから、そのためのプルリクエストを発行しますか？

  3. git commitには修正機能がありますが、ローカルリポジトリの外部にコミットをプッシュした後に使用すべきではないと聞いたことがありますか？この場合、ローカルPCで変更を行い、プロジェクトのgithubブランチにプッシュしました。 「修正」を使用しても問題ありませんか？

  4. 他に何か？

オプション2/3はニースだと思われます。オープンソースプロジェクトの履歴には、すべてを実装するコミットが1つしかありませんが、これを行う方法はわかりません。

注：これが答えに影響するかどうかはわかりませんが、別のブランチで変更を加えず、マスターの上でコミットしました

gitversion-controlgithubpull-request
320
Orion Edwards

プルリクエストで使用されるブランチに新しいコミットを追加し、ブランチをGitHubにプッシュするだけです。プルリクエストは、追加のコミットで自動的に更新されます。

＃2と＃3は不要です。ブランチがマージされた場所（追加のコミットではなく）のみを表示する場合は、git log --first-parentを使用して、ログ内のマージコミットのみを表示できます。

208
Amber

プルリクエストを更新するには

プルリクエスト（ポイント＃1）を更新するために必要なことは、プルリクエストと同じブランチをチェックアウトし、再度プッシュすることだけです。

cd /my/fork
git checkout master
...
git commit -va -m "Correcting for PR comments"
git Push

オプション-コミット履歴のクリーニング

リポジトリの履歴がきれいになるようにコミットをまとめてつぶすように求められる場合があります。または、プルリクエストの「メッセージ」から気を散らす中間コミットを削除したい場合があります（ポイント＃2）。たとえば、コミット履歴が次のようになっている場合：

$ git remote add parent [email protected]:other-user/project.git
$ git fetch parent
$ git log --oneline parent/master..master
e4e32b8 add test case as per PR comments
eccaa56 code standard fixes as per PR comments
fb30112 correct typos and fatal error
58ae094 fixing problem

まとめてつぶして、単一のコミットとして表示することをお勧めします。

$ git rebase -i parent/master

これにより、プルリクエストの履歴を書き換える方法を選択するよう求められます。エディターには次のように表示されます。

pick 58ae094 fixing actual problem
pick fb30112 correct typos
pick eccaa56 code standard fixes
pick e4e32b8 add test case as per PR comments

以前のコミットの一部にしたいコミットについては、ピックをスカッシュに変更します。

pick 58ae094 fixing actual problem
squash fb30112 correct typos
squash eccaa56 code standard fixes
squash e4e32b8 add test case as per PR comments

そして、エディターを閉じます。その後、Gitは履歴を書き換え、1つの結合されたコミットのコミットメッセージを提供するように求めます。それに応じて修正すると、コミット履歴が簡潔になります。

$ git log --oneline parent/master..master
9de3202 fixing actual problem

それをフォークにプッシュします。

$ git Push -f
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (11/11), 978 bytes, done.
Total 11 (delta 9), reused 7 (delta 6)
To [email protected]:me/my-fork.git
   f1238d0..9de3202  HEAD -> master

プルリクエストには単一のコミットが含まれ、以前にいくつかのコミットに分割されたすべての変更が組み込まれます。

パブリックリポジトリの履歴を変更するのは悪いことです

履歴を書き直し、ブランチでgit Push -fを使用することは、潜在的に他の誰かが既にクローンを作成していることは悪いことです。リポジトリの履歴とチェックアウトの履歴が分岐する原因になります。

ただし、フォークの履歴を修正して、あなたが提案をリポジトリに統合するという変更を修正するのは良いことです。そのため、プルリクエストから「ノイズ」を排除する予約はありません。

枝に関するメモ

上記では、プルリクエストがあなたのフォークのmasterブランチから来たものとして示していますが、それは必ずしも悪いことではありませんが、これがあなたの標準的なテクニックであれば、1つのPRリポジトリ。ただし、提案する個々の変更ごとにブランチを作成することをお勧めします。

$ git branch feature/new-widgets
$ git checkout feature/new-widgets
...
Hack hack hack
...
$ git Push
# Now create PR from feature/new-widgets
211
AD7six

ベストプラクティスに関する私の意見：プルリクエストをパッケージ化する準備ができたら、その目的のために、最初に独自のトピックブランチを取得する必要があります。そのブランチをgithubリポジトリにプッシュすることから始めます。

git Push Origin name-of-pull-request-branch

プルリクエストをそのブランチの基にします。そのようにすると、そのブランチにプッシュしたコミットはすべて、プルリクエストに自動的に追加されます。そのブランチを他の何にも使用しません。

GithubのユーザーIDを使用してこのようなブランチの名前空間を作成することを好む人もいます。そうすれば、彼らはローカルで自由にチェックアウトして、試してみることができます。

  • ブランチ名の衝突の恐れが少ない
  • 覚えやすい

私は通常、プルリクエストブランチに次のような名前を付けます

claybridges-do-the-things
5
Clay Bridges