目次
はじめに
今までGitHub含め仕組みを一切理解せず使ってきたので、そろそろ理解したいなと思い勉強してみました。
※7/7 3か月ぶりに追記しました。(読み返したところ、当時はほんとに理解できていなかったので。。。)
👇関連記事
Git
✅Gitとは
バージョン管理システム。コミットというセーブポイントを沢山設けることができ、以前の状態に戻すこともできる。
※GitHubはGitのホスティングをしてくれるサービス。
✅特徴
分散型バージョン管理システム(複数人が並行して作業を進められる。)
✅メリット
・共同作業の実現。ファイルを1まとめにしてくれる。
・修正の履歴がバックアップされる。前の状態に戻せる。
基本的な使い方(流れ)
コミット編
リポジトリ作成
→コミットしたいファイルをステージ(add)
→メッセージを記載してコミット(ローカルではこれでコミットが保存される)
※コミットメッセージの書き方はコチラ参照 1行目概要、3行目に詳細(理由)
ブランチ編
ブランチ作成
→ブランチを切り替える(チェックアウトと呼ぶ)
→コミット
大事→新しいブランチを作成する際はブランチ元にチェックアウト(切替)して、最新かつクリーンの状態を確認すること
知っておくと良さそうなこと
・最初のローカルブランチは必ずmasterと命名される。(リモートブランチはorigin)
・HEADは現在作業している場所を示すポインタ。
👇.gitignoreでリポジトリで変更を検知しないファイルを指定できる。
test.md // 特定のファイル test/ // 特定のディレクトリ test/test2.md // 特定のファイルを相対パスで設定 !test.md // 指定から外す *.md // .mdファイルをすべて除外
ざっと用語まとめ
ヘッド：現在チェックアウトされているコミット(作業中のコミット)を指す単語。普段は、ブランチ名を指す。
リポジトリ：Gitによって管理されているフォルダのこと(.gitが含まれる)。PC上にあるものをローカルリポジトリ、GitHubなどサーバ上にあるものをリモートリポジトリと呼ぶ。
コミット：ファイルやフォルダの追加・変更をリポジトリに記録する。実行すると差分を記録した「コミット」が作成される。
ステージングエリア(登録する作業をインデックス)：次にコミットされるファイルを保存しておく場所。※コマンドは”git add”
※stage(ステージ)はindex(インデックス)と呼んだりも。
※厳密にはstageした内容を保持する「index」
プッシュ：ローカルリポジトリでコミットした内容をGitHubのリポジトリ(リモートリポジトリ)に反映させる。
ブランチ：タスクごとに併行で作業を進めるためにコミットの流れを分岐させたもの。本流の開発を邪魔することなく開発できる。
※ブランチを作成する際にmasterブランチは最新の状態にしておくこと(ブランチもコミットを指すポインタであるため)。
マージ：ブランチを合体させること。
コンフリクト：複数の人が同じ場所を変更してGitがマージ(合体)できなくなった状態のこと。
クローン：リモートリポジトリをローカルリポジトリに複製すること。自身のパソコン上で作業できる。
フォーク：他人のリポジトリを自分のアカウントのリモートリポジトリにコピーすること。本流の開発に影響を与えずに開発できる。
プルリクエスト：共同作業する際に活用。作業を行っているブランチから、マージしたいブランチに対してマージを依頼すること。(※GitHubの機能)
フェッチ：リモートリポジトリにあるすべてのブランチの状態を、現在のローカルリポジトリに影響を与えることなくすべて取得する機能。
issue：ディスカッションに使え、Pull Requestやコミットと関連付けもできる。更に、Issue番号を記述すると、その課題に対する変更点や進行具合を一覧表示できる
コマンド
✅マストで使うもの(※個人開発・独学中も使った)
リポジトリの作成
git init
ファイルやディレクトリをステージに登録
→次回のcommit対象にするコマンド
“.”を指定するとサブディレクトリも含めたすべてのファイルをステージングエリアに登録できる。-pや-iオプションあり。
git add <ファイル名>
※Aオプションはプロジェクト全体。”.”はカレントディレクトリ以下になるので注意。参考
ステージングエリアに追加されたファイルをコミット
-aオプションで変更されたファイル(新規ファイル除く)を検出してステージングエリアに追加し、コミットできる。-mでメッセージも付けられる。
git commit
ブランチの一覧表示
git branch
既存リモートリポジトリの複製
※ローカルで作業する際に使う。
git clone <URL>
リモートリポジトリの追加
git remote add <リモート名> <URL>
リモートリポジトリにブランチ作成/変更反映
コミットをアップロードして反映させる。-uオプションで対象のブランチをリモートリポジトリに追跡。
git push <リモート名> <ブランチ名> ※デフォルトは origin master
✅知っておくと便利(※現場では使うやつ)
変更内容を把握する
git diff
※前回コミットした時点からのファイル(※中身)の変更点を表示する。
変更されたファイルの一覧表示
git status
※前回コミット時から変更されたファイルのみ表示する。
赤字で表示されれば変更がコミットされていない。
緑で表示されれば変更が適用されている。
コミット履歴を表示する
> git log
commit 482fb7171~~~~~~~~ (HEAD -> master)
Author: cho <@yahoo.co.jp>
Date: Tue Jul 7 22:52:39 2020 +0900
test
※変更内容含めて表示したい場合はgit log -pを使えば表示できる。Qキーで終了。
✅リモートの変更を取得する際使うコマンド
remoteの登録リポジトリ確認
git remote -v origin ssh://git-~~~~~~~~~~~~~~~~~~~~(fetch) origin ssh://git-~~~~~~~~~~~~~~~~~~~ (push)
差分をfetch 参考
git fetch origin
※remote -vで確認できた対象のリモート名を指定
マージ
git merge origin/<マージしたいブランチ名>
取消関連深掘り
変更を元に戻すには”git reset”と”git revert”の2つの方法がある。
resetはブランチのポインタを後方に移動。
git reset HEAD~1
※前のコミット含め削除するので上書きのイメージ。
→ほかの人も使っているリモートのリポジトリに対してはできない。
revertは巻き戻した内容を新しいコミットとして作成する。
git revert HEAD
※新しいコミットは戻すのに必要な
→ほかの人と共有する場合はrevertを利用する。
ステージ編
リポジトリのHEADの内容をステージにコピーする
git reset
特定のファイルだけHEADの状態に戻す
git reset --ファイル名
ステージングエリアへの移動だけでなくコミットも消す
git reset --hard （戻りたいコミットのコミットコード）
コミット編
参考：git commit を取り消して元に戻す方法、徹底まとめ
①直前のコミットを取り消す
git reset --soft HEAD^
softオプションで作業ツリーとインデックスをそのままに、ブランチの先頭のみ変更。
②過去のコミットの直後に戻す
git reset --hard HEAD^
HEADのみではなく、インデックスや作業ツリー上の変更もすべて取消。
※変更内容がすべて消えるため要注意
③直前コミットの上書き
git commit --amend
現在のHEADが指すコミットを破棄して、新しいコミットを作成。
マージに関して深掘り
※別のコミットを指している2つのブランチを統合。
git merge bugFix
※masterブランチで作業している場合、bugFixブランチをmasterブランチにマージしている。
※マージのイメージ c0 │ c1 ┐ │ │ c2 c3 │ │ └ c4
上記のようにc2(bugFix)とc3(master)が統合されてc4(master)が作成されている。
この状態だとbugFixブランチは最新の状態になっていないので最新化。
※内部的にはbugFixのポインターをc2からc4に移動させるだけ。
git checkout bugFix git merge master
マージの代わりにリベース
マージするコミットのコピーを取ってどこかに落とすイメージ
git rebase master // bugFix上で行う git checkout master git rebase bugFix // master上で行うことで
🙄コマンドを打った際のブランチが指定したブランチに合体するという点は認識間違い起こりそうなので注意ですね！！
前述のマージのイメージではc2とc3が枝分かれしているが、リベースを使うとc2とc3が合体して、c3’として新しく作成される。
※リベースのイメージ c0 │ c1 │ c2 (c3※合体する別ブランチのコミット) │ c3'
HEADの分離
git checkout <ブランチ名>ではなくgit checkout <コミット名>とすることで分離される。
コミットのハッシュを確認するにはgit logを使う。
※ハッシュはユニークな存在だと確認できるだけの文字数のみでOK。
相対リファレンスを使うことも可能(HEADやbugFixブランチなど)。
1つずつ上へ移動させる^(カレット)
git checkout HEAD^
複数回上へ移動させる~<num>
git checkout HEAD~4
ブランチを強制的に移動
git branch -f master HEAD~3 git branch -f <移動したい対象ブランチ> <移動先> // masterブランチを強制的にHEADより3つ前に移動する
※-fオプションでブランチを直接コミットに関連付けできる
リモートブランチの扱い深掘り
【初心者向け】git fetch、git merge、git pullの違いについて
fetchもpullもリモートリポジトリから最新情報をローカルに持ってくる。
リモートから最新情報をローカルに持ってくるのですが、場所は「master」ブランチではなく、「origin/master」ブランチに取り込まれます。
- 「master」ブランチ…ローカルの中心となる統合ブランチで、他のローカルの作業ブランチと繋がったもの。
- 「origin/master」ブランチ…ローカルにある、リモートのmasterブランチを追跡するリモート追跡ブランチ。
git pullはgit fetchとgit mergeを同時に行ってくれるコマンド
※リモートから取り込む際はプロジェクトリーダがだいたいgit管理するので、どちらのコマンドを使うかはプロジェクトごとに変わるとのこと。
リモートブランチは固有の命名規則が存在。
origin/master <リモート名>/<ブランチ名>
※gitはgit cloneした際にoriginという名前をデフォルトとしてリモートに付与する。
git checkout origin/master; git commit
👆上記のようにorigin/masterに移ってもHEADが分離し、origin/masterは更新されない。
git fetchはリモートにあってローカルリポジトリにないコミットをダウンロード、リモートブランチ(origin/master)の位置を更新する。
ローカルのリポジトリにリモートのリポジトリの内容を反映させるには以下。
git merge origin/master # 反映したい作業ブランチにて
コンフリクト編
共同製作で他人が自身の機能に依存していたコードを変更してしまった。
↓
この場合、git pushが許可されず、作業を共有する前に最新のリモートの状態を取り込むことを強制される。
↓
リモートブランチの最新の状態に自身の作業が基づくようにしなければいけない。
👉自身の作業をリベースで移動させて解決させる。
git fetch; git rebase o/master; git push ※ローカルのリモートブランチを更新; 作業をリベースで新しい変更に適用; プッシュ
リベースの代わりにマージ
git fetch; git merge o/master; git push
省略
git pull --rebase; git push git pull; git push // rebaseオプションを付ける場合と違い、枝分かれは残る。
その他なるほど！となったこと
✅なぜステージングが必要なのか？
コミットには、コミットメッセージにそぐわない無関係の変更を含むべきではありません。ですがときに作業の都合により、ワーキングツリーに大量の変更が積まれてしまうことがあります。ステージングはその中からコミットに含めたい変更を選別する作業といえます。
🙄普段”git add . “ですべてステージングしてしまっていたので、今後はコミットに含めるべき変更を選別して作業していきたいと思いました。
参考
オプション含め一部非対応のコマンドもあるが、手を動かしながら学ぶことができる！！
※手順通りに打たないと正解にならないが、それも含めて勉強と思えばとても良い！！
📚サルでもわかるGIT入門
Sourcetreeを使ってGitHubの仕組みを理解していく。コマンドラインで学習したい方には向いていないかも。。。
ただ用語の理解とかはしやすい。
また、付録としてコマンドラインで使う方法を紹介。付録-2のコマンドリファレンスは便利。
📚Web制作者のためのGitHubの教科書
こちらもSourcetreeを使ってGitHubの仕組みを理解していきます。
前述の書籍との違いはSourcetreeを使いつつも並行してGitコマンドを紹介してくれているところ。
共同開発のイメージを付けるのであればこちらを読むほうが良さそう。より実践的。
Git – originとmasterとは何か(初心者向け)
おわりに
コマンドを使わずにGUIで操作できるSourcetreeを使うことが今は定番ぽい。
備忘録
※Learn Git Branchの問題に関しての個人的備忘録です。
・Main/HEADの分離 4問目
解答
git reset HEAD~1 // もしくはHEAD^ git checkout pushed git revert HEAD
・Remote/clone入門 5問目
練習用の特別な疑似コマンド
git fakeTeamwork ※リモートで1回コミットしてくれる git fakeTeamwork foo 3 ※追加するブランチを指定して、特定の数コミットしてくれる
解答
git clone git fakeTeamwork 2 git fetch // o/masterの最新化 git commit // masterブランチでコミット作成 get merge o/master
・Remote/clone入門 7問目
git clone git fakeTeamwork git commit git fetch git rebase o/master git push
・Remote/clone入門 8問目
ローカルからリモートのマスターにプッシュする場合、ポリシーでマスターがロックされており、プルリクのプロセスが必要な場合がある。
ここのルールとしてはブランチを作成し、そのブランチをプッシュしてプルリクを実行するプロセス。
問題
featureという別のブランチを作成し、それをリモートにプッシュします。 また、マスターをリセットしてリモートと同期するようにしてください。そうしないと、次にプルを実行したときに問題が発生し、他の誰かがコミットを競合する可能性があります。
git branch feature git reset HEAD^ git checkout feature git checkout feature
模範解答
git reset --hard o/master git checkout -b feature C2 git push origin feature
🙄originもブランチ分けて管理されるみたいですね！
コメントを残す