Git ワークフロー

このドキュメントは Gutenberg で git を使うためのガイドです。git は強力なソースコード管理ツールです。git を深く学ぶには、Pro Git book (日本語版) を参照してください。CC BY-NC-SA 3.0 ライセンスの下、オンラインで無料で入手できます。

もし git の使用に慣れていなければ、しばらく遊んでみると良いでしょう。git tutorial や git user manual などを参考にしてください。

Gutenbergプロジェクトでは、コントリビューションに標準的なプルリクエストプロセスを採用しています。プルリクエストに関する詳細については、GitHubのドキュメント を参照してください。

コントリビューションプロセスの概要は次のとおりです。

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

Gutenberg プロジェクトにおける GitHub の使用に関する追加情報は、ドキュメント「リポジトリ管理」を参照してください。

コードもドキュメントもどちらも GitHub で管理されているため、ワークフローも共通です。ドキュメントのコントリビューションに関するビデオチュートリアルや、付属のスライド「Gutenbergへのコントリビューション」を参照してください。

Git ワークフローのビジュアルな概要を示します。

手順1: GitHub 上の Gutenberg リポジトリにアクセスし、「Fork」をクリックします。あなたのアカウントに 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に従って、ローカルで変更を行い、プッシュしてください。

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

これで完了です。承認されてマージされると、変更がメインのリポジトリに組み込まれます。 🎉

ブランチの名前は、接頭辞と短い説明を使用して [タイプ]/[変更] のように命名してください。

推奨される接頭辞

• add/ = 新機能の追加
• try/ = 実験的な機能、一時的な追加
• update/ = 既存機能の更新
• remove/ = 既存機能の削除
• fix/ = 既存の問題の修正

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

さまざまな人が同時にプロジェクトで作業すると、プルリクエストがすぐに古くなります。「古い」プルリクエストとは、開発のメインラインの最新版から遅れたものに対する変更を指し、これはプロジェクトにマージする前に更新する必要があります。

これには、マージとリベースの2つの方法があります。Gutenberg では、リベースを推奨しています。リベースとは、あたかも開発のメインラインの最新版に対して変更したかのように、あなたの変更を書き換える方法です。リベースではコミットの履歴が常に美しく、直線的です。リベースは、プルリクエストでの作業中に何度でも実行できます。作業内容はできる限り早い段階で共有してください。それにはプルリクエストを作成し、履歴をリベースしながら作業を進めていきます。

開発のメインラインは trunk ブランチとして知られています。競合のために trunk にマージできないプルリクエストブランチがある場合 (これは、長期間作業中のプルリクエストで起こります)、リベースの過程でローカルコピーの競合を手動で解決する必要があります。詳細については How to Rebase a Pull Request の Perform a rebase セクションを参照してください。

ローカルでの競合の解決跡は、git push --force-with-lease で、プルリクエストを更新できます。force-with-lease`パラメータは、他の人の作業を誤って上書きしないようにするために重要です。

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

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

プルリクエストの作業は、まず Gutenberg リポジトリのフォークから始まります。これが作業用コピーですが、メインリポジトリで新しいプルリクエストがマージされると、簡単に同期が失われます。ここで、作業用リポジトリをフォーク、Gutenberg のメインリポジトリを upstream とします。新しいプルリクエストで、機能や修正を行うための git checkout -b my-new-branch を実行する前に、必ずフォークを更新してください。

自分のフォークを最新に保つには、リモート 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)

フォークを同期するには、まず upstream の変更を取得し、ローカルコピーにマージする必要があります。

git fetch upstream
git checkout trunk
git merge upstream/trunk

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

git push

上のコマンドは、upstream の trunk ブランチを更新します。他のブランチを更新するには、trunk をそれぞれのブランチ名で置き換えてください。

特定の変更を行ったコミットを探す場合、スタイルやフォーマットの変更のみを含むリビジョンは無視した方がよいでしょう。

幸いなことに、新しいバージョンの 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

原文

最終更新日: 2022年1月29日