Gitワークフロー（Git Workflow）

概要

貢献者のためのプロセスの概要は次のとおりです：

• Gutenberg リポジトリをフォークします。
• フォークしたリポジトリをクローンします。
• 新しいブランチを作成します。
• コードを変更します。
• テストが通過することを確認します。
• 新しく作成したブランチ内でコード変更をコミットします。
• フォークしたリポジトリにブランチをプッシュします。
• Gutenberg リポジトリにプルリクエストを送信します。

Gutenberg プロジェクトが GitHub をどのように使用しているかについての追加情報は、リポジトリ管理ドキュメントを参照してください。

Git ワークフローの手順

コードとドキュメントのワークフローは同じです。両方とも GitHub で管理されています。ドキュメントへの貢献のビデオウォークスルーと、Gutenberg への貢献のためのチュートリアルを視聴できます。

以下は Git ワークフローの視覚的概要です：

ステップ 1: GitHub の Gutenberg リポジトリに移動し、フォークをクリックします。これにより、メインの Gutenberg リポジトリのコピーがあなたのアカウントに作成されます。

ステップ 2: フォークしたリポジトリをローカルにクローンします。場所は次のとおりです： https://github.com/YOUR-USER-NAME/gutenberg。クローンはすべてのファイルをコンピュータにコピーします。ターミナルを開いて次のコマンドを実行します：

git clone https://github.com/YOUR-USER-NAME/gutenberg

これにより、プロジェクトのすべてのファイルを含む gutenberg という名前のディレクトリが作成されます。Gutenberg プロジェクトの全履歴をダウンロードしているため、数分かかる場合があります。

ステップ 3: 変更のためのブランチを作成します（ブランチ名の付け方については以下を参照）。この例では、ブランチ名は完全な文字列です： update/my-branch

git switch -c update/my-branch

ステップ 4: コード変更を行います。変更を徹底的にビルド、確認、テストします。ガイダンスについては、コーディングガイドラインとテスト概要を参照してください。

ステップ 5: 良いコミットメッセージで変更をコミットします。これにより、リポジトリのローカルコピーに変更がコミットされます。

git commit -m "Your Good Commit Message" path/to/FILE

ステップ 6: 変更を GitHub にプッシュします。変更は GitHub のリポジトリのフォークにプッシュされます。

git push -u origin update/my-branch

ステップ 7: GitHub のフォークしたリポジトリに移動します。変更が自動的に検出され、プルリクエストを作成するためのリンクが表示されます。

ステップ 8: プルリクエストを作成します。これにより、フォークしたリポジトリからの変更を統合するためのリクエストが WordPress Gutenberg リポジトリに作成されます。

ステップ 9: プルリクエストの新しいアクティビティを追跡します。追加の変更や更新が要求された場合は、ローカルで変更を行い、ステップ 4-6 に従ってプッシュします。

更新のために新しいプルリクエストを作成しないでください。リポジトリに変更をプッシュすることで、同じ PR が更新されます。この意味で、PR は WordPress Gutenberg リポジトリのあなたのコピーへのポインタです。したがって、コピーを更新すると、PR も更新されます。

以上です！承認されてマージされると、あなたの変更はメインリポジトリに組み込まれます。

ブランチ名の付け方

ブランチには接頭辞と短い説明を使用して名前を付けるべきです。例： [type]/[change]。

推奨される接頭辞：

• add/ = 新しい機能を追加
• try/ = 実験的な機能、「仮に追加」
• update/ = 既存の機能を更新
• remove/ = 既存の機能を削除
• fix/ = 既存の問題を修正

例えば、add/gallery-block は新しいギャラリーブロックを追加する作業をしていることを意味します。

ブランチを最新の状態に保つ

多くの異なる人々が同時にプロジェクトに取り組んでいると、プルリクエストはすぐに古くなります。「古くなった」プルリクエストは、メインの開発ラインともはや一致しないものであり、プロジェクトにマージされる前に更新する必要があります。

これを行う方法は2つあります：マージとリベース。Gutenberg では、リベースを推奨しています。リベースとは、変更をメインの開発ラインの上にあるかのように書き直すことを意味します。これにより、コミット履歴が常にクリーンで直線的になります。プルリクエストに取り組んでいる間は、必要に応じて何度でもリベースを実行できます。作業を早めに共有してください。プルリクエストを開き、進行に応じて履歴をリベースし続けてください。

メインの開発ラインは trunk ブランチとして知られています。もし、trunk にマージできないプルリクエストブランチがある場合（これは長期間のプルリクエストで発生する可能性があります）、リベースの過程でローカルコピーで手動で競合を解決する必要があります。詳細は、プルリクエストをリベースする方法のセクション リベースを実行するを参照してください。

ローカルで競合を解決したら、git push --force-with-lease でプルリクエストを更新できます。--force-with-lease パラメータを使用することは、他の誰かの作業を誤って上書きしないことを保証するために重要です。

要約すると、リポジトリの新しい変更を取得し、trunk の上にブランチをリベースし、結果をリポジトリにプッシュする必要があります。これに対応するコマンドは次のとおりです：

git fetch
git rebase trunk
git push --force-with-lease origin your-branch-name

フォークを最新の状態に保つ

プルリクエストに取り組むには、Gutenberg リポジトリをフォークし、別の作業コピーを作成します。新しいプルリクエストがメインリポジトリにマージされると、簡単に同期が取れなくなる可能性があります。ここでの作業リポジトリは fork で、メインの Gutenberg リポジトリは upstream です。新しいプルリクエストに取り組む際は、機能や修正に取り組む前に常にフォークを更新する必要があります。

フォークを更新するには、upstream リモートを追加する必要があります。

git remote add upstream https://github.com/WordPress/gutenberg.git
git remote -v
origin  git@github.com:your-account/gutenberg.git (fetch)
origin  git@github.com:your-account/gutenberg.git (push)
upstream    https://github.com/WordPress/gutenberg.git (fetch)
upstream    https://github.com/WordPress/gutenberg.git (push)

フォークを同期させるには、まずアップストリームの変更を取得し、それをローカルコピーにマージする必要があります：

git fetch upstream
git checkout trunk
git merge upstream/trunk

ローカルコピーが更新されたら、変更をプッシュして GitHub 上のフォークを更新します：

git push

上記のコマンドは、アップストリーム から trunk ブランチを更新します。他のブランチを更新するには、trunk をそれぞれのブランチ名に置き換えます。

その他

Git 考古学

特定の変更を導入したコミットを探すとき、スタイリングやフォーマットの変更のみを含むリビジョンを無視することが役立つ場合があります。

幸いなことに、git の新しいバージョンでは、履歴のコミットをスキップする機能が追加されました：

git blame --ignore-rev f63053cace3c02e284f00918e1854284c85b9132 -L 66,73 packages/api-fetch/src/middlewares/media-upload.js

すべてのスタイリングおよびフォーマットのリビジョンは、Gutenberg リポジトリ内の .git-blame-ignore-revs ファイルを使用して追跡されます。このファイルを使用して、すべてを一度に無視することができます：

git blame --ignore-revs-file .git-blame-ignore-revs -L 66,73 packages/api-fetch/src/middlewares/media-upload.js