前回の話（Gitのインストール）
本投稿の閲覧が役に立ちそうな人
- プログラムもそんなにやったことがない人
- Shellとかコマンドプロンプトとかの知識がないけどGitがなんか使えるってことは聞いたからやってみたい人
- GitHubの導入になんかそのすんごい苦戦している人
- ↑これらの人に教えようとしているけど、なんかその人がよくわからんところで詰まってて「いや、もう無理。〇〇のサイトみて自分で勉強して」って言いたくなってる人。
なお、本記事ではWindows10・11環境でのGitHub利用について記載しております。
前回のあらすじ
前回、Gitをインストールしました。
英語だったしGitがどういうものかという前知識やネットワーク系の知識ないと、まったくわからんよね、という話でした。
あと前回俺の名前使って記事書いてたけど、若干用語の説明怪しかったぞ。
「導入だから問題ないだろうけど」ということで許されました。（ふぅー）
さて、前回GitをインストールしたのでGitの勉強でも始めようかと思ったのですが、そもそもGitって何なんだろう？という疑問が発生しました。
GitHubはその後に登録しようか。
とのことだったので、とりあえず説明サイトをいくつか確認。
これによってマージされます～
ブランチから特定の項目だけを～
プルリクエストすることでプロジェクトを～
えぇ……なに？ もしかして最近世界共通語変わった？
とにかく簡単に流れをまとめてみた
用語の説明に関しては、既にいくつか参考になるページが世の中には存在していたのですが、正直用語は用語だけで「こういう時どうしてる」とか「この用語はこういう時に使う」とかいうのが意外と少なかったので、そちらから調べてまとめてみることに。
①プロジェクト発足！！（リポジトリと[git init]コマンド）
さて、プロジェクトが発足！となった際、Gitではどのような処理になるのでしょうか。
大体は何かしらのプロジェクトの追加やプログラムの変更など既存のものを変更することになるとは思いますので、ほとんどいきなり作成することはないかと思います。
が、例えば初めてGitを導入したり、他である程度進んでいたがGitHubなどで管理したくなったりした場合、リポジトリ自体がない状態なので作成しなければなりません。
前項でも出てたけど、結局のところ
「リポジトリ」ってなんなの？
プロジェクト管理する箱的なものだってことは
何となくわかったけど。
Gitはバージョン管理システムだから、Gitのリポジトリって言えば
「Gitで管理するデータ・ソースがある場所」のことだね。
管理したいディレクトリまで行った状態で、
「git init」と入力することで、そのディレクトリは
Gitのリポジトリになる感じ。
つまりバージョン管理ツールGitでは、まず「リポジトリ」を作成する必要があるということですね。
リポジトリの作成には、マギたんが先ほど言ったように「init」コマンドを使う必要があるようです。早速やってみましょう。Gitインストール時に一緒にインストールしたコンソールアプリの「GitBash」アプリを起動しましょう。
ディレクトリの移動とかは通常のコマンドと一緒だから
「cd」コマンドで移動して。
全て監視対象になってしまい、データ保存のたびに
バージョンが更新されるというビックプロジェクトになる。
GitHubとかで公開してるとユーザーフォルダが全公開になる。
warning: could not open directory '[ディレクトリ名]': Operation not permitted
実際は上記のエラーが出るだろうとのことです。これは「エラーがあるかディレクトリをオープンする操作ができないよ」というもので、Gitでは変更内容を後述する「commit」コマンドで保存する際に、それぞれのプロジェクトより上のディレクトリに別のリポジトリがあると設定が重複してしまい、正しく保存できなくなるようです。
はー、結構めんどくさいんですね。とりあえず、リポジトリを設定するときは他のリポジトリを確認しながら設定する必要がありそうですね。
とりあえず、リポジトリに設定するディレクトリ(フォルダ)を決めましょう。今回は新規プロジェクトなので、フォルダを作ってそこに設定しちゃいましょう。（ついでにフォルダもGitBashで作ってみましょうか。）
GitBashの画面で、とりあえず今いるディレクトリを確認しましょうか。
ls -al
「ls -al」は現在いるフォルダ内のフォルダ・ファイルをリストアップしてくれるコマンドです。ユーザーフォルダ直下が表示されているのがわかりますね。
次は、さっきのリストの中にリポジトリとなる「TestRepository」フォルダを作ってそこに移動しましょう。
mkdir TestRepository cd TestRepository
これで今「TestRepository」フォルダにやってこれました。
コマンドを知らない方のために説明しますと、「mkdir＝make directory」のことでその名の通り、ディレクトリ（フォルダ）を作成するコマンドで、「cd = chdir => change directory」のことらしく（自信ない）今いるディレクトリを変更するコマンドです。
ひとまず、これでリポジトリを作成するディレクトリにつきましたので、本題の「git init」を入力してみます。
git init
「git init」の前半部分の「git」は「今からgit関係のコマンドを使いますよー」というものです。「init」は「Initialized（初期化）」のことですので、「git init」は「Git機能の初期化コマンドを実行」というコンソール命令になります。
リポジトリの設定ファイルとして「.git」フォルダ作成したよ
これでバージョン管理が開始できるな
②Gitの基本はReadmeを設置（「add」「commit」「diff」コマンドについて）
①でリポジトリを新規作成しました。これでこのフォルダでバージョン管理ができるようになりました。早速データを追加してみましょう。
複数人で管理するにあたり、更新情報等が書かれているドキュメントファイルがあったほうがいいからね。
Windows10環境で進めているのでそのフォルダに行って適当な.txtファイルを作成して置いてもいいんですが、調べたところGitHubとかは「.md(マークダウンファイル)」という「HTML形式に変換しやすいドキュメント用拡張子」で保存し、GitHubサービス上で見えるようにすることが多いそうな。
せっかくなので、このままGitBashで作成することにしました。
echo "# TestRepository" >> README.md
Gitコマンドではないので詳しい説明はしませんが、「echo」コマンドで「README.md」ファイルを作成し、そこに「# TestRepository」という文字を入れております。
「.md」拡張子のデータをWebブラウザで表示すると、「#」が書かれた行は「大見出し文字」として表示されます。あとでGitHubサービスサイトで直接この文書を確認した時にでっかく「TestRepository」と表示されるわけですね。
ちゃんとこれが「バージョン管理するファイルだよ」と
Gitに言わないといけない。
「git add」コマンドを使って追加しようか。
どうやらそこまで簡単というわけではないようです。確かにフォルダに入ったものが何でもかんでも管理対象になるとバージョン管理が不要なファイルも含まれてしまうので仕方ありませんね。
とりあえず、マギたんが言うように「git add」コマンドを使ってそのファイルを更新対象にしてしまいましょう。
git add README.md
その際、警告文で「追加されたREADME.mdファイル上の文末改行コードがLF形式だったけど、CRLFに変換したよ。元の文末データは作業中のディレクトリにあるよ」という文言がでます。
前ページのGitインストール時にそういう設定にしたからですね。
「git add」コマンドで実行した内容は「更新情報として保存するリストに該当のデータを追加する」というもので、「git commit」コマンドは「その更新情報リストの情報をバージョン管理データに保存する」というものになります。
今回は分けて実行しましたが、大体の場合ではこの二つの処理を同時に行うようです。
「git add」した後は「git commit」する！という一連の流れを覚えておくといいかもしれません。
補足：addで追加される前のファイルは「ワークツリー」ファイルと呼ばれ、addで追加したデータは「インデックス」ファイルになります。その後commitで「リポジトリ」ファイルとなります。インデックスに含まれていないファイルはリポジトリに入りません。
では、早速「commit」してみましょうか。
コミット前に、ちゃんとaddされているか
データを確認してみようか。
「git diff」で確認できるよ。
作業をしていると時々「add」し忘れるファイルがあったりするらしく、基本addした後は確認するほうがいいとのこと。
「diff」コマンドはadd後のファイル群(インデックス)とcommit後のファイル群(リポジトリ内)を比較したり、複数のインデックスデータの比較をすることができるそうな。
やってみましょう。
git diff --cached
何やら色々出てきましたね。GitBashさんはこういうことを言っております。
diff --git a/README.md b/README.md
さっき加えた[b/README.md]を比較するよー。
new file mode 100644
新しいファイルを「100644」のパーミッション(ファイル権限)形式で
作成するよー。
補足：「100644」の「100」は通常ファイルであることを差しており、「644」はLinuxなどにおけるファイルの表示権限を示すパーミッション値「rw-r--r--」のことを差します。Linuxの権限は頭1桁(ファイル形式)と3桁づつのパーミッション値が3つ分合わさった形で表示されます。
「rw-r--r--」の場合、「rw-」「r--」「r--」の三つに分けられ、左から所有者権限・グループ権限・そのほかのユーザー権限となります。つまり、「所有者は書き込みまでできるが、他の人は読み取りまでしかできない通常データ」というルールのファイルが出来上がったということになります。ややこしいですね！
index 0000000..d10d1c4
「0000000～d10d1c4」を確認するよ。
--- /dev/null
+++ b/README.md
次のcommitで「b/README.md」を追加するよ！
@@ -0,0 +1 @@
+# TestRepository
内容は「# TestRepository」という文章を追加してるよ！
といった感じです。
補足：ちなみにdiffコマンドのオプションでよく使うものをまとめると、以下の通りになります。
| git diff (オプションなし) | add前後（ワークツリーとインデックス）の比較 add忘れを確認するときはこのコマンド。 |
| git diff --cached | commit前後(インデックスとリポジトリ)の比較 commit忘れを確認するときはこのコマンド。 cachedの後にcommit名を入れるとそのcommitデータと比較できる。デフォルトでHEADが入っている。 |
| git diff --cached HEAD | 最新のcommitデータとワークツリーの比較。 |
| git diff HEAD^ | 前回のコミットデータと今回のコミットデータを比較する |
| git diff ブランチA..ブランチB | ブランチ名を指定してブランチ同士を比較する。 |
| git diff -- 対象のファイルパス | ある一つのファイルの変更点を見る。 |
| git diff --name-only | 変更があったファイル名だけ確認できる。 |
次commitしたら追加されるよ」でいいのかな
コミットしてようか。
問題なくインデックスにデータを追加できているようですので、いよいよcommitです。
git commit -m "first commit"
とりあえず、1ファイル1行分追加したよ。
README.mdってやつね。
といった感じです。
終わりだね。お疲れ様。
……え、なにローカルリポジトリって。
もう終わりでいいんだけど。
今まではあくまでローカルPC上で管理する際の管理方法で
一人でしか使わないやり方だね。
外部公開や共同プロジェクトの場合は、これをGitHubなどの
共有のリポジトリに送る必要があるんだ。
リモートリポジトリともいうんだけど。
どうやらまだまだ先は長そうです。
③更新名を設定する([branch]コマンド)
「masterブランチ内で～」ってあったけど、
何も設定してなかったらmasterになるの？
それぞれの作業を分担して更新することがあるけど、
そういったときにブランチ名を分けていると誰が何やっているか
わかりやすいし、あとでくっつけるときに不具合少ないよ。
「master」って名前で触っていると、
なんか畏れ多いから別の名前にしたいんだけど
まぁ使い方としては合ってるんだけど。
ということで、branch名を「master」から変えてみましょう。
使うコマンドはこちら。
git branch -M main
「-M」は「強制的に別のブランチ名に変更する」オプションです。
名前が「main」になったね。
ここから担当者ごとに枝分かれして作業する感じだね。
ちなみになんだけど、例えば俺が「README.md」を
編集する作業をすることになったら、どうすればいいの？
新しいブランチを作成する必要があるね。
では、README.mdを編集する作業担当になったときを想定して、「readme」ブランチを作成してみましょう。
まず、どのブランチから枝分かれするかを決めましょう。
ブランチを切り替えたり、ブランチを作成するときは「checkout」コマンドを利用します。
git checkout main
次に、子になる(枝分かれする)ブランチを作成しましょう。
ブランチを作成するときは「checkout」コマンドの後ろに「-b ブランチ名」で作成できます。
git checkout -b readme
だよ、ってことがわかりやすいね。
あとは「README.md」を編集して、「add」して、「commit」したら
ブランチ「readme」の履歴に保存される感じ。
でもこれ後で編集するときにブランチ作ったこと忘れて
「README」とか「ridomi」とか作っちゃいそうだな
そうならないようにブランチ名は確認しておこうね。
「git branch -a」もしくは「git branch --list」で一覧
出るから一度確認してみて。
git branch --list
または
git branch -a
このブランチとかが大きく関わってくるから、
覚悟しとくといいよ。
以上、Gitの簡単な流れでした。
分岐したブランチは、本来ですと「merge」という作業でマスターブランチに合併する必要があるんですが、ブランチの詳しい項目含めリモートリポジトリ環境で進める場合はそちらで関わってくるので、ここでは一旦省略いたします。
ここまでのまとめ
はい。
結構書いたつもりですが、まとめると意外とあっさりしてますね。
基本Gitはリポジトリを作ってブランチ名分けて編集したデータaddしてcommitして、(今回省きましたけど)mergeという結合作業して終わりという方式ですので、専門用語がわかればわざわざ作業の順番に合わせて説明する必要はなかったかもしれませんね（苦笑）
次回はいよいよGitHubに挑戦します。
この記事、GitHubでUnity管理することを目標としているのに、まだGitHubの登録すらしてないんですよ！ 知ってましたか奥さん！
この記事を書いている時点でGitHubへの登録まで終わってますが、実は地味にUnityでトラブルがあり一から勉強しておりました。なかなかうまいこと行かないものですね・・・ｗ
それではまたー。
