GitHubについて

まず、前提としてGitから説明したいと思います
この記事は個人の独断と偏見によって書かれています
# Gitとは
Gitはソースコードやテキストファイル等のバージョン管理システムです。
普段はコマンドベースでコマンドプロンプトなどからコマンドで操作します。
主な流れとしては

1. リモートサーバ等にある中心リポジトリをローカルに複製する (git clone)。
2. ローカルでコンテンツの修正・追加・削除を行い、ローカルリポジトリに変更履歴を記録する (git commit)。必要に応じて過去の状態の閲覧や復元などを行う。場合によってはこのステップを何度か繰り返す。
3. ローカルの変更内容を中心リポジトリに反映させる (git push)。作業者ごとの変更内容が衝突することもある。Gitが自動で解決できる場合もあれば、手動での解決 (git merge）が必要なこともある。
4. 更新された中心リポジトリ（他者の作業内容も統合されている）をローカルの複製にも反映する (git pull)。これによりローカル環境のコードも最新の内容になるので、改めてステップ2の作業を行う。

大まかな流れとしてはこう（[Wikipedia](https://ja.wikipedia.org/wiki/Git)より

また、Gitを使うにはGitをインストールする必要があります。
Git公式:
[https://git-scm.com/](https://git-scm.com/)

コマンドベースのチュートリアルの一覧としてはこちらを参考にしていただければ
[https://qiita.com/yuyakato/items/41751848add5dfd5289c](https://qiita.com/yuyakato/items/41751848add5dfd5289c)

使用コマンド一覧
[Reference](https://git-scm.com/docs)

## メリット
メリットとしては
1. コミットの履歴が残る
2. 誰がどこを編集したのかがわかる
3. 複数人で同じファイルを作業した際に上書きされない
4. 前のバージョンに戻したり、一部分の編集をなかったことにできる


## デメリット
デメリットとしては
1. 使用する人の環境にGitが入っていることが前提
2. 覚えること（コマンド等）が多い



## Branch
Gitでは作業場所を分けて使う事ができる。
複数人で作業する場合は通常、その人数分の作業場所を準備する。
理想的なワークフローはgit-flowが一番理想的ではある。
git-flowに関しては下記に図解されてわかりやすいと思うので時間があるときに読んでもらいたい
git-flow 図解:https://qiita.com/ohnaka0410/items/7c7fa20710dfd72b7d7a

## コマンド一覧

### clone
リモート上にあるgitをローカルにダウンロードします。

```
git clone url
```

とすることでリポジトリのディレクトリが作成されます


### init
gitリポジトリを作成します

### diff
現在のブランチと変更したファイルの変更点を表示します
また、ブランチとブランチのファイルの変更点も表示できます

```
git diff ブランチ名..ブランチ名
```

Pull Requestを送る前に見たいときに使えます

### status
gitに関するカレントディレクトリの状態を表示します
`git add`され、コミットされていないファイルの一覧や
addされていないファイル、.gitigoreで管理対象外にもされていないファイル一覧
が見ることができます

.gitigoreで管理対象外にもされていないファイルとは
新規で作られて、ファイルの履歴が無いファイルのことを指します

### log
gitリポジトリのログ（変更履歴）を表示します
変更履歴で変更されたファイルを一緒に見たい場合は

```
git log --stat
```
とコマンド入力することで変更履歴と変更ファイルを見ることができます。


### tag
gitの変更場所にタグをつけることができます

```
git tag タグ名
```
特定のコミット場所にタグをつけるには

```
git tag -a タグ名 -m 'タグのコメント' コミット番号
```
タグの作成後はpushするとリモートにもタグが反映されるようになります

```
git tag
//または
git tag -l 'パターン'
```
を入力するとタグの一覧が表示されます
パターンに入力するとマッチした一覧が表示されます

特定のタグを確認するには

```
git show タグ名
```
とすることでタグの場所のコミットメッセージや変更者などが見れます。

### show

前述した通り、`git show`を入力するとコミットのメッセージや変更者が見れます。
これはタグだけではなく、コミットのハッシュ値などを入力するとそのコミットの詳細が見れるようになります。
また、ファイルを指定するも可能です。

```
git show タグ名:file.txt
```

### Add
ファイルの変更点をステージング（一時的にまとめておく）する
ステージングしたファイルをCommitすることでGitへ変更点が適用される

.gitignoreを無視して追加することもできるみたいです。

```
git add -f <ファイル名>
```

### Commit
ソースコードの変更点をコメント付で保存することができます。

主に英語でコミットするようになっていますが、日本語でも結構です。

ただ、英語と日本語どちらかに合わせるようにしましょう。（英語のほうが何かと便利です
英語で書く場合に参考になると思う記事

https://qiita.com/shikichee/items/a5f922a3ef3aa58a1839

また、英語で書くメリットとしてGitHubでは`#番号`でIssueやプルリクエスト番号を指定することができます

そのコミットをGitHub上で見るとリンク形式になり、そのリンクが指定されたIssueやプルリクエストに飛ぶことができるの後から見返したときにわかりやすいと思います。

また、commitの頻度はできるだけ細かくしておきましょう。

これは大きな変更を一つのcommitにしてしまうと、その変更点の一つに問題が合った場合はすべての変更が取り消されることになります。

小さな処理の追加でも一つのcommitにするようにしましょう。
メリットとしては下記に記載されています（個人的な考えですが

[Git 作業における commit と push の頻度について](https://qiita.com/kozyty@github/items/87fa95a236b6142f7c10#%E3%81%AA%E3%81%9C%E7%B4%B0%E3%81%8B%E3%81%84%E5%8D%98%E4%BD%8D%E3%81%A7%E3%81%AE%E9%A0%BB%E5%BA%A6%E3%82%92%E6%8E%A8%E5%A5%A8%E3%81%99%E3%82%8B%E3%81%AE%E3%81%8B)



### Stash
今変更を加えたファイルを避難させておくこと

変更後にリモートで変更があった際に使える
1. 今の変更点をstashする
2. リモートの変更をローカルに取り込む
3. stashにある変更を戻す
4. 変更をcommitする

という手順でするとわざわざコピーしておくことなく変更点を戻せる


変更済みのファイルをAddでもなく、stashをすることによって一時的に保管できます。

取り出したいときは`stash pop`をすることで取り出すことができます。

reset時やrevertをする際には事前にやっておくことで変更中のファイルが元に戻ることを防ぐことができるので

やっておくべきだと思います。

### Conflict
ファイル同士の衝突

同じ変更部分があったり、元のファイルと変更したファイルとの差分がおかしくなった場合に発生する

これを解決しない限りそのファイルに変更点を適用できない

Conflictを解決するにはWeb上で解決するか、GitKrakenなどを使って解決する事もできる

### Pull
リモートの状態を現在のローカルに適用させます。

リモートの状態とローカルの状態（commit等）が違った場合にConflictが起きるので
なにかをする前にPullをするということをしておきましょう。

### Push
ローカルにある変更（commit）をリモートに適用させます

また、リモートに適用させてもリポジトリが共有されているすべてのローカルに適用されるわけでは有りません。

個々にPullをすることで変更点を適用させることになります。

### checkout
今現在いるブランチから他のブランチへ移動する際に使われるもの
コマンドでは

```
git checkout -b ブランチ名
```
で変更できる

### merge
マージ、ブランチの変更点を取り入れる際に使ったりする。

例：debugの変更点をmasterに取り入れる際には

```
git merge debug
```
とする

### revert
コミットを取り消します。

取り消す際には順番に気をつけなければ変更が残ったままになる場合がありますで注意が必要です。

取り消す順番としては新しいものから順番に取り消しましょう

また、まとめて取り消したい場合はコマンドを入れるほうが安全かもしれません

まとめて消す際には

```
git revert <対象のコミットID A>..<対象のコミットID B>
```
を使用してコミットの先頭、末尾を時系列で指定します。

revertされるのは先頭(A)の直後のコミットとなり、先頭(A)自体は含みません。

参考どころか引用：[Git revertとresetについて](https://qiita.com/RyoU24/items/e37c7242544fd1da81be)

ちなみにA→B→Cの順番のコミット（Cが最新）を取り消す場合には

C→B→Aの順番で取り消すべきだと考えてます（A→B→Cの順番で取り消した際に変更が残っていたことがあったため

マージをrevertで取り消すことも可能です。

その他revertのコマンドは下記の記事をご覧ください。

[Git revertとresetについて](https://qiita.com/RyoU24/items/e37c7242544fd1da81be)

### reset
上記のrevertでは変更点を戻すコミットを出しますが、resetではコミット無しで戻すことが可能です。

ただし、リモートへpushしたあとに取り消すことはあまりおすすめできません。

一応下記の記事にリモートへpushした後にコミットを取り消す方法が記載されていますので興味があれば

[Gitで誤ってpushしてしまったときのpushの取り消し方法](https://awesome-linus.com/2019/03/09/git-push-by-mistake/)

ローカル内であれば基本的には問題有りません。

ただ、現在変更中のファイル等があればstashしておきましょう

resetの方法は下記記事を参考に

[[Git]コミットの取り消し、打ち消し、上書き](https://qiita.com/shuntaro_tamura/items/06281261d893acf049ed)

```
git reset --hard HEAD^
```

### cherrypic
他のブランチのコミットを今現在いるブランチへそのコミットだけを取り入れるときに使える。

マージしたいけどいらない部分があったり、ブランチを分けてそのコミットだけを入れてPull Requestをしたりと分けることもできるので覚えておくと便利

### rebase
リベース

ブランチ元を変更する

自分が理解できた記事はこちら:
[git rebaseを初めて使った際のまとめ](https://qiita.com/310ma3/items/e0ec74b47c6c219f2a8b)

### bisect
git bisectによって問題が発生した箇所を特定することができます。

```
git bisect start 問題のコミット 問題の無いコミット
```
このコミットの場所にはタグを指定することもできます。

なので、v1.0で問題がなく、v1.5で問題が発生した場合は

```
git bisect start v1.5 v1.0
```
と記述します

そしてテストスクリプトの指定をします

```
git bisect run スクリプトファイル名
```
とすることで、gitが自動的にテストの実行と中間のバージョンのチェックアウトを繰り返し行い、問題が発生した地点を見つけてくれます。

手動で行う場合は

テスト結果が問題ないなら以下

```
git bisect good
```
問題があった場合は以下を実行します

```
git bisect bad
```
上記のどちらかを実行すると自動的に中間のバージョンにチェックアウトしてくれます

その後、再び手動でチェックを行い、問題があるかどうかをgit bisectに教えることを繰り返します。


git bisectが現在チェックアウトしているコミットを確認するには

```
git bisect view
```
で確認できます

過程を確認するには

```
git bisect log
```

元の状態に戻す（git bisectの実行前）

```
git bisect reset
```

参考記事:
[git bisect で問題箇所を特定する](https://qiita.com/usamik26/items/cce867b3b139ea5568a6)

### .gitigoreについて
Gitには特定のフォルダ、ファイルを管理しないように除外設定することができます。

.gitigoreに除外するファイルやディレクトリを設定することでGitで管理しません。

これはC#のbinなど、コードのデバッグで作成されたファイルなどを記載することで管理するファイル容量を抑える事ができます。

このファイルに関しての書き方はコードの言語によってはテンプレートがあったりするので言語に合わせて書いていただきたい。

例：
[VisualStudio.gitignore](https://github.com/github/gitignore/blob/master/VisualStudio.gitignore)

# GitHubとは
GitHubはローカルに置いてあるGitをWeb上で管理できる

Web上で管理することで、ローカル（自分のPC）のソースコードを他のローカル（人のPC）に導入することもでき

他人のPCから変更点をアップしたりすることができる

コマンドベースで触る人は
[こちらの記事](https://qiita.com/b150005/items/508009234bf9813b230f)
も参考に

GitHubのドキュメントはこちら:https://docs.github.com/ja/free-pro-team@latest/github/getting-started-with-github

去年一昨年辺りにMicrosoftの傘下に入り、前まではプライベートリポジトリに3人までしか招待できなかった制限（無料プラン）が解除され、人数に制限がなく、保持できるプライベートリポジトリも3つまでだったのが無制限になった。

[コラボレーターを個人リポジトリに招待する](https://docs.github.com/ja/free-pro-team@latest/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository)

## 画面
友人のリポジトリですがこのような画面になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/77208e6a-bd5e-4c71-765f-65c244b18c7c.png)


### Code
現在のリポジトリにあるファイルや変更点などが見れます
また、コミットに対してコメントの入力をすることができるのでそのコミットに疑問を持ったりした場合はコメントで質問や提案をすることができます

### Issues
現在発生しているバグや機能向上の提案などができます

Issueごとにラベルやコメント、解決してほしいユーザー等の指定ができます、

ラベルに関して：[ラベルについて](https://docs.github.com/ja/free-pro-team@latest/github/managing-your-work-on-github/about-labels)

これがOpenの状態だと未解決、Closeの状態だと解決済みといった具合でひと目でわかるようになります

こちらにもコメントが追加でき、質問や解決に向けての対策などが取れるようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/4d917e10-90d2-e6c5-b381-320913d605a1.png)

### Pull request
各ブランチから他のブランチへ変更点を入れたいときに使います

ここではIssueで建てたバグや機能を`fix #1`（＃の後はIssueの番号）等で指定してプルリクエストがマージされるとそのIssueは自動的にClose状態になります。

こちらもコメントができますので質問等やレビューができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/a6e1627f-bf11-5d61-e352-dbf338fcbbb4.png)

勝手に入れられたくない場合はリポジトリの本人やコラボレーター(設定)のみマージすることや、何人以上がレビューした場合にのみマージボタンが押せる等の設定ができます。

### Actions
GitHubが用意しているAction（動作）から選択できます。

主にあるのは、ビルドが正常に通るかどうかなど

このタブは設定より表示、非表示等の設定ができます。

### Projects
こちらはプロジェクトタブで、Todoリストや完了したものなどリストで管理することができます

また、Issueも追加することができます。![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/df2c580e-b0f5-c8d5-fd2a-818b16bc84e6.png)

### Security

セキュリティタブではセキュリティに関しての設定ができます。

コードの脆弱性がないかどうかをチェックしてもらうユーザーの追加など

### Insights
このタブではリポジトリの状況が見れます。

誰がどのくらいコミットしたか、どのくらいのコードの追加削除を行ったかが見れたり、ブランチのグラフが見れたりします

## GitHub Tools
こちらに一覧が乗ってますのでご参考に

https://git-scm.com/download/gui/windows

下記は自分が使ったことのあるツール一覧
### GitHub Desktop
https://desktop.github.com/

料金：無料

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/7201ad13-c690-65f7-42b7-9a74c4fe0bba.png)

使い勝手は悪くないがIssueの状況が見えなかったり使い勝手が自分的にはよくなく、あまりつかいませんでした。

ブランチの変更やコードの変更点などは見れます。

プライベートリポジトリなども変更することができます。

### SouceTree
料金：無料

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/6945d026-677e-90da-91cd-021eea422432.png)


GitHub Desktopと同様にIssueの状況等が見えないのであまりおすすめはできません。。。

### GitKraken
https://www.gitkraken.com/

料金:無料（一部有料
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/557752/f278da8e-f215-040a-0283-a019ae410938.png)

プライベートリポジトリを開く等は有料になりますが、一番使いやすいと思います。

GitHubと連携し、Issueの一覧やPull Requestの一覧が見れるようになり、Conflict等の衝突の解決も手軽にできます。

価格も年間で5000円弱なのであまり高くは無いと思っています（月々約400円ほど

またこちらにもGitHubと似たようなBoards（GitHubでいうProject）があり、そのBoardに他のGitkrakenユーザーを招待して開発することができます。このBoardにはラベルが付けられたり、日付の追加ができたりと非常に便利で使いやすかったです。

またラベルに対してコメントの追加等ができるのでGitHub Projectよりは使いやすいかと思います。