前書き

オープンソースプロジェクトへの貢献は、あなたのようなエンドユーザーにとってソフトウェアをより良くするために努力するときのやりがいのある経験です。 プルリクエストを送信すると、プロジェクトに貢献するプロセスでは、承認前にコードのリベースとリワークが必要になる場合があります。その後、ブランチの一般的なクリーンアップが行われます。

このチュートリアルでは、https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-githubを送信した後に実行する必要がある次の手順のいくつかをご案内します[プルリクエスト]をオープンソースソフトウェアプロジェクトに。

前提条件

このチュートリアルでは、プルリクエストを行った後に実行する手順を説明します。したがって、すでにGitがインストールされており、プルリクエストを作成したか、作成を検討している必要があります。

オープンソースプロジェクトへの貢献の詳細については、https://www.digitalocean.com/community/tutorials/contributing-to-open-source-getting-started-with-git [この紹介]をご覧ください。 プルリクエストの作成については、「https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github[GitHubでプルリクエストを作成する方法]」を参照してください。 」

オープンソースに貢献している間、ブランチまたはプルリクエストとアップストリームコードの間に矛盾があることに気付くかもしれません。 シェルで次のようなエラーが表示される場合があります。

OutputCONFLICT (content): Merge conflict in
Automatic merge failed; fix conflicts and then commit the result.

または、GitHubのWebサイトからのプルリクエストで次のようになります。

image:https://assets.digitalocean.com/articles/eng_python/PullRequest/conflicts.png [GitHub pull request conflicts]

これは、メンテナーがしばらくの間プル要求に応答しない場合、または多くの人が一度にプロジェクトに貢献している場合に発生する可能性があります。 これが発生し、プルリクエストをマージしたい場合は、競合を解決してコードをリベースする必要があります。

  • rebase *を使用すると、ブランチのベースとなるコミットを変更してブランチを移動できます。 このようにして、masterブランチの最近のコミットに基づいてコードをリベースできます。 リベースは慎重に行う必要があり、プロセス全体を通して適切なコミットと適切なブランチで作業していることを確認する必要があります。 また、 `+ git reflog +`コマンドhttps://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request#recovering-lost-commits [以下]エラーが発生した場合。

https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github [プルリクエストチュートリアル]で行ったように、コードディレクトリに移動してフェッチしますコードの最新のアップストリームバージョン。

cd
git fetch

プロジェクトのアップストリームバージョンを取得したら、コミットメッセージを押しつぶすか言い直してコメントをクリーンアップし、プロジェクトメンテナがより理解しやすいようにします。 多くの小さなコミットを行わなかった場合、これは必要ないかもしれません。

このプロセスを開始するには、インタラクティブなリベースを実行します。 * interactive rebase *を使用すると、以前のコミットメッセージを編集したり、複数のコミットを1つに結合したり、不要になったコミットを削除または元に戻したりできます。 これを行うには、番号またはブランチのベースを参照する文字列で行ったコミットを参照できる必要があります。

行ったコミットの数を調べるには、次のコマンドを使用して、プロジェクトに対して行われたコミットの総数を調べることができます。

git log

これにより、次のような出力が得られます。

Outputcommit
Author:  <>
Date:



commit
Author:  <>
Date:

ログには、指定されたプロジェクトのリポジトリに対して行われたすべてのコミットが表示されるため、コミットは他のコミットによって行われます。 複数の作成者による広範なコミットの履歴があるプロジェクトの場合は、コマンドで自分を作成者として指定する必要があります。

git log --author=

このパラメーターを指定すると、行ったコミットをカウントアップできるはずです。 複数のブランチで作業している場合は、コマンドの末尾に「+-branches [= <>] +」を追加してブランチごとに制限できます。

これで、リベースしたいブランチで行ったコミットの数がわかっている場合、次のように `+ git rebase +`コマンドを実行するだけです:

git rebase -i HEAD~

ここで、「-i +」はインタラクティブなリベースを指し、「 HEAD 」はmasterブランチからの最新のコミットを指します。 `+`は、最初にブランチをフェッチしてからブランチに行ったコミットの数になります。

ただし、ブランチで行ったコミットの数がわからない場合は、ブランチのベースであるコミットを見つける必要があります。これは、次のコマンドを実行して実行できます。

git merge-base  master

このコマンドは、コミットハッシュと呼ばれる次のような長い文字列を返します。

Output

このコミットハッシュを使用して、 `+ git rebase +`コマンドに渡します。

git rebase -i

