Sourcetree で簡単に使うGitHub

# 対象
- プロジェクトにアサインされたので、最速でGitHubの基本的な使い方を取得したい人
- コマンドを使わずにGitを扱いたい人


# 環境

| - | バージョン |
| :-:|:--|
| OS | macOS Catalina |
| Git | 2.24.3 (Apple Git-128) |
| Sourcetree | 4.0.1(234) |

## セットアップ
### Git
1. インストール

    Mac を使っている場合は [Xcode](https://apps.apple.com/jp/app/xcode/id497799835) に付属している Git を使うのが無難でしょう。
    ※ Xcodeをインストール後に一度起動して、付属ツール(Command Line Tool for Xcode)のインストールをしましょう。
    それ以外の環境の方は [Git - Downloads](https://git-scm.com/downloads) から Git を導入してください。
1. **コマンドの使用に不安がある方は以降はスキップして、[Sourcetree](#Sourcetree)から続けてください。**
1. Git ユーザー名の設定

    以下の`ユーザー名`を使いたいユーザー名に変更する。

    ```
    $ git config --global user.name "ユーザー名"
    ```
1. Git コミットメールアドレスの設定

    以下の`コミットメールアドレス`を使いたいメールアドレスに変更する。
    ※GitHub で設定しているメールアドレスと同一になっている必要があります。

    ```
    $ git config --global user.email "コミットメールアドレス"
    ```

### Sourcetree
1. インストール

    1. [Sourcetree](https://www.sourcetreeapp.com/)より、Sourcetreeアプリをダウンロードしてください。
    1. 初回のセットアップをします。
        - Bitbucketのアカウント作成は無視して「続行」できます。
        - gitコマンドを使って Git のユーザー名・コミットメールアドレスを設定してない方はここで設定できます。
1. 環境設定からユーザー名とコミットメールアドレスを確認しておきましょう。
    <img width="789" alt="スクリーンショット 2020-06-20 15.11.27.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/20ef2783-42b4-96b7-b2fd-a4d050f36146.png">


1. GitHubアカウントと紐付けます。
    1. アカウントタブから「追加」します。
    <img width="500" alt="スクリーンショット 2020-06-20 15.14.18.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/f4203876-e1fa-0d15-4112-bc8b33943200.png">

    1. GitHubアカウントと紐付けます。
    <img width="500" alt="スクリーンショット 2020-06-20 15.18.46.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/8d19c65c-e207-1566-3618-d4c69bd2f2d3.png">
    
    | 項目 | 選択肢 | 説明 |
    |:--|:--|:--|
    | ホスト | Bitbucket, GitHub, GitLab, etc. | GitHubを選択します。 |
    | 認証タイプ | Basic, OAuth | Basic: GitHubのユーザー名とパスワードを入力できます。<br>OAuth: 「アカウントを接続」から、GitHubで認証できます。  |
    | プロトコル | HTTPS, SSH | GitHubでSSH接続の設定を行っていない場合は、HTTPSを選択します。 |

#### リポジトリのクローン
1. GitHub のリポジトリから URL をコピーします。
    ※GitHubでSSH接続の設定を行っていない場合は、右上にある "Use HTTPS" を使用してください。
<img width="500" alt="スクリーンショット 2020-06-20 16.16.19.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/750143a9-f1ac-c7f9-03ac-01af0896e06d.png">
    
1. Sourcetree でコピーした URL を使ってリポジトリをクローンします。
    1. 新規... > URLからクローンを選択します。
    <img width="300" alt="スクリーンショット 2020-06-20 16.14.38.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/ac60dbdc-bc77-22ac-ed08-c830a724b676.png">

    1. ソース URL を埋めると他の項目も自動で埋まります。
    <img width="500" alt="スクリーンショット 2020-06-20 16.26.23.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/90083fad-27d2-7586-6ed1-20850183467c.png">

1. クローンが完了すると、そのリポジトリのウィンドウが表示されます。
    <img width="500" alt="スクリーンショット 2020-06-20 16.33.25.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/34992a91-f5b2-3c49-242f-981ce68288df.png">


# ワークフロー
会社やチームごとにGitブランチのワークフローが決められています。
今回は、以下の2つのワークフローを紹介します。

- git-flow
- GitHub flow

## ワークフローが必要な理由
もし、あなたが一人で開発を行っている場合には、ワークフローは必要ないかもしれません。
例えば、ずっと master ブランチで作業していても、さほど問題は生じないでしょう。
なぜなら、コードは唯一の開発者であるあなた自身が把握しているからです。

しかし、複数人のチームで開発を行っている場合には、複数の機能追加が同時並行で進みます。
あなたが充分に把握していないコードが混入することになります。
その結果、一つのブランチだけで作業していると、以下のような問題が生じる可能性があります。

- 他メンバーが作業中の未完成コードが混入する。
- 充分にテストされていないコードが混入する。
- 本番環境で重大なバグを発見したが、作業中のコードがあるため修正をリリースできない。

こういった問題を回避するために、Git のブランチを使った運用ルールが必要になります。
ワークフローはこの運用ルールを実現するためにあります。

## git-flow
git-flow は Vincent Driessen氏の[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)を基にしたフローです。
git-flow は後に紹介するGitHub flowと比べると、大規模で複雑です。
よりシンプルなワークフローが適している場合もありますが、既存のプロジェクトに参画する際にはそこで使われているワークフローを知っておく必要があるので紹介します。
ここでは、GitHubで行うべきことも追記してあります。

### フロー
#### メインブランチ

| 名称 | 説明 |
|:-:|:-:|
| master[^master]  | 本番環境に対応しているブランチです。 |
| develop | 次のリリースに向けた最新の変更が反映されたブランチです。 |

<img width="300" alt="main-branches@2x.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/0f97cb70-1a26-8dae-6ab7-924ad30c5bbb.png">

[^master]: masterという名称は差別的な意味を含んでいるため、変更する動きもあります。<br>[blacklist/whitelist master/slave に関する情報集め](https://gist.github.com/mattn/488af4c3b3841ea901a1f9820636393c)<br>[Change the default branch from "master" to something else #929](https://github.com/cli/cli/issues/929)

#### サポートブランチ

| 名称 | 説明 | 分岐元 | マージ先 | 命名 |
|:-:|:-:|:-:|:-:|:-:|
| feature | 新しい機能を開発するためのブランチです。 | develop | develop | feature/ブランチ名 |
| release | 新しいリリースを作成するためのブランチです。 | develop | develop と master | release/ブランチ名 |
| hotfix | 本番環境で発生した重大なバグを修正するためのブランチです。 | master | develop と master | hotfix/ブランチ名 |


#### feature
feature ブランチは新しい機能の作業を始めるときに使います。

1. feature ブランチは develop からブランチします。
1. feature ブランチは で新しい機能の開発を行います。
1. GitHub に Pull Request を作成し、新しい機能や変更について議論をしたり、レビューの依頼をします。
1. 機能が完成したときは、feature ブランチを develop ブランチにマージします。

<img width="200" alt="fb@2x.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/5bbad315-9a6e-b0ad-12e0-f824568d6f54.png">

#### release
release ブランチは新しい本番リリースの準備をするときに使います。
新しい本番リリースのバージョン番号が割り当てられるのは、release ブランチが作成されるときです。

1. release ブランチは develop からブランチします。
1. relese ブランチには新しいバージョン番号の命名をします。例えば、release/1.1.0 などです。
1. relese ブランチで新しいバージョンのリリース準備をします。内部のバージョン番号の修正や軽微なバグフィックスも含まれます。
1. （必要な場合は）GitHub に Pull Request を作成し、レビューの依頼をします。
1. リリースの準備が完了したら、release ブランチを master にマージします。
1. 次に、master 上のコミットにバージョン番号のタグをつけます。
1. 最後に、release ブランチを develop にマージします。

<img width="300" alt="スクリーンショット 2020-06-21 16.58.27.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/56fc8407-cc0f-a915-8047-aa7e6471c0d8.png">

#### hotfix
hotfix ブランチは本番環境で発生した重大なバグをすぐに解決しなければならない場合に使います。

1. hotfix ブランチは master からブランチします。
1. hotfix ブランチでバグの修正を行います。(バージョン番号をインクリメントするのを忘れないようにしましょう)
1. （必要な場合は）GitHub に Pull Request を作成し、レビューの依頼をします。
1. バグの修正が完了したら、hotfix ブランチを master にマージします。
1. 次に、master 上のコミットに新しいバージョン番号のタグをつけます。
1. 最後に、hotfix ブランチを develop にマージします。(今回のバグフィックスが今後のリリースにも含まれるようにするためです。)

<img width="300" alt="hotfix-branches@2x.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/f6bbcc96-bbfa-86ef-3afd-3dbd268a2bfa.png">

### 引用
[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)

## GitHub flow
GitHub flow はシンプルです。git-flow に比べると命名規則も緩やかです。

### ルール
`マスターブランチにあるものは常にデプロイできる`

### フロー
#### ブランチの作成
機能追加や変更を行う際には、 master から新しいブランチを作成します。
ブランチ名は説明的なものにします。(例えば `add-authentication`,`refactor-authentication-controller` など)

<img width="400" alt="スクリーンショット 2020-06-21 18.52.14.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/27e15ade-1617-995c-9805-79d66e106fd5.png">

#### 変更の開始
新しく作成したブランチで変更を開始します。
あなたが何をしたのか、なぜしたのかを理解できるようなコミットメッセージを書くことを推奨しています。

<img width="400" alt="スクリーンショット 2020-06-21 18.52.09.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/2fd0e2c7-6251-9d2c-e2f9-09d8f0d6f05d.png">

#### Pull Request の作成
新しいブランチの Pull Request を GitHub で作成します。

<img width="400" alt="スクリーンショット 2020-06-21 18.53.28.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/a507c84e-7e11-a83c-7865-aac630cc9e31.png">


#### コードについて議論し、レビューする
Pull Requset を使って、コードについての議論やレビューをします。
フィードバックを得て、コードに変更を追加することもできます。

<img width="400" alt="スクリーンショット 2020-06-21 18.53.32.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/801d94a4-2fc6-accf-b0df-51a9ec0f9db0.png">


#### デプロイ
master にマージする前に、本番環境やテスト環境にデプロイして最終テストをします。
もし、問題を発見したら、既存の master をでブロイしてロールバックすることができます。

<img width="400" alt="スクリーンショット 2020-06-21 18.53.51.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/6b866a98-5dfd-2d56-a5cc-9a6e080be877.png">


#### マージ
本番環境での変更が確認できたので、master にブランチをマージします。

<img width="400" alt="スクリーンショット 2020-06-21 18.54.04.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/297266/9a2b6aa4-1f70-cc56-c2cc-af028899313b.png">

### 引用
[Understanding the GitHub flow](https://guides.github.com/introduction/flow/)

# Sourcetree で git-flow
Sourcetree を使うと、簡単にgit-flowを導入することができます。