git note

# Git と GitHub について勉強メモ

## Git

コミットは変更点を記録すること
プログラムの変更履歴を追うときにはコミットメッセージを読むためコミットがきれいに行われていると他人は履歴を追いやすい

どのコミットに戻りたいかを指定する時 →「コミットハッシュ」や「ハッシュ値」はコミットに対して固有の一つが割り当てられる → それを指定

リポジトリ

- ローカルリポジトリ
- リモートリポジトリ

ブランチに分けて作業を行う
マージするときに複数のチームが同じファイルの同じ部分を編集していた場合は「コンフリクト」という機能によって変更の衝突が起こる前に気づかせてもらうことができる。

git config の設定に関して
設定を消去したい時は...
`git config --glibal **--unset** 設定項目名`
とすればよい。

#### 標準ブランチ名の設定

Windows を使っている人は標準で master に設定されているが、Windows 以外の OS を使っている人は、以下のようにして標準ブランチ名を設定する。
`git config --global init.defaultBranch master`

### ローカルリポジトリの操作においての基本的なコマンド

#### リポジトリの作成

`git init`：ローカルリポジトリを作成

#### コミットの作成

`git add`：ステージングエリアに変更を登録
`git commit`：コミットの作成
`git rm`：Git 管理下のファイルやディレクトリを消去する
コミットメッセージについて https://git-scm.com/docs/git-commit#_discussion

#### 状態の確認

`git status`：ローカルリポジトリ内の状況を確認
`git diff`：各エリアの差分を確認する
`git log`：コミットの履歴を確認する

#### 状態の復元

`git checkout`：ワーキングツリーの変更を取り消す(移動のコマンドではなかったのか？)
`git reset`：ステージングエリアに追加した変更をワーキングツリーへ戻す

※ワーキングツリーとは...
Git で管理されている実際に作業を行うディレクトリ

---

#### git diff コマンドについて

`git diff`：ワーキングツリー内とステージングエリアの差
`git diff ブランチ名`ブランチでコミット後にそのブランチでの差を見れる
`git diff --cached`：ステージングエリアと Git ディレクトリの差
が確認できる

---

コミットされるのは git add コマンドでステージングエリアに登録した時点でのファイル
ステージングした後の変更は含まれていない →git add コマンドをもう一度使う必要がある。

---

ローカルリポジトリでの操作の取り消し
`git checkout`：ワーキングツリーでの変更の取り消し → ファイルの状態が直前のコミットまたは直前のステージングエリアへの登録までもどる
※厳密にはステージングエリアの状態まで戻す。
ファイルをいろいろ変更したけど直前のコミットまで戻したい場合。
git checkout -- ファイル名
パラメータにブランチ名を指定するとブランチを切り替えることもできる。
**取り消せないケース**

- ファイルを新しく作成した場合 → ファイルを新規作成したときはそのまま残ってしまう
- ファイル名を変更した場合 → 変更前のファイルと変更後のファイルの両方が残ってしまう

`git reset`：ステージングエリアへの変更の取り消し → ファイルの状態はそのままでステージングエリアへの登録だけを取り消し

#### git restore と git switch について

git checkout はワーキングツリーの変更を取り消す、特定のコミットにワーキングツリーの状態を切り替える、ブランチの作成、ブランチの切り替えなど機能が多い
↓
より分かりやすい役割分担のために導入されたのが git restore と git switch。
`git restore`：ワーキングツリーやステージングエリアの変更を取り消せる
`git switch`：ブランチの切り替え