上記のコマンドのいずれについても、ブランチ内のすべてのコミットのリストを含むファイルを使用してコマンドラインテキストエディターが開き、コミットを圧縮するか、または書き直すかを選択できるようになりました。

スカッシュコミット

コミットメッセージを押しつぶすときは、いくつかの小さなコミットを1つの大きなコミットに押しつぶすか結合します。

各コミットの前に「ピック」という単語が表示されるため、2つのコミットがある場合、ファイルは次のようになります。

GNU nano 2.0.6ファイル:…username / repository / .git / rebase-merge / git-rebase-todo

pick a1f29a6
pick 79c0e80

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

ここで、最初の行を除くファイルの各行について、「pick」という単語を「squash」という単語に置き換えて、コミットを結合する必要があります。

GNU nano 2.0.6ファイル:…username / repository / .git / rebase-merge / git-rebase-todo

pick a1f29a6
79c0e80

この時点で、ファイルを保存して閉じることができます。これにより、すべてのコミットのすべてのコミットメッセージを結合する新しいファイルが開きます。 コミットメッセージを適切に書き換えて、ファイルを保存して閉じることができます。

ファイルを閉じると、フィードバックを受け取ります。

OutputSuccessfully rebased and updated refs/heads/.

これで、すべてのコミットをまとめて1つにまとめました。

コミットの書き換え

タイプミスに気づいたとき、またはコミットのそれぞれに並列言語を使用していないことに気付いたときに、コミットメッセージを言い換えることは素晴らしいことです。

`+ git rebase -i +`コマンドを使用して上記のようにインタラクティブなリベースを実行すると、次のようなファイルが開きます。

GNU nano 2.0.6ファイル:…username / repository / .git / rebase-merge / git-rebase-todo

pick a1f29a6
pick 79c0e80

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

ここで、言い換える各コミットについて、「pick」という単語を「reword」に置き換えます。

GNU nano 2.0.6ファイル:…username / repository / .git / rebase-merge / git-rebase-todo

pick a1f29a6
79c0e80

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

ファイルを保存して閉じると、ターミナルエディタに新しいテキストファイルが表示され、コミットメッセージの修正された文言が表示されます。 ファイルを再度編集する場合は、ファイルを保存して閉じる前に編集できます。 これにより、コミットメッセージが有用で統一されたものになります。

リベースを完了する

作成するコミットの数と関連するコミットメッセージに満足したら、プロジェクトのアップストリームコードの最新バージョンの上にブランチのリベースを完了する必要があります。 これを行うには、リポジトリのディレクトリから次のコマンドを実行する必要があります。

git rebase

この時点で、Gitはコミットを最新バージョンのマスターにリプレイし始めます。 これが発生している間に競合が発生した場合、Gitは一時停止して続行する前に競合を解決するように促します。

競合を修正したら、次を実行します。

git rebase --continue

このコマンドは、コミットの再生を継続できることをGitに示します。

以前に `+ squash +`コマンドを使用してコミットを結合した場合、衝突を解決する必要があるのは一度だけです。

強制プッシュを使用したプル要求の更新

リベースを実行すると、ブランチの履歴が変更され、ダイレクトパスが変更されたため、 `+ git push +`コマンドを使用できなくなります。

代わりに、 `-force +`または ` -f +`フラグを使用して変更を強制的にプッシュし、プッシュする内容を完全に認識していることをGitに通知する必要があります。

最初に、 `+ push.default `がGit 2.0+のデフォルトである ` simple +`であることを確認して設定します。

git config --global push.default simple

この時点で、作業中のブランチをチェックアウトして、正しいブランチにいることを確認する必要があります。

git checkout
OutputAlready on ''
. . .

これで、強制プッシュを実行できます。

git push -f

これで、更新のフィードバックと、これが「強制更新」であるというメッセージが表示されます。 これで、プルリクエストが更新されました。

失われたコミットの回復

ある時点で、より大きなプロジェクトに統合したいコミットを破棄した場合、Gitを使用して、誤って破棄した可能性のあるコミットを復元できるはずです。

`+ git reflog +`コマンドを使用して、欠落しているコミットを見つけ、そのコミットから新しいブランチを作成します。

  • Reflog reference logs *の略で、ローカルリポジトリ内でブランチや他のリファレンスのヒントが最後に更新された時間を記録します。

作業中のコードリポジトリのローカルディレクトリから、次のコマンドを実行します。

git reflog

このコマンドを実行すると、次のような出力が表示されます。

