Library)を使わないのですかなぜGodotは例外処理を使わないのですか?GodotがRTTI(実行時型情報)を強制しないのはなぜですか?GodotがユーザーにDoD(データ指向設計)の実装を強制しないのはなぜですか?Godotの開発をサポートしたり、貢献したりするにはどうすればいいですか?誰がGodotで働いていますか。sourceプルリクエスト・ワークフロー¶Godotが使用するいわゆる「PRワークフロー」は、Gitを使用する多くのプロジェクトに共通しており、ベテランのフリーソフトウェア貢献者には馴染み深いはずです。アイデアは、少数(もしある場合)だけがmasterブランチに直接コミットすることです。リポジトリの1つのブランチにプルをリクエストします。他の貢献者によって確認され、承認、拒否、またはほとんどの場合、変更の実行を要求できます。コマンドを示す例をまとめます。GodotのGitリポジトリの組織を簡単に見てみましょう。Gitソースリポジトリ¶GitHubのリポジトリは、組み込みの問題追跡システムとPRシステムを備えたGitコードリポジトリです。Godotに効率的に貢献するために、Gitコマンドラインの基本を学ぶことは強く推奨されます。Gitにはグラフィカルインターフェイスがいくつかありますが、通常はGitとPRワークフローに関する悪い習慣をユーザーに奨励するため、使用しないことをお勧めします。(ただし、小さな修正やドキュメントの変更には許容されます)、ファイルごとに1つのコミットが適用され、変更ごとに1つのコミットが適用され、読み取り不能なGit履歴を持つPRがすぐに発生します(特にピアレビューの後)。参考Gitの「ブック」の最初のセクションは、ツールの哲学と、毎日のワークフローで習得する必要があるさまざまなコマンドの優れた紹介です。SCMWebサイトでオンラインで読むことができます。ブランチは、次のメジャーバージョンの開発が行われる場所です。開発ブランチとして、それは不安定であり、生産で使用するためのものではありません。ここでPRを優先して行う必要があります。バグ修正と機能強化をバックポートするために使用されます。リリースまで維持されていました)。ブランチにも関連しているかどうかを確認する必要があります。ブランチにマージされることを意図しています。godotリポジトリをフォークすることです。そのためには、GitHubアカウントが必要であり、ログインする必要があります。repoの自分のフォークにリダイレクトされるはずです:次に、forkのクローンを作成します。オンラインリポジトリのローカルコピーを作成します(Gitの言葉を使えば、元のリモート)。Gitをダウンロードしていない場合は、WindowsまたはmacOSを使用している場合はそのWebサイトからダウンロードし、Linuxを使用している場合はパッケージマネージャからインストールします。Bashを開いてコマンドを入力します。macOSとLinuxユーザーはそれぞれの端末を使用できます。https://github.com/USERNAME/godot注釈この例では、「$」文字は、一般的なUNIXシェルのコマンドラインプロンプトを示します。これはコマンドの一部ではないため、入力しないでください。ディレクトリが表示されます。いう名前の参照が作成されます。ブランチから新しいコミットをプルする場合に便利です。サブフォルダに隠されています)。注釈ブランチ、プル、コーディング、ステージング、コミット、プッシュ、リベース...テクノロジー。PunkのTechnologicに対するこの悪い見方は、Git初心者がワークフローについて持っている一般的な概念を示しています。コピーアンドペーストで学ぶ多くの奇妙なコマンドは、期待どおりに機能することを望んでいます。あなたが好奇心が強く、迷ったときに検索エンジンに質問することを躊躇しない限り、それは実際に学ぶための悪い方法ではないので、Gitで作業するときに知る基本的なコマンドを提供します。ファイルにコーディングされている機能をGodotのプロジェクトマネージャーに実装することを想定しています。)に置かれているはずです。masterブランチの更新¶これは最初は必要ありません(アップストリームリポジトリをフォークした直後)。ブランチの後ろにいくつかのコミットがあることに気づくでしょう。その間に他の貢献者からのプルリクエストがマージされているでしょう。ブランチとの間に競合が生じないようにするには、アップストリームブランチをプルによってブランチを更新する必要があります。コミット」を作成し、すぐに仲間の貢献者からそれらがPRで望まれないと聞いたとします。ブランチの上で再生できるようにする必要があります。Git履歴は効果的に変更されますが、それはより大きな利益のためです。ファイルに変更を加えます。デフォルトでは、これらの変更はステージングされていません。フォルダ内のすべてのメタデータ)の間のレイヤーです。コマンドでコミットする必要があります。現在の作業を確認するために、ステージングする前、ステージング中、コミット後に確認するために知っておくべきさまざまなコマンドがあります。現在のステージングされていない変更、つまり作業ディレクトリとステージング領域の違いが表示されます。指定されたファイルに対するステージングされていない変更を取り消します。リストされたファイルの変更をステージングします。現在のステージングされた変更、すなわちステージング領域と最後のコミットの違いが表示されます。リストされたファイルをステージ解除します。現在ステージングされ、ステージングされていない変更が何であるかを示します。ステージングされたファイルをコミットします。設定で使用するエディタを定義できます)、コミットログを書き込むことができます。使用して、ログを直接書き込むことができます。現在のブランチの最後のコミットが表示されます。ローカルコミットを行った場合は、上部に表示する必要があります。最後のコミットの変更を表示します。コミットハッシュを指定して、そのコミットの変更を確認することもできます。ブランチにはない2つの新しいコミットが必要になります。それらはまだローカルのみであり、リモートフォークはそれらを認識せず、アップストリームリポジトリも認識しません。Gitでは、コミットは常にローカルリポジトリで行われます(コミットがリモートリポジトリを直接変更するSubversionとは異なります)。新しいコミットをリモートブランチにプッシュして、それらを世界と共有する必要があります。better-project-managerGitはユーザー名とパスワードを尋ね、変更内容はリモートに送信されます。GitHubでフォークのページを確認すると、コミットが追加された新しいブランチが表示されます。ブランチと同期していない場合、潜在的にいくつかのコミットが遅れます)。その行には、「プルリクエスト」リンクがあります。クリックすると、godotengine/godotアップストリームリポジトリでプルリクエストを発行できるフォームが開きます。2つのコミットを表示し、「マージ可能」を示す必要があります。ない場合(例えば、より多くのコミットがある場合、またはマージの競合があると言う)、PRを作成しないでください。IRCに移動し、サポートを依頼しましょうPRに明示的なタイトルを使用し、必要な詳細をコメント領域に配置します。スクリーンショット、GIF、またはzipプロジェクトをドラッグアンドドロップして、作業内容を示すことができます。他の貢献者によってレビューされていますが、貢献者が要求したか、テスト中に自分で問題を発見したため、まだマージされていないPRを変更する必要があります。良いニュースは、プルリクエストを行ったブランチに基づいて操作するだけでプルリクエストを変更できることです。上記の状況では、Gitの歴史に関して特に熱心な仲間は、最後の2つのコミット(プロジェクトマネージャーに関連する2つ)をsquashまたはmeldにリベースするように頼むかもしれません。2番目のコミットは基本的に最初のコミットの問題を修正するためです。PRがマージされると、PR作成者がミスをしたことは、変更ログの読者には関係ありません。代わりに、ある作業状態から別の作業状態に移行するコミットのみを保持する必要があります。これら2つのコミットをまとめてつぶすには、履歴を書き換える必要があります。私たちにはその力があります。あなたはそれが悪い習慣であると読むかもしれません、そしてそれはアップストリームレポのブランチに関しては本当です。このコマンドは引数としてコミットハッシュを受け取り、そのコミットハッシュとブランチの最後の1つ、いわゆるHEADとの間のすべてのコミットを変更できるようにします。titleエディタには、これらのコミットを実行する方法についての指示も表示されます。「pick」とはそのコミットを使用すること(何もしない)を意味し、「squash」と「fixup」を使用してコミットを親コミットにマージできることを示します。「squash」と「fixup」の違いは、「fixup」はコミットログを圧縮されたコミットから破棄する点です。titleエディタを保存して終了すると、リベースが発生します。よって、前の2つのコミットから変更されたコミットが1つだけであることが確認されます。使用すると、このリベースを回避できます。)に直接書き込みます。新しいコミットでリフィックスし、それを「fixup」としてマークすることと同じです。!履歴を書き直した結果、ローカルブランチとリモートブランチが分岐しました。実際に、上記の例のコミット:1b4aad7は変更され、新しいコミットハッシュを取得します。counterpart.これは正常な動作です。Gitでは、リモートコンテンツをオーバーライドする変更をプッシュできません。これにより、それに応じてPRも更新されます。Gitブランチの削除¶プルリクエストがマージされた後、最後にやることが1つあります。PRのGitブランチを削除します。ブランチを削除しなくても問題はありませんが、削除することをお勧めします。これを2回行う必要があります。1回はローカルブランチ用、もう1回はGitHub上のリモートブランチ用です。