[`git switch`と`git restore`に関して](https://zenn.dev/gmomedia/articles/d9366fa84aadfd)

---

#### ステージングエリアの登録を取り消す

`git reset HEAD ファイル名`
ここでの HEAD は最後にローカルリポジトリでコミットした状態を意味している →
ステージングエリアの状態を最後のコミットと同じ状態にリセットするという意味

---

#### git の管理下にあるファイルの消去

`git rm` コマンドを用いて Git で管理しているファイルやディレクトリを消去できる
このコマンドによって、ワーキングツリーから指定のものを消去してその状態をステージングエリアへ登録できる。

その他の方法でファイルやディレクトリを消去した場合は、ファイルを消去した状態をステージングする必要がある。
ディレクトリを消去するときは`-r`オプションが必要になる → ディレクトリの中身まで消去するオプション
git rm ファイルパス
git rm -r ディレクトリパス

---

#### 改行コードの警告

`git add`コマンドを行う際に
`warning: LF will be replaced by CRLF` と表示されることがある。
Git をインストールしたときの改行コードの設定が影響している。
改行コードを LF で設定したファイルが CRLF で保存されることがあると警告。
変更されたくない場合は
`git config`コマンドで、`core.autocrlf`を`false`にする必要がある。
改行コードの警告について https://qiita.com/WebEngrChild/items/133484ca79fc90a207d5

---

#### .gitignore

ワーキングツリー内にこのファイルを指定してファイル名や指定の拡張子を中に記載すればそれに当てはまるファイルを無視できる。

Windows では`Thumbs.db`、MacOS では`.DS_Store`は除外するようにする。
gitignore テンプレート https://github.com/github/gitignore

.gitignore の効果は.gitignore を作成したディレクトリ以下に影響する。

---

`git log`で過去のコミットの履歴が確認できる。
・コミットハッシュ
・コミットをした人の情報
・コミット日時
の順で表示される。
`-p`オプションで`git diff`コマンドの時のような差分を確認できる

---

## GitHub

#### 公開鍵の設定

SSH Key を作成する
デバイスごとにひとつずつ作成した。
`ssh-keygen -t ed25519 -C "mail address"`
Enter file in ehich to save the key と表示されたらエンターキーを押す
この時表示される絶対パスが鍵の保存場所
パスワードの作成(流れに乗って)

.ssh/"name".pub の ssh key をコピーして
GitHub の Setting→SSH and GPG keys→New SSH Key→ タイトルを入力して公開鍵を張り付ける →Add SSH Key

上手く設定できたことを確認するために
`ssh -T git@github.com`
パスワード
Hi NAME! You've successfully authenticated と表示されたら設定完了

WSL から Github を使いたい場合この設定が必要？

---

`git remote`でリモートリポジトリの設定などが確認できる。`-v`オプションなど

---

#### branch の作成

`git branch ブランチ名`で作成
`git branch`で現在どのブランチにいるか確認
`git status`でも現在どのブランチにいるかが確認できる
`git checkout 移動先ブランチ`コマンドでブランチを切り替える

---

#### push

`git push プッシュ先のリモートリポジトリの名前 プッシュするブランチ名`
e.g. `git push origin branch-name`

---

#### プルリクエストの作成

変更内容の欄はマークダウンを用いての作成が可能
ここで使われる略語に LGTM(Looks Good To Me)というものがある。プルリクエストの内容を承諾する意味合いを持っている。

---

#### Merge について

- Create a merge commit：枝分かれしたブランチの先がベースブランチに合成される
- Squash and merge：枝分かれしたトピックブランチをひとつにまとめる
- Rebase and merge：ベースブランチの最新のコミットの直後にブランチの枝分かれ元を合成する
  pics #git merge

※Squash や Rebase は履歴の書き換えを行うため、GitHun の「いつでも過去の状態に戻せる」という特徴を失う可能性がある。

---

#### リモートからローカルに

- pull：取得内容がリポジトリ、さらにワーキングツリーにまで反映される
  `git pull プル先のリモートリポジトリ名 プルするブランチ名`
- fetch：ローカルリポジトリまでの取得にとどまる
  `git fetch フェッチ先のリモートリポジトリ名`
  リモートリポジトリにしかない時は fetch を使用できる。fetch してから checkout で移動する。

---

#### About github workflow

https://docs.github.com/en/get-started/using-github/github-flow

---

Creating and deleting branches within your repository

- https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#deleting-a-branch

Changing the default branch

- https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch

If the branch you want to delete is associated with an open pull request, you must merge or close the pull request before deleting the branch.

---

merge コマンド
別のブランチの最新情報を取り込む。
情報を更新するだけでブランチはそれぞれ分かれたまま編集を続けることができる。

この Merge は情報を最新の状態に更新しているだけでブランチを完全に Merge しているわけではないんですよね？

はい、その通りです。git merge コマンドを使用すると、あるブランチから別のブランチへ変更を取り込みますが、これはブランチを"消去"するわけではありません。マージ操作は、指定されたブランチの変更を現在のブランチに統合するだけで、マージ元のブランチはそのまま残ります。

例えば、feature ブランチから main ブランチへマージする場合、feature ブランチの変更は main ブランチに取り込まれますが、feature ブランチ自体は削除されずに残ります。マージ後も feature ブランチで作業を続けることができ、必要に応じて再度 main ブランチ（または他のブランチ）にマージすることが可能です。

マージ操作により、複数のブランチで行われた変更を統合して、ソフトウェア開発のプロセスでコードの整合性を保つことができます。しかし、ブランチを完全に統合して一つにするわけではなく、あくまで変更内容をマージする操作です。ブランチを削除したい場合は、別途 git branch -d ブランチ名 コマンドを使用してブランチを削除する必要があります。

---

#### ブランチの消去

##### ローカルリポジトリ

マージ済みのブランチの消去
`git branch --delete ブランチ名`または`git branch -d ブランチ名`
マージの状況にかかわらずブランチを消去
`git branch -D ブランチ名`

##### リモートリポジトリ

ブランチの消去
`git push --delete origin ブランチ名`または`git push origin :sessions-info`

---

#### コンフリクト発生時において

警告文

- both modified：
- deleted by them：them はマージ先のブランチを指す
- added by you：you はマージ元である現在使用中のブランチを指す

コンフリクトが起こるとコードファイルには以下のように表示される

```
<<<<<<< HEAD
                                    <td>編集後</td>
=======
                                    <td>ハロー<td>
                                    <td>編集前</td>
>>>>>>> master
```

```
<<<<<<< HEAD　使用中のブランチによる変更の開始地点
                                    <td>編集後</td>
=======　二つのブランチの変更の境目
                                    <td>ハロー<td>
                                    <td>編集前</td>
>>>>>>> master　マージ元のmasterブランチによる変更の終了地点
```

コンフリクトが起こっているファイルを編集してコンフリクトを解消したらもう一度コミットする。
コンフリクトにより失敗したマージは解消してコミットを行うまで、マージしている最中(マージ未完了)のままとみなされる
この時のコミットは`git commit`のようにパラメータがいらない

---

#### remote ripository の追加

`git remote add origin URL`

---

#### README.md に画像を挿入する方法

[記事](https://note.com/yukinooffice/n/n8b579ba619f7)を参考に行った

#### README.md にロゴを挿入する方法

[記事](https://t8csp.csb.app/)を参考行った。
条件を選択し、MarkDown 形式の URL？を作成し、README.md に張り付けるだけ！

#### 直前のコミットメッセージを修正する

`git commit --amend -m "Commit message"`

#### SSH キーを変更する

プッシュやクローン時に求められる SSH パスワードを変更する

`ssh-keygen -p -f ~/.ssh/プライベートキーファイル名`