GitHubって難しいよね

GitHubを触り始めた超初心者のメモ
めっちゃ触ってる人には蛇足メモ

本当はMacとかLinuxでやるべきかと思うが、残念ながらwindowsなのでごめんなさい。

Mac及びLinuxについては虎視眈々と狙っていきます。

一応e-learningでぼちぼちと勉強しながらですが如何せん難しい
初心者の私がイメージ出来る程度です。

# GitHubのイメージ

![git_image.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/df7b7932-f6eb-99ca-6e65-a2ab3a386f0a.jpeg)

詳しい事は[Udemy](https://www.udemy.com/course/aigitgithub/)で学習中
(多分これを学習するのが一番と思います。)

要は作ったスクリプトのバージョン管理をやり易くするもの。
『誰が』・『いつ』・『何を』変更したのかを管理するシステムの一つ

# GitHubの用語について

丸パクリ資料
ただ細かく書いてはいるものの、触り続けないと理解しきれないと思う
特に私の様な初学者で別業務(全く関係ない業態)ではさらに倍率ドン！

| 用語                                      | 意味         |
|:------------------------------------------|:-------------|
|**リポジトリ**<br>(repository)                 |履歴管理を行う場所。<br>(要はGitHubの事)|
|**リモートリポジトリ**<br>(remote repository)  |サーバーにあるリポジトリ。基本はベアリポジトリで運用される。|
|**ローカルリポジトリ**<br>(local repository)   |自分のPCにあるリポジトリ。基本はノンベアリポジトリで運用される。<br>(自分のPCの事)|
|ベアリポジトリ<br>(bare repository)        |ワークツリーを持たず、チェックアウト、マージができないリポジトリ。|
|ノンベアリポジトリ<br>(non bare repository)|ワークツリーを持ち、チェックアウト、マージができるリポジトリ。|
|ワークツリー<br>(work tree)                |履歴管理を行いたいファイルがある場所。|
|インデックス<br>(index)                    |コミットしたいファイル又はファイルの一部を登録するところ。|
|ステージ<br>(stage)                        |ワークツリーからコミットしたいファイル又はファイルの一部をIndexに登録すること。|
|ハンク<br>(hunk)                           |変更した一範囲。|
|**コミット**<br>(commit)                       |インデックスに登録してある変更対象をローカルリポジトリに反映すること。|
|リセット<br>(reset)                        |コミット前の変更をローカルリポジトリの状態へ戻すこと。<br>また、特定のコミットまで状態を戻すこと。ただし、ローカルリポジトリに限られる。|
|ヘッド<br>(head)                           |作業対象となっているブランチ、コミット。|
|**チェックアウト**<br>(checkout)               |ヘッドを切り替えること。<br>過去のコミットを対象にチェックアウトした場合、それをもとにコミットすることはできない。|
|**プッシュ**<br>(push)                         |ローカルリポジトリの変更をリモートリポジトリに反映させること。|
|**プル**<br>(pull)                             |リモートリポジトリの変更をローカルリポジトリに反映させること。フェッチ＋マージ|
|**フェッチ**<br>(fetch)                        |リモートリポジトリの変更をローカルリポジトリに反映させること。|
|**マージ**<br>(merge)                          |異なるブランチの変更を反映させること。お互いの変更履歴が残る。|
|リベース<br>(rebase)                           |異なるブランチの変更を反映させること。変更履歴が片方に集約される。|
|コンフリクト<br>(conflict)                 |マージ対象の２ファイルで同じ箇所が変更されており、自動でマージができないこと。|
|**ブランチ**<br>(branch)                       |履歴管理を枝分かれさせてたもの。ブランチを使うこちにより、複数の履歴を並列に管理できる。|
|フォーク<br>(fork)                         |リモートリポジトリをコピーしてリモートリポジトリを作成すること。|
|**クローン**<br>(clone)                        |リモートリポジトリをコピーしてローカルリポジトリを作成すること。|
|プルリクエスト<br>(pull request)           |フォークしたリポジトリでの変更を、フォーク元のリポジトリへ反映するよう依頼すること。|
|.gitignore                                 |履歴管理の対象外とするファイルを登録するところ。対象範囲は各リポジトリ。|
|.gitignore (グローバル)                    |履歴管理の対象外とするファイルを登録するところ。対象範囲は全リポジトリ。|

恐らく太字部分がよく使うのではと…

ただ、用語の言い方が違う所も多いので参考程度で…
(自転車をチャリやケッタっていうぐらい違う)


# GitHubアカウントについて
私はGmailで登録してます。

[Git Hub公式サイト](https://github.co.jp/)

![スクリーンショット (344).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/1458d9a0-a14a-9039-2a36-08aace0df1aa.png)

『GitHubに登録する』を選択すると

![スクリーンショット (345).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/eb73105b-c771-b648-c0b9-30f55e5a0a0e.png)

登録画面に行くので必要事項を登録する。

細かい部分は他に詳しく解説している所があるのでそこを参照した方がよい。

[参考サイト①](https://proengineer.internous.co.jp/content/columnfeature/7103)
[参考サイト②](https://techacademy.jp/magazine/6235)
[参考サイト③](https://git-scm.com/book/ja/v2/GitHub-%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E6%BA%96%E5%82%99%E3%81%A8%E8%A8%AD%E5%AE%9A)

---

登録できるとこんな感じ

![スクリーンショット (346).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/6ce5c343-74dc-713c-5987-0e61e1d09b93.png)

・・・Udemyやってるのがばれるなぁ~

# gitのインストール
MacとかLinuxではまだ試していないから分からないがWindows機においてはコマンドプロンプトでは結構しんどいってか出来ないので
gitなる物をインストールする。

こいつはLinuxやMacのターミナルみたいに使えるもの

[gitのダウンロード](https://git-scm.com/downloads)

![スクリーンショット (347).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/dc45302e-0362-372e-7ffc-2dcbc57f7580.png)

インストールすると`Git Bash`なるアイコン君が出来るのでGitの操作に関しては今後これをメインとしていく。

![スクリーンショット (350).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/1406aa82-47b6-029a-366f-f8e4dec18e4b.png)




# Gitをコマンドで使ってみる
コマンドを全部覚えるなんて無理！
最低限の物のを記載
(今後増えるかは進捗しだい…)

## ①リポジトリのコピー(Clone)
ローカルリポジトリの設定と作成。
基本的にはこの流れとなる。
今回はリモートリポジトリに作成した`.mdファイル`を持ってくるてい

---

ローカルにユーザー情報をセットする。

```
$git config --global user.name "<username>"
$git config --global user.email "<email>"
```

ここでの`username`と`email`はアカウント登録時に設定した物

設定した情報の確認

```
$ git config --global --list
```

---

リモートリポジトリをCloneして、ローカルリポジトリを作成する。

```
$ git clone <リモートリポジトリのurl>
```

![スクリーンショット (352).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/ea6bc76d-1ce3-ed82-5242-77a4500df76f.png)

リポジトリURLについては上記赤枠をコピーする

```
$ git config https://github.com/*****/○○○○○
```

って感じで打ち込む。

ただこのまま普通にダウンロードするとwindowsでいう所のUserにファイルが来るので
予めデスクトップ上など管理し易い所にフォルダを新規作成しておき
`cd ※※※※`でそこに移動してダウンロードする事をお勧めします。

`git bash`立ち上げ時

![スクリーンショット (365).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/0bd5fa08-43aa-af57-2497-f0b38dee605d.png)

`cd Desktop`でデスクトップに移動

![スクリーンショット (366).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/ad15921c-3533-4e01-e51b-2319b4ea8b91.png)

どこで作業するかは個人の好みだが、私的にはデスクトップが楽だった。
(フォルダ置きすぎてデスクトップめっちゃ汚いけど…)

今回のWindows環境で上記までの操作を進めていくと
![スクリーンショット (368).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/dcaced22-07c6-abc9-744b-46b29a1bcfc4.png)

↑デスクトップ上のどこかにもってきた物が出来る(これがローカルリポジトリになる)



![スクリーンショット (369).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/ddcc5df2-3f91-cc96-ed66-e8121f3a32ea.png)

`git clone ~`でリポジトリを持ってきて確認までの一連の流れが上記

`ls -a`は隠しファイルを含めたディレクトリ内データ
`.git`がgitの設定ファイルとなります。

また、`git remote -v`と入力する事で
ローカルリポジトリに紐づいているリモートリポジトリを確認出来ます。

![スクリーンショット (370).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/18a33319-9b0f-a961-ccfc-baf9ee176e36.png)

`fetch`は取ってくる場所(remote → local)
`push`は持っていく場所(local → remote)

簡単に言えばこんな認識をしています。

## ②ブランチの作成

ブランチ(branch)
『履歴管理を枝分かれさせてたもの。ブランチを使うこちにより、複数の履歴を並列に管理できる。』
リモートリポジトリからローカルリポジトリにクローン(コピー)してきたファイルを
直接変更するのではなく一旦別ファイルとして扱う事
まぁバックアップファイルを作成してそこで変更するってイメージです。

---

ブランチの一覧を表示する

```
git branch
```

![スクリーンショット (376).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/78640ee9-dfd1-c7e4-55bf-96dc62bbf924.png)

現在のブランチの場所が分かります(グリーンはアクティブなブランチ)

---

新しいブランチの作成

```
git branch <branch-name> 
```

![スクリーンショット (375).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/a48e88f5-f796-2f6f-61cc-a7194406b79d.png)

変更するデータに紐付いた名前(他人も理解しやすい名前)にする事。
作成後、`git branch`で一覧確認すると
作成した物が表示されます。

---

作業するブランチの切り替え

```
git checkout <branch-name>
```

![スクリーンショット (377).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/7c06ee61-27b6-ff6c-4da4-003d28cc6739.png)

上記コマンドで作業ブランチが切り替わります。

新しいブランチの作成と同時に作業ブランチを切り替えるには

```
git checkout -b <branch-name>
```

これで作成⇒切替が出来ます。

## ③データを変更してリモートリポジトリに反映する準備
`Remote`から`local`に`clone`したデータを`branch`した`working directory`で変更して
`add`して`Staging area`に`commit`して…

初心者はここで詰まる！
用語が分かりにくい！

どこぞの意識高い系コンサルタントが話す横文字か！っと思いました…

今回はまず、ローカルに持ってきた`README.md`を変更する所からいきます。

その前にまずは作業状態はどうなっているかを確認する

```
git status
```

![スクリーンショット (378).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/37c325c1-76dd-c041-667f-2c5a30976b75.png)

持ってきたデータを触っていなければcleanだよと表示します。

---

持ってきたデータを編集すると
(今回はVScodeでファイルを直接開いて、文章追加してます。)
変更前
![スクリーンショット (379).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/0b1f6368-f0cf-de87-f155-47596532eb56.png)

↓
変更後
![スクリーンショット (380).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/c8b31a29-b116-efee-acb2-8ef75fe785fe.png)

ここでもう一度`git status`を打ち込むと

![スクリーンショット (381).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/e85d95ab-dcd2-1708-7ec4-945512460d09.png)

変更されたよと表示されます。

---

次に変更したファイルを`Staging area`簡単に言えば変更した物を纏める箱みたいな物
言い方としては他に`インデックス(index)`とか`ステージ(stage)`とかもあります。



```
git add <filename>
```

![スクリーンショット (383).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/198f8802-a8b6-ef58-f139-61c2aa0f397b.png)

```
git add.
```

上記はディレクトリは以下の全てのファイル。フォルダを`Stagin area`に送る。

複数のファイルを変更等行った場合はこれの方が楽と思う。

## ④コミットする。
今まで変更したデータが`working directory`に出来る
↓
まとめてローカルリポジトリに反映する為、`Stagin area`に纏める

ここでいよいよローカルリポジトリに変更したファイルを反映します。
それが`コミット(commit)`だそうです。

```
git commit -m "<commit message>"
```

コミットメッセージは今からコミットするデータは『何をしたやつ』を端的に表す為
メッセージを入れるのがマスト

![スクリーンショット (385).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/86a76121-18af-03b6-15d7-246df27ff348.png)

これでコミットされます。

コミットした後に`git status`で確認すると

![スクリーンショット (386).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/d44e3303-84f3-6aaa-551e-08057f8c1e57.png)

`working directory(working tree)`には何もないとなります。

---

コミットした履歴の確認

```
git log
```

![スクリーンショット (387).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/f49e4934-f1b4-9ab8-7a89-f0d6cda8d964.png)

これでローカルリポジトリに変更履歴が反映されます。

一番上に表示されるのが最新コミット

やっぱりコメントがないと何をしたものなのかわからないですね。


## ⑤ローカルリポジトリの情報をリモートリポジトリに反映する
大元のリモートリポジトリに、ローカル側の情報を送る事を`プッシュ(push)`するというらしい

ただ、個人でGitHubを使うだけならすぐに`push`しても問題ないが
複数人のチームで色々と行っている場合、リモート側が更新されている可能性があるので
上げる前に一度確認する必要がある
そいつが`プル(pull)`という

```
git pull <remote_ref><branch name>
```
どこから`pull`してくるのかを指定する必要がある
詳細は↓に

![スクリーンショット (388).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/a1b25940-f6f8-d5f8-f6d2-7bc18ce8e6fd.png)


`git remote -v`を入力するとローカルと紐づいているリモートが表示されます
ここの上段がリモートで`origin`を`<remote_ref>`に入力すればOK

`<branch name>`は`main`と入力

そうするとリモート側の`main branch`が更新されます。

確認する癖をつけた方がよいと思います。

---

ローカルからリモート側に`push`する。

```
git push <remote_ref><branch name>
```

`remote_ref`については前述と同じリモート側の`origin`を指定
`branch name`は『**ローカル側アクティブブランチ**』を指定する

今回の例で言うと、自分が作業している`branch`の名前となります。

これはいきなりリモート側のmainを変更するのではなく
リモート側にローカルで作業していたブランチ(ここでいう`kai-branch`)を作るイメージです。

![スクリーンショット (389).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/a88900a2-f370-dc33-af2e-da992ac9a540.png)

リモート側に新しいブランチが出来たと表示が出ます。

GitHub側で

![スクリーンショット (390).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/e4ea7bbe-d500-7723-16b3-09fd502cad63.png)

正常に`push`されていれば上記の様になります。

## ⑥プルリクエストをマージする
また分かりにくい横文字が来ました。

マージとは『異なるブランチの変更を反映させること。お互いの変更履歴が残る。』 ≠ リモート側を変更する
プルリクエストは『フォークしたリポジトリでの変更を、フォーク元のリポジトリへ反映するよう依頼すること。』 ≠ 変更依頼

イメージとしては
メンバー：『ローカル側で色々と触ったやつ上げたから変更してよ』
　　　　　　　↓
リーダー：『確認するからちょっと待って』
　　　　　　　↓　～内容確認～
リーダー：『OKだからリモートのmainに反映するわ』

って流れで認識してます(本当は違うはず)

---

pull requestを作成する

`pull request`を選択する。

![スクリーンショット (392).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/db93e041-0e6e-8241-5e96-d24bdeae31d8.png)

`New pull request`を選択する。

![スクリーンショット (394).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/de80ea49-23ba-fc7c-2aff-3a8707b722fd.png)

`base:main` ← `compare:base`となっているので右側を選択して、プルリクエストしたいブランチを選択する。

![スクリーンショット (396).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/89c2f8c5-38c8-d34b-801e-64dc2d27df38.png)

変更箇所の差分が表示されるので問題なければ『Create pull request』を選択する。

![スクリーンショット (397).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/374c9de3-904e-8914-b085-14d6656557ca.png)


何かコメントを入れて『Create pull request』を選択する。

![スクリーンショット (399).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/5f61bd34-a04b-3382-7515-6ced01a2f058.png)

これでプルリクエストが行われました。

![スクリーンショット (400).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/e82d7702-e09e-1611-9b79-9f8510560378.png)

基本的にはチーム単位で作業を行うのでプルリクエストを行った人以外の人間が確認する。これがマージとなります。

---
pull　requestをマージする

個人としてやる場合は気にしないでよいが
チーム単位でプロジェクトを進めていく場合はきちんとルールを決めておこう事

『Pull request』を選択する。
![スクリーンショット (401).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/d3098f92-be34-cf33-bbfd-e06ba1b57316.png)


リクエストで上がってきたもの(ここでいう`update readme`)を選択する。
![スクリーンショット (402).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/5fd1cd74-d33e-a868-aa39-268343f9a671.png)

『Merge pull request』を押す。
![スクリーンショット (404).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/21fe83ed-a93a-9f04-983a-d92972ae2f56.png)

変更箇所については『Files changed』を選択すると確認出来ます。
![スクリーンショット (405).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/660c7d02-6635-5cc5-fd3a-0364d3592570.png)

変更箇所を確認したうえで、『Merge pull request』を行い完了すると
![スクリーンショット (407).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/bbc57c8c-7bbf-4523-9c8a-500f32a88f90.png)

成功したぞと出る。

![スクリーンショット (408).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/8b812aa3-3eaf-bde6-9efa-b079d7d1d196.png)

これでリモート側のデータが更新されます。

## ⑦ローカルリポジトリを更新する
リモート側を更新しているのでローカル側も情報を反映する(要は`pull`する)
(ローカル側が更新前のままだから)

注意点としては、ローカル側でcommitしたファイル(`kai-readme`)をローカルにマージするのではなく
リモート側から`pull`を行い、メインブランチを更新する。


ただ、`pull`についてはアクティブブランチに適応されるのでメインブランチに切り替える必要がある

```
git checkout main
```

これで切替(復習)


```
git pull origin main 
```

これでローカル側のメインブランチを更新する。

![スクリーンショット (409).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/0deb156a-b85d-4392-b085-fac6393703cc.png)

## ⑧不要なブランチを削除する
ローカルリポジトリのブランチ削除

```
git branch -d <branche-name>
```

メイン(リモート側)にマージしていない場合は削除出来ないみたいです。
また、ブランチを削除する際は`main`に切り変えておくこと

![スクリーンショット (410).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/d50c2a2a-0ead-483b-9498-ee04f2602e32.png)

これで不要になったブランチは削除されます。(打ち間違いはデフォ)

---

リモートリポジトリのブランチ削除

『branch』を選択する

![スクリーンショット (411).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/0c30bd36-37ab-6983-a019-583e311d8dd4.png)

ゴミ箱アイコン君をクリックすれば削除されます。

![スクリーンショット (412).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/607764/94b4d4a5-7833-ba05-279a-a9f0ab6e33c7.png)

リモート側についてはこれで完了

## ⑨スクリプトのアップロードについて

意外と簡単だったのがびっくり

ファイルをドラッグアンドドロップで行けた



# まとめ
多分ここまでが基本的な操作と思います。
ちなみにssh接続については…個人としてはやっていますが
現時点では別に問題ないと思っています(プロジェクトを上げないので)