この記事では、Gitで具体的によく使う操作や基本的な知識についてまとめていきます。
今回はローカルリポジトリで完結する操作(個人でのバージョン管理操作)を対象としています。
※この記事で使用しているSource treeや、Git/GitHubの用意については以下「準備編」の内容でまとめています。環境構築や導入方法についてはこちらをご参照下さい。
ローカルリポジトリの準備
まずはローカルリポジトリ(自分のPC上で使う貯蔵庫)を用意します。手順は以下のとおりです。
1. Godotプロジェクト作成:
Godotで、新規プロジェクト作成時に
[バージョン管理メタデータ]で[Git]を選択
し、作成します。
※この操作によって、新規プロジェクトファイル内にGodot用の[.gitignore]、[.gitattributes]ファイルが生成されます
2. リポジトリ作成:
Source treeを起動し、
新規タブ→[Create]で、
手順1.で作成したプロジェクトフォルダを指定
します。
※この操作で、指定したGodotプロジェクトフォルダ内に、新規リポジトリ(.gitフォルダ)の作成が行われます。(=コマンド[git init]相当)
完了確認:
画像のような画面になっていればOKです。
「作業ツリーのファイル」にはGodotプロジェクトフォルダ内のファイルが表示されていることが確認できます。
(.gitignore で除外されているものを除く)
リポジトリの準備ができたら、このプロジェクトを作成しただけ(空)の状態で最初のコミットまでを済ませてしまうことをおすすめします。
→これは、初回コミットにはリベースができない(作業が煩雑になる)ためです。(詳細は後述)
ここで、リポジトリ/Godotプロジェクト作成時に生成されているGit関連ファイルについても簡単にまとめておきます。
.git
=(ローカル)リポジトリ。
gitで管理されたバージョンデータは圧縮されてこのフォルダ内に格納されていきます。
gitattributes:
gitの振る舞いを制御するためのファイル。
一般的にはリポジトリのルートディレクトリに配置します。
gitignore:
Gitでのバージョン管理において、無視する(トラッキング対象外とする)ファイル or ディレクトリを指定するファイル。
Godotプロジェクトにおいては、デフォルトで「.godot/」ディレクトリ以下を無視するように設定されています。(ここにはGodotの内部処理に必要なデータ類が格納されています)
ステージングとコミット
Godotプロジェクトで、何らかの編集をした後(もしくは初回リポジトリ設定後)は、
リポジトリに変更を反映する作業(ステージング→コミット)を行います。手順は以下のとおりです。
1. プロジェクトファイルの編集(変更の確認):
まずはGodotプロジェクトフォルダ内のファイルに対して、何らかの変更を行います。
→新規ファイルが追加されたり、既存のファイルに変更が発生すると、Gitはその変更を検知します。
(読み込まれていないときはF5で更新できます)
Source treeでは、この内容を
[ファイルステータス]
→[作業ツリーのファイル]から確認できます。(変更がない場合は非表示となります)
2. ステージング (git add):
[すべて/選択を インデックスに追加]から、変更内容をステージします。
→ファイルが[indexにステージしたファイル]
へ移動したことを確認できます
※ステージングとは、
次に行うコミット(変更の反映)の準備として、「反映する対象を選別する」作業のイメージです。=インデックスに追加するとも言います
3. コミット (git commit):
ファイルステータス下部にあるテキストボックスにコミットメッセージ※を入力し、
右下のボタンからコミットを実行します。
※例は初回コミットのため、コミットメッセージは「初期化(initialize)」の略で「init」としています。
チェックアウト
[チェックアウト]は、Gitにおいて“移動”を行う操作で、ファイル状態を特定のコミット時点のものに揃復元したり、作業ブランチ(後述)を変更したりするのに使用します。
※以下ではチェックアウトによって[復元]を行う方法を紹介します。
また、なにか作業をした後、ステージングを行う前にチェックアウトを実施することで、実質的に[ステージしていない変更を取り消す]ことも可能です。
GitにおけるHEADやブランチは、「作業が行われている場所」を示すためのポインタです。
いかがそれぞれの意味になります。
ブランチ | あるコミット単体を指すポインタ (ブランチの履歴全体ではないことに注意) →新ブランチが作成されれば、そのブランチ固有のポインタが作成される |
HEAD | 今作業が行われている(チェックアウト中の)ブランチを指すポインタ →ブランチはコミットを指すため、間接的にコミットに対応関係を持つ ※ブランチポインタは複数存在し得るが、HEADは必ず一つ |
detached HEAD | HEADがブランチで指定されていないコミットを指している状態 →解決するには任意のブランチにHEADをチェックアウトすればOK |
ブランチの作成
ブランチは作業している場所を示すポインタの意味を持ち、Gitではこれを用いて並行した作業を管理・進行できます。
→例えば、「新機能開発」と「バグ修正」のブランチを分けて作ることで、それぞれの作業に影響を出さずに並列して作業の進行ができるようになります。
ブランチの統合:マージ
作成したブランチ各個の作業が完了したら、メインとなるブランチに変更を反映するため、統合作業を行います。
これを実行するのが、「マージ」操作です。
コンフリクト(衝突)発生時の対応
マージを行う際、統合するブランチで同じ変更箇所を編集していた場合、衝突(コンフリクト)が発生し、マージが失敗することがあります。(Gitがどちらを反映すべきか判断できない状態)
→マージを実行するには、コンフリクトの解消が必要になります。
今回は例として画像のようなブランチを用意しました。
同一gdスクリプトファイル7行目にて、
mainでは、 printt(“TEST01”)
sub_test02では、printt(“TEST02”)
と、衝突が発生するようにコミットしています。
衝突(コンフリクト)の解消:
衝突が発生したファイルをGodotで開くと、画像のように衝突した箇所と各ブランチの内容が表示されています。
→衝突を解消するにはこの部分を編集し、
・どちらか一方の編集内容を採用
・または、2つを統合した内容を新たに追記
といった対応を行います。
マージには、以下2種類があります。
ファストフォワード | ・マージを行う際、ブランチの HEAD を最新ブランチ先端に移動させるだけのマージ ・HEADの位置が変わるだけのため、マージコミットは発生しない =コンフリクトは発生しないが、履歴が残らないことに注意 ・マージするコミット履歴が一致する場合、自動的にこのマージになる |
ノンファストフォワード | ・マージコミットが発生するマージ →マージした履歴が残る ・コンフリクトが発生する可能性がある |
おわりに
今回はローカルリポジトリでの基本操作についてまとめました。
次回からはリモートリポジトリ(GitHub)での操作と共同作業についてまとめていきます。
コメント