§Gitの操作

このガイドは、新しいコントリビューターがPlayを使い始めるのに役立つように設計されています。ここに記載されていることの一部は、私たちが良いと考えており、Playへの貢献を容易にするための慣例ですが、決して義務的なものではありません。あなたにとって最適な方法を使用してください。

§Gitのリモート

公式のPlayリポジトリのリモートをoriginと呼び、あなたのフォークのリモートをあなたのユーザー名と呼ぶことを推奨します。この慣例は、複数のフォーク間でコードを共有する場合にうまく機能し、このガイドの残りのgitコマンドすべてで使用する慣例です。また、GitHubコマンドラインツールとそのままの状態で最適に機能する慣例でもあります。

§ブランチ

通常、すべての作業はブランチで行う必要があります。mainで直接作業を行うと、一度に1つのプルリクエストしか送信できません。なぜなら、mainから2つ目のプルリクエストを送信しようとすると、2つ目のプルリクエストには最初と2つ目の両方のコミットが含まれるからです。ブランチで作業することで、プルリクエストを互いに分離できます。

ブランチの名前は自由に決めてください。ブランチ名にissue番号を含める人もいれば、階層構造を使用する人もいます。

§コミットのマージ（スカッシュ）

すべてのプルリクエストが単一のコミットであることを推奨します。これにはいくつかの理由があります。

安定ブランチに単一のコミットをバックポートする方が、コミットのグループをバックポートするよりもはるかに簡単で、エラーが発生しにくいです。変更が1つのコミットだけにある場合、エラーの可能性はありません。変更全体がcherry-pickされるか、されないかのどちらかです。
私たちは、mainブランチを常にリリース可能にすることを目指しています。今だけでなく、歴史上のすべての時点でもです。何かを元に戻す必要がある場合、その前のコミットが安定していると確信したいのです。
変更が1つのコミットに自己完結している場合、履歴で何が起こったかを完全に把握するのがはるかに簡単です。

もちろん、コミットをスカッシュすることが適切でない状況もあります。これはケースバイケースで決定されますが、コミットのスカッシュを要求しない場合の例としては、次のようなものがあります。

プルリクエストに複数の人が行ったコミットが含まれている場合。この場合、可能であれば、同じ人による連続したコミットをスカッシュすることを推奨します。
プルリクエストが、コミュニティで共有されているフォークまたはブランチから来ている場合。履歴を書き換えると、そのフォークまたはブランチから変更をプルした人に問題が発生します。
プルリクエストが非常に大規模な作業であり、コミットログがその作業の進化を理解するのに役立つ場合。

ただし、一般的なケースでは、プルリクエストに複数のコミットが含まれている場合は、スカッシュする必要があります。これを行うには、またはすでにプルリクエストを送信しており、スカッシュするように求められた場合は、次の手順に従う必要があります。

リポジトリにコアmainブランチからのすべての変更があることを確認してください。
```
git fetch origin
```
インタラクティブなリベースを開始します。
```
git rebase -i origin/main
```
これにより、エディターに画面が開き、各コミットで何を行うかを指定できます。最初のコミットのコミットメッセージがすべてのコミットを記述するのに適している場合は、そのままにしておきます。そうでない場合は、最初のコミットのコマンドをpickからrewordに変更します。
残りの各コミットについて、コマンドをpickからfixupに変更します。これにより、gitはコミットを前のコミットにマージし、前のコミットのコミットメッセージを使用するように指示します。
ファイルを保存してエディターを終了します。Gitがリベースを開始します。最初のコミットをリワードするように指示した場合は、新しいエディターでそのコミットの文言を求められます。すべてがうまくいけば、完了ですが、変更を最新のmainブランチに適用するときに競合が発生する可能性があります。その場合は、競合を修正し、修正をステージングしてから、次を実行します。
```
git rebase --continue
```
競合する変更がさらにある場合は、これを繰り返す必要がある場合があります。
リベースが完了したので、変更をプッシュできます。このブランチを以前にプッシュしたことがある場合（プルリクエストを作成済みの場合も含む）は、強制プッシュを行う必要があります。これは、次のように行うことができます。
```
git push yourremote yourbranch --force
```

§レビュー/ビルドの失敗への対応

プルリクエストがCIビルドに合格しない場合、レビューを行い、プルリクエストを更新するように求められた場合、またはその他の理由でプルリクエストを更新する場合は、新しいコミットを作成するのではなく、既存のコミットを修正します。これは、コミット時に--amendフラグを指定することで行えます。

git commit --amend

修正を行った後は、--forceフラグを使用して強制プッシュを行う必要があります。

git push yourremote yourbranch --force

§やり直し

プルリクエストが完全に間違っていて、やり直したいと思う人もいます。これは問題ありません。ただし、元のプルリクエストを閉じて新しいプルリクエストを開く必要はありません。強制プッシュを使用して、完全に新しいブランチをプルリクエストにプッシュできます。

やり直すには、Playコアからの最新の変更を取得していることを確認し、その時点から新しいブランチを作成します。

git fetch origin
git checkout -b mynewbranch origin/main

変更を加え、プルリクエストを送信する準備ができたら、古いブランチがmyoldbranchと呼ばれていたと仮定して、リポジトリ内の古いブランチに新しいブランチをプッシュします。

git push yourremote mynewbranch:myoldbranch --force

これで、プルリクエストが新しいブランチで更新されます。

§履歴の変更について

一度公開したgitの履歴は変更すべきではないと言われているかもしれません。rebaseとcommit --amendはいずれも履歴を変更し、push --forceは変更された履歴を公開します。

公開後にgitの履歴を変更すべきではない場合が確かにあります。主な場合は、他の人がリポジトリをフォークした可能性がある場合、またはリポジトリから変更をプルした場合です。これらのケースで履歴を変更すると、リポジトリからの変更を安全に自分のリポジトリにマージできなくなります。このため、公式のPlay Frameworkリポジトリでは、履歴を決して変更しません。

ただし、個人のフォークに関しては、プルリクエストになることを意図したブランチの場合は別です。ワークフローの意図は、変更がmainブランチにマージされたときに「公開」されるということです。それまでは、履歴は作業中と見なすことができます。

ただし、ブランチが多くの人のコラボレーションであり、他の人が正当な理由でブランチからプルしていると信じている場合は、お知らせください。意味のない場所でコミットを強制的にスカッシュすることはありません。

次へ：Playについて

このドキュメントにエラーを見つけましたか？このページのソースコードはこちらにあります。ドキュメントガイドラインをお読みになったら、遠慮なくプルリクエストを送ってください。質問や共有できるアドバイスがありますか？コミュニティフォーラムでコミュニティとの会話を始めましょう。