[git]使用方法と仕組み：総集編！
今回は、チーム開発が始まる前にgit知識の整理を行なっていきます！
タイムマシーンgitは仕組みさえ理解できたら何も難しくない！
そもそものgitの仕組みから必須コマンド、注意点まで、総集編で書いていきますヾ(๑╹◡╹)ﾉ"
gitとは
＜概説＞
- ”分散型バージョン管理システム”.
- 「変更履歴を管理できる」「コードを簡単に共同編集できる」の2つが長所。
- 主にプログラムのファイルを管理するために使用。
-
git の本質は,データを圧縮してスナップショットで保存していること!
=>これによってバージョンを管理を行うことができている。(マージなどの章で詳しく書いていきます。)
バージョン管理ツールとは
”データを誰が、どこを、いつ編集したのかを履歴残しながら、データを保存するもの。”
- ファイルの作成日時、変更日時、変更点などの履歴を保管ファイルの作成者、作成日付、更新日付、更新者、変更履歴、コメントを記録できる。
=> 過去の状態や変更内容を確認したり、変更前の状態を復元することが可能。
なぜバージョンを管理するのか
- “アジリティを高めるため”
※Agility = 機敏さ,素早さ,敏しょう性。 最適に判断し、迅速に対処できる能力
⏩開発中にソフトウェアにバグを埋め込んでしまっても、問題発生の以前の状態へ簡単に戻せる - 素早い開発に役立つ
- 余計な情報でコードが肥大しない
変更内容は記録されるため、変更前の内容をコメントアウトしてコード中に残したりをする必要がなくなり、人が読みやすい状態を保てる。
バージョン管理方法は2種類ある！集中型と分散型
この違いを理解するために前知識が必要！
この二つの差はリポジトリにある。
リポジトリとは
リポジトリ＝貯蔵庫。
データを保存しておくところ。これには二種類ある。
- サーバー側のもの＝リモートリポジトリ
- ローカル側(個人のPCなど)のもの＝ローカルリポジトリ
集中型（svn）はローカルリポジトリを持たない。
分散型（git）は両方持っている。
これが何を意味するのか、仕組みも見ながら見ていこう！
◉集中型 [SVN （subversion）]
ファイルの保管場所は一箇所のみ（リモートリポジトリのみ）。
⚠️サーバ上でファイル情報を一括管理するため、
サーバにつながっていない状態ではファイルの変更情報を記録できません。
みんな同時に編集してしまうと、だれかが変えたので上書きされてしまう。
誰かは作業し保存できて、誰かはできません。の状態になってしまう。
◉分散型 [Git（SouseTree）]
利用者1人1人に専用の保管場所がある（＝ローカルリポジトリ）。
バージョンをそれぞれのローカルに丸ごと複製（クローン）して、個々で作業、
ファイルの修正が一段落したら、
チーム全員で共有する保管場所（リモートリポジトリ）に反映（＝プッシュ）させる。
ユーザーがそれぞれ自分のPC内にリポジトリ（保存場所）を保持しているため、
ネットワークにつながらずサーバにアクセスできなくても作業ができる！！
gitの仕組みついて！zoomして詳しく見ていこう
ざっとイラストにするとこんな感じ！
gitのデータの持ち方：snapshot
大雑把に、イラストにするとこのような感じ。(少し見ずらいかも…。)
<スナップショット>
コマンドの説明とともに、snapshotとはどのようなものなのか、やっていきます。
[初回]必須コマンド
ローカルにリポジトリを作成しリモートにプッシュする際の手順
| コマンド | 説明 |
|---|---|
| git init | リポジトリを新規作成コマンド |
| git add | 変更をステージに追加 |
| git commit -m "コメント" | メッセージをつけて変更履歴を保存 |
| git branch -M main | デフォルトブランチをmasterからmainに変更する。デフォルトブランチmainの場合は不要 |
| git remote add origin リポジトリURL | originという名前でリモートリポジトリのURLを登録する。 |
| git push origin ブランチ名 | ローカルの変更をリモートリポジトリにアップロードする。「ブランチ名」にアップロードしたいブランチの名前を指定します。 |
下の三つに関しては、gitからコピペで大丈夫！！！
git init = リポジトリ新規に作成コマンド
initコマンドを実行後、現在の(または指定した)ディレクトリに,「.git」というリポジトリを構成するディレクトリが作成される。
=> .gitにはGitで使用するファイルが新規に作成される
= リポジトリを再度初期化を行いたい場合も使用。
git add ＝ 圧縮ファイルが作られインデックスに追記、ステージングエリアに追加
git addコマンドを実行すると、ステージにのせたファイルを圧縮し、インデックスに追記する。
= この追加されたファイルはblobオブジェクトという。
※blob:カタマリ=ファイルの中身を圧縮しただけのカタマリ
Gitの専門用語では、ファイルは『ブロッブ（blob）』と呼ばれる。
また、ここでの**圧縮ファイルは正確に名前を言うと、 "ハッシュID" **という。
そもそもなぜステージがあるのか
答えは,コミットを変更する順にをする時や、一部の変更を記録する際など、
一度その"一部の変更"を記録するために存在している。
git commit = commitファイルの作成コマンド
git commitコマンドを実行するとまず、treeオブジェクトが作成される。
そして、コミットファイルが作成される。
● ツリーファイル ＝ treeオブジェクトという。
ファイル構成を表すファイル。
ファイル名とファイルの中身の組み合わせを保存するためにあるのがツリーファイル。
●コミットファイル = commitオブジェクトという。
コミットが親コミットを持つことで、変更履歴を辿れるようになっている
=>これがスナップショット
少しの期間だけ保存しときたい… git stash
-
作業コピーに加えた変更を一時的に保存し (または stash して)、他の作業をした後で戻って再適用できる便利なコマンド！！
-
作業しているローカルの Git リポジトリにのみ適用される。
=> プッシュ時にサーバーには転送されない！！！
ログの確認・操作
コミットする前（addする前）など、確認の癖をつけよう！！
| コマンド | 説明 |
|---|---|
| git log | コミットの履歴を確認する |
| git reset コミット | 履歴を元に前の状態に戻す。「コミット」には識別番号を指定します。git reset HEAD^で一つ前に戻すことも可能 |
| git status | ファイルの追加/変更/削除の確認 |
＜注意＞
git resetなどは、あまり使用しない方が良い。
[2回目以降]コマンドまとめ
ローカルにリポジトリの変更をリモートにプッシュする際の手順
| コマンド | 説明 |
|---|---|
| git add ファイル名 | 「ファイル名」の部分にファイル名を指定することで、指定したファイルをインデックスに追加することができます。 |
| git commit -m "コメント" | メッセージをつけて変更履歴を保存する。 |
| git push origin ブランチ名 | ローカルの変更をリモートリポジトリにアップロードする。「ブランチ名」にアップロードしたいブランチの名前を指定します |
gitの最大の特徴：ブランチ機能
- ブランチ = 分岐(コミットID)の連なりの記録。
ブランチはコミットIDを記録したポインタにすぎない！！！
HEADは現在作業中のブランチへのポインタ！！！
複雑なことはしていない！ただのポインター！ということを踏まえて学習しよう。難しくない！
-
ブランチを作る（＝ブランチを切る） ことで、変更履歴を分岐して記録したり、
合流させてそれぞれの変更内容を統合したりする。
＜ブランチを切る意味＞
複数人で1つの製品を開発するとき、対応状況や対応結果を反映するときに、
対処している問題などの単位でブランチを切ることで,他の開発に影響を与えず開発することを可能にしている。
ブランチの作成・確認コマンド一覧
| コマンド | 説明 |
|---|---|
| git branch | ブランチの一覧を表示する |
| git branch ブランチ名 | ブランチを作成する。「ブランチ名」の部分に、作成するブランチの名前を指定します |
| git checkout ブランチ名 | ブランチ名を指定して切り替える |
| git checkout -b ブランチ名 | ブランチの作成と切り替えをまとめて実行できるコマンド |
ブランチをきるとどのようなことが起こるのか
このようになっていくのはイメージできる。
( ex. )
現在:masterブランチにいるとする。
=> 一旦ブランチをきる(ここではそのブランチの名前は"future")
ブランチを切った時の状態
ブランチを切った時点では、上にかいた絵のように、両方ともコミット３を指し示している。
その後、作業を行ってコミットするとどのようになるか
コミットするとブランチの指すコミットファイルが変わる
上記したように、現在いるブランチがmasterブランチだから、
コミット行うとmasterブランチにコミット４が作成される。
新しいブランチで進めていきたい！
新規作成したfutureブランチにコミットを追加していくには、
futureブランチをチェックアウトする必要あり！
git checkout <branch>
リモートリポジトリをローカルリポジトリに複製 (cloneする)
| コマンド | 説明 |
|---|---|
| git clone リポジトリURL | リモートリポジトリをローカルリポジトリに複製する（ダウンロード）。「リポジトリURL」は複製したいリモート先のURLを指定します。 |
git からクローンしたい！！！となったら、、、
まずクローンしたいもののHTTPSをコピーをして、
ターミナルで
git clone コピーしてきた**HTTPS 実行！
それをVSコードで開きたい！
VSコードでそれを開きたい、となったら code . 実行で開く！
開いた後、必ずしないといけないコマンドが３つ！！！
bundle install
gemなどは容量が重いからgitignoreと、gemfileにだけ書いてgitに保存してあった状態
なので必須コマンド。
(gemなどのパッケージはこのように基本的にgitにpushされて保存されない。)
gemfile とは
これはあくまでtext であって、ここに書いたから何か変わるわけではない
.gitignoreファイル
Git による追跡から特定のファイルを除外するための設定を書き込むファイル。
.gitignore に記載された対象ファイルは、git add の実行時に、
インデックスに追加されないようになる!
(bundle installというのはbundler gemが入っていないと使えないコマンド)
yarn install
⇒ package.jsonにリスト化されている全ての依存関係を
node_modules 内にインストールするコマンド。
JS系もインストールが必要なので必須。
yarnとは
jsのパッケージを管理できるパッケージマネージャのこと。
パッケージとは
コンピュータに何のソフトウェアがインストールされたかを記録し、
新しいソフトウェアのインストール・新しいバージョンへのソフトウェアの更新、
以前インストールしたソフトウェアの削除を容易に行えるようにするプログラムのこと。
ライブラリもこの中の一つ。
-
rails db:migrate
DBもからになってるからもう一度インストール
リモートリポジトリの変更をローカルに反映させる
| コマンド | 説明 |
|---|---|
| git fetch origin | リモートリポジトリからローカルにあるリモートリポジトリのコピーに最新情報をダウンロードする |
| git merge ブランチ名 | ローカルブランチに反映する |
| git pull origin ブランチ名 | fetchとmergeをまとめて実行できるコマンド |
”マージする”
この意味は、ブランチとブランチを合わせること！
他のブランチでの変更分を自分の手元に取り込める。
コミット（プッシュ）も合わせると言う意味では似ているが、コミット（プッシュ）はリモートリポジトリへの時に使う！！
⚠️マージできないケースがある！
→それぞれが範囲分担されているのに
他の部分も触ってしまい、誰かと誰かが一つの同じ部位のコードをいじってしまった時
git marge ブランチ名これでマージはできるが、、、
マージの取り込みかた(仕組み)は３種類
1. Fast Foward : 早送りになるマージ
緊急のバグなどがあった際に、hotfixというブランチを新たに作成して修正、
hotfixブランチからマスターブランチに取り込む際は git margi hotfix でできるが、その場合…
⇒ masterがhotfixと同じものを指すようになる。
ブランチが枝分かれしていない際は、
（masterbuランチの先のものならば、）ポインタが前に進むのみ。
これをFast FOWARDという。
２. Auto Marge : 基本的なマージ
masterブランチ、featureブランチ両方に変更がある時、取り込まれると、
新しいブランちが作成される。
これはmasterブランチベースに、featureブランチの変更分を取り込みスナップショットしたもの。
枝分かれして開発していた場合、マージコミットという
あたらしいマージコミットが作成され、変更履歴を統合している。
このマージコミットは親を二つ持つのが通常コミットとの違い。
３. コンフリクト
コンフリクトとは：複数人の人が同じ箇所で別々の変更をしてしまった場合に、
どの変更を優先していいものかわからない状態のこと。
＜解決方法＞
<<<<<<< HEAD
# 作業ブランチでの変更内容
・・・
=======
# develop(マージしたブランチ)での変更内容
・・・
>>>>>>> develop
このように出てくるから、差分を確認しながら編集する
起こしちゃいけないけど、起こしたことあるエラー集
detached HEAD
detached = 切り離された、分離したの意味。
detached HEADは、HEADがブランチから切り離された状態のことを言っている。
要するに、**ブランチがない状態で、「HEAD がコミットIDを直接指し示している状態」**をいう。
<なぜそうなったのか>
過去のcommit IDを直接指定してcheck outすることによって発生した。
＝＞ちゃんとブランチの仕組みについて理解していなかった！！！
解決策を書いておくと…
①ブランチをきる （git checkout -b ）
(=> resetではなく、ブランチを切ってそのエラーも残しておく)
②git addする
③git commit する
④git checkout mainにする
勉強参考教材
<UDEMY> チーム開発
Discussion
git margi hotfix誤字でしょうか
ドンミンさんコメントありがとうございます！すみません自分でどこを
git margi hotfixになりそうな誤字の所を探したのですが見つけれないです…！(´༎ຶོρ༎ຶོ`)