Output46f1962 [email protected]{0}: checkout: moving from branch-1 to new-branch
9370d03 [email protected]{1}: commit: code cleanups
a1f29a6 [email protected]{2}: commit: brand new feature
38f2fc2 [email protected]{3}: commit: remove testing methods
. . .

コミットメッセージは、どのコミットが残したものであるかを知らせ、関連する文字列はターミナルウィンドウの左側の `+ HEAD @ {} +`情報の前にあります。

これで、その情報を取得し、関連するコミットから新しいブランチを作成できます。

git checkout -b

上記の例では、上に表示された3番目のコミットから新しいブランチを作成しました。これは、文字列「+ a1f29a6 +」で表される「真新しい機能」を展開したものです。

ここから何をする必要があるかに応じて、https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-githubでブランチを設定する手順に従うことができます#create-a-new-branch [プルリクエストに関するこのチュートリアル]、またはhttps://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request#に戻る新しいブランチのリベースを行うために、コードとクリーンアップのコメントをリベースする[現在のチュートリアルのトップ]。

コードレビューで何を期待するか

プルリクエストを送信すると、より大きなプロジェクトと対話します。 プルリクエストを送信することは、あなた自身がより大きなプロジェクトについて話し、関与しているのと同じように、他の人にあなたの仕事について話すように誘います。 会話を成功させるには、コミットメッセージを使用してプルリクエストを行っている理由を伝えることが重要です。そのため、できるだけ正確かつ明確にすることが最善です。

プロジェクトによっては、プルリクエストのレビューに時間がかかり、詳細になる場合があります。 プロセスを学習体験と考え、コードを改善し、プルリクエストをソフトウェアプロジェクトのニーズに合わせてより適切に行うための良い方法と考えるのが最善です。 このレビューにより、メンテナーのアドバイスと指示により、自分で変更を加えることができます。

プルリクエストは、レビュアーからのメモのログと、一緒に行った更新やディスカッションを保持します。 プルリクエストが受け入れられる前に、このプロセス全体でいくつかの追加のコミットが必要になる場合があります。 これは完全に正常な動作であり、チームの一員として改訂作業を行う良い機会となります。

プルリクエストはGitを通じて維持され、同じブランチにコミットを追加し、それらをフォークにプッシュし続ける限り、プロセス全体で自動更新されます。

同僚によるレビューのためにコードをより大きな世界に公開していますが、レビューが個人的なものになっているように感じることは決してないので、関連する `+ CONTRIBUTION.md +`ファイルまたは行動規範を必ず読んでください。 コミットがプロジェクトで指定されたガイドラインに沿っていることを確認することが重要ですが、不快に感じ始めた場合、作業中のプロジェクトは貢献に値しないかもしれません。 オープンソースコミュニティには多くの歓迎スペースがあり、批判的な目でコードを見ることが期待できますが、受け取るフィードバックはすべて専門的で礼儀正しいものでなければなりません。

プルリクエストの受け入れとブランチの削除

おめでとうございます。 プルリクエストが受け入れられた場合、オープンソースソフトウェアプロジェクトへの貢献が成功しました!

この時点で、ローカルリポジトリを介して、行った変更をフォークに戻す必要があります。 これは、https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github#sync-the-forkへのプロセスを実行したときにすでに行ったことです。フォークを同期する]。 これは、ターミナルウィンドウで次のコマンドを使用して実行できます。

git checkout master
git pull --rebase upstream master
git push -f origin master

ここで、ローカルとリモートの両方のブランチが不要になったため、両方の場所で作成したブランチを削除して、クリーンアップする必要があります。 まず、ローカルブランチを削除しましょう。

git branch -d

+ git branch`コマンドに追加された + -d + `フラグは、コマンドに渡したブランチを削除します。 上記の例では、と呼ばれます。

次に、リモートブランチを削除します。

git push origin --delete

ブランチを削除すると、リポジトリがクリーンアップされ、変更がメインリポジトリに反映されます。 プルリクエストで行った変更がメインリポジトリの一部になったからといって、パブリックリリースをダウンロードしている平均的なエ​​ンドユーザーが利用できない場合があることに留意してください。 一般的に、ソフトウェアメンテナーはいくつかの新しい機能と修正プログラムを1つのパブリックリリースにまとめます。

結論

このチュートリアルでは、https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github [プルリクエスト]オープンソースソフトウェアリポジトリ。

オープンソースプロジェクトへの貢献-そしてアクティブなオープンソース開発者になることは、しばしばやりがいのある経験です。 頻繁に使用するソフトウェアに定期的に貢献することは、ユーザーのコミュニティにとって価値があり、有用であることを保証するのに役立ちます。