はじめに
Gitです。独学のころは必要に応じてChatGPTに聞いてやってました。
私の小さいメモリに、Gitを覚える領域はなかった・・・・・・寝て揮発してました。
基礎の基礎でも、体系的に学べるのはなかなか楽しみ。
メモず
雑記：用語：リポジトリ
もともとの英語の意味は「保管庫」
IT業界においては、以下のように言い換えられる
リポジトリ=バージョン管理機能付きディレクトリ
ディレクトリという言葉は一般的でないので、フォルダと呼ぼう。
さらに、バージョン管理というのもピンとこないので、「全変更履歴が保存される」としよう。しかし、「変更履歴」と呼ぶと「作成・削除」をイメージしにくいので、それも入れよう。よって、
リポジトリ=「作成・削除を含む全変更履歴の保存機能付きフォルダ」
しかし、これでもまだ問題がある。それは、ブランチ・マージ・コンフリクト解決・複数人での開発について十分にカバーできていないことだ。また、変更履歴が保存できるメリットについても説明できていない。よって、
リポジトリは「作成・削除を含む全変更履歴の保存機能付きフォルダ」である。これを使うことで、「複数人での同時開発、変更の比較、選択が可能」になる。
満足。
git init
最初のお作法。初期化。
で、何が起きてるの？
- 実行されたディレクトリに、隠しディレクトリ
.gitが作成される -
.gitの中には、Gitの設定ファイルが作成され、リポジトリの設定を管理できる - 初期ブランチ
mainが作成される。
雑記：初期・メインブランチの名前
昔は、masterだった。「主人」のニュアンス。だけど、masterという言葉は、往々にして対のslave（奴隷）を想起させる。それはよくないとなり、今はmainと名付けるのが主流
git add file_name
待機リストに追加（add）する、というイメージ
なお、追加されるのは「変更履歴」である。
「追加」は正確には「ステージング」という
雑記：すべての変更をaddする方法
git add -u
git commit
待機リストの変更履歴たちを、リポジトリに記録（commit）する。
git commit -m "message"：インラインコミットメッセージ
多くはこのように使われる。エディタを開く必要がないのでスムーズ。
詳細な説明・長文には向かない。
単にgit commitとするとどうなるのか？
テキストエディタが開き、そこにコミットメッセージを記入する必要がある。
詳細な説明・長文の場合はこちらの方法をとるとよい。
テキストエディタはgit config --global core.editor "editor_name"で変更できる。
git remote add repogitory_name repogitory_url
リモートリポジトリの登録。
git push repogitory_name branch_name
リモートリポジトリへ変更履歴をアップロード
この変更履歴に基づいて、リモートリポジトリでファイルが変更・作成・削除される。
↑ たぶん。自信ない。
git pull repogitory_name branch_name
リモートリポジトリから変更履歴をダウンロード
この変更履歴に基づいて、リモートリポジトリでファイルが変更・作成・削除される。
↑ たぶん。自信ない。
git status
ローカルのGitに関連する状況を表示できる。
ブランチの情報：On branch branch_name
On branch main
Your branch is up to date with 'origin/main'.
ここでは、mainブランチから、リモートのorigin/mainに同期している
ステージングされた変更：Changes to be committed:
ステージング（add）されたファイル
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: example1.txt
new file: example2.txt
deleted: example3.txt
modifiedは変更されたファイル
new fileは新しく作成されたファイル
deletedは以下略
ステージングされていない変更：Changes not staged for commit:
変更されたが、ステージング（add）されていないファイル
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: example4.txt
未追跡のファイル：Untracked files:
新しく作成され、まだ一度もgit addされていないファイル
Untracked files:
(use "git add <file>..." to include in what will be committed)
example5.txt
これを引き続きgit addしたくなければ、.gitignoreファイルに記述することでGitの追跡から除外できる
マージの競合：Unmerged paths:
On branch main
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: example.txt
no changes added to commit (use "git add" and/or "git commit -a")
both modified: example.txt：2つのブランチ、どちらでもexample.txtが変更されているため、どれを保持するか決め、編集する必要がある。
git diff
ファイルの状態を見れるgit statusと違い、実際に何が変更されたかを見ることができる。
特定のファイルだけ表示
git diffだとすべての変更が表示される。
git diff file_nameで特定のファイルの変更のみを見ることができる。
さらに、オプションを追加することができる。
git diff --staged file_nameで、ステージングされた変更だけを表示できる。
git log
コミット履歴が見れる。
git log -pで、変更内容も見ることができる。特別な表示モードになる。
qキーで終了できる。
git checkout
ブランチのあれこれ
git checkout branch_name：ブランチに切り替え
git checkout -- file_name||directory_name：最後のコミット時の状態に戻す
git checkout -b new_branch_name：新しいブランチを作成し、そのブランチに切り替える
ただ、複数の機能が1つのコマンドに集約されており、誤って使用すると進捗がふっとぶ可能性がある危険なコマンドでもある。
Git 2.23でgit switch / git restoreが導入されており、これらを使うのが無難。
git switch
git switch branch_name：git checkout branch_nameに同じ。ブランチに切り替え
git checkout -b new_branch_name：git checkout -b new_branch_nameに同じ。新しいブランチを作成し、そのブランチに切り替える
git restore
git restore file_name||directory_name：git checkout -b new_branch_nameに同じ。最後のコミット時の状態に戻す
git rebase
履歴を直線的にする。mergeの前に行う。
rebaseなしでmergeを行うと、履歴が分岐して残される。どの変更がどのブランチから来たかを残したい場合はrebaseを行わなくてよいが、履歴が複雑になる。
git branch -D
ブランチを強制的に削除する
まとめ：Gitサイクル
ローカル
初期設定：init⇒remote add
Gitサイクル：(add→commit→push) or (pull→add→commit)
開発中：status / diffを用いて変更を確認。特にpushの前
リモート
初期設定：何かしらでリモートリポジトリを作成
開発中：必要に応じて設定の変更、プルリクエストを通じたマージ
雑記：git pullとpull requestの、2つのpull
どちらのpullも「引き寄せる」意味。
git pull：リモートから、ローカルへ「引き寄せる」
pull request：サブブランチから、メインブランチへ「引き寄せる」
終わりに
Gitも楽しかった～！
なんとなくやってたことが体系的にわかるの、めちゃくちゃ気持ちいいですね。
Gitの苦手意識克服できたの、エンジニアとして働くにおいて必要不可欠だと思うので
今日は大きな一歩でした。