-
Notifications
You must be signed in to change notification settings - Fork 0
Gitについて
Gitはバージョン管理システム(VCS:Version Control System)と呼ばれるものです。
例えばtest/フォルダにindex.htmlというファイルがあったとして
何もせずに修正を加えてしまうと元の状態に戻したいときに困ります。
そのため、フォルダをコピーしてtest1210/のように
バックアップを取ってから変更を加えることがあります。
これがバージョン管理です！
変更履歴を残すだけであれば、日付フォルダでもなんとかなりそうです。
ではなぜGitが必要なのでしょうか？
それは他にも便利な機能がいっぱいあるからです！
一部ご紹介します。
- 修正をひと固まりにして保存する機能
- 修正内容の他に、修正日時、修正した人、コミットのタイトルが含まれる
- コミットを意味のある単位でまとめることで、コミット単位の差分を見たり、修正の取り消しが簡単にできる
- 修正された差分を見る機能
- 追加された文字や削除された文字、古いファイル名や新しいファイル名をわかりやすく表示できる
- 複数のコミットをまとめる機能
- 同じファイルを違う人が同時に修正したときに、両者の作業内容を自動的に取り込んで反映する
gitはローカルにあるファイルを
-
作業ディレクトリ
- 変更を加えた作業中のファイル群
-
ステージングエリア
- 次のコミットに含めるファイル群
-
Gitディレクトリ
- 変更が確定したファイル群
- コミット完了した状態
という3つの状態に分けて管理します。
例えば、index.htmlとstyle.cssを修正して同時にロゴの画像(logo.png)を変更した場合を考えます。
変更を終えた瞬間、3つのファイルは作業ディレクトリにあります。
でも、同時にコミットしてしまうと1つのコミットに2つの変更内容が混ざってしまうし、1つ1つコミットすると作業が大変でコミットログも見づらくなってしまいます。
そんな時に、まとめてコミットしたい内容をステージングエリアに一時的に保存しておけば、ファイルの入れ忘れを防げ、同じ変更内容の単位でそろえておくことができます。
- リポジトリ＝データの保管場所という認識でひとまず問題ないです！
リポジトリには大きく2種類あります。
-
リモートリポジトリ
- インターネット上にあるリポジトリのこと
- もっと言うとGitHub上にあるリポジトリのこと
-
ローカルリポジトリ
- 自分のパソコン内にあるリポジトリのこと
この2つは重要な概念になるので覚えておいてください！
ちなみに上に書いた3段階のファイル状態はローカルリポジトリの話です。
リポジトリの運用方法はいろいろあると思いますが、今回のプロジェクトでは
- GitHub上でリモートリポジトリを作る
- それぞれのパソコンにリモートリポジトリをダウンロードする(このときにローカルリポジトリになる)
- それぞれがローカルリポジトリに修正を加えてリモートリポジトリに反映させる
- 3を繰り返して完成に近づけていく
という運用になります。
できるだけ簡単な言い回しにしたかったので表現が適切じゃないかもしれないですが、こんなイメージになります！
ここで紹介する用語はGitを扱う上で必須級のものなのでぜひ覚えてください！
「パソコンにリモートリポジトリをダウンロードすること」を clone（クローン） といいます。
「ローカルリポジトリに修正を加えてリモートリポジトリに反映させること」を push（プッシュ） といいます。
プルの必要性をイメージしやすくするために次のストーリーを読んでください。
- あなたは数人のチームでWeb製作をすることにしました。
- 代表1人がGitHub上にリモートリポジトリを作成しました。
- メンバーそれぞれがクローンしてローカルリポジトリを作りました。
- あるメンバーが修正をコミット、プッシュしてリモートリポジトリが更新されました。
- しかしその修正はあなたのローカルリポジトリに反映されません。
ここで、「リモートリポジトリをローカルリポジトリに反映させる」必要があります。
これをプルといいます。
ここもイメージしやすくするために次のストーリーで考えましょう。
A君はGitHub上にリポジトリを作成して、ファイルを追加しました。
A君とB君はこれをクローンして、それぞれが別の更新作業を行います。
リモートリポジトリのファイル
<p>おはよう</p>先にA君が更新作業を終えてコミット・プッシュしました。
A君の更新内容
- <p>おはよう</p>
+ <p>こんにちは</p>つづいてB君が更新を終えてコミット・プッシュをしました。
B君の更新内容
- <p>おはよう</p>
+ <h2>おはよう</h2>ここでコンフリクトが発生しました！
一般的にコンフリクトが発生した時は、後からコミットした人が解消作業します。
このプロジェクトでもそのように進めようと思いますので、コンフリクトが発生した時はここを見ながら落ち着いて解消作業を進めてください！
例えば、ヘッダーとサイドメニューを作りたいときに
- A君がヘッダー
- B君がサイドメニュー
のような割り振りであればブランチを意識せず開発を進めることもできそうです。
一方で
- A君とB君がヘッダー
- C君とD君がサイドメニュー
のような割り振りであれば A君とB君用の作業場所、C君とD君用の作業場所を分けて開発したいですよね！
それを一つのリポジトリ内で実現できる機能がブランチです！
1つ目の割り振り方でもブランチをわけることがあります。
例えば常にmainブランチをリリースしているコードの状態にして置きたい場合です。
そうすることでソースコードの管理がしやすくなるので、
アップデート機能は新規ブランチで作業して実際にリリースする時にmainに反映させます。
その名の通り「プルしてください」という要求をすることです！
分岐させたブランチは最終的にmainブランチに統合しないといけないので、
マージしたいときはorigin/mainにプルリクエストを送ります。