# GitとGitBucketを利用した開発フロー

Gitはバージョン管理をするためのツールですが、Gitの良さは分散型バージョン管理が出来るという点が大きいです。今回は複数人数の共同開発を想定してGitBucketを利用した開発フローについて説明していこうと思います。この開発フローは、GitHubで提案されている[GitHubフロー](https://b.pyar.bz/blog/2014/01/22/github-flow/)と呼ばれるものです。詳しい解説は、そちらのリンクから見たほうが良いと思います。GitBucketを利用した場合でも、開発のフローは変わりありません。

# Gitの初期設定

$ git config --global user.name "John Doe"
$ git config --global user.email [e-mail]
$ git config --global core.editor emacs

# 開発の流れ

GitHubフローは、とても単純です。以下の流れに沿って開発を進めるだけです。

## 開発を始めるときは常に最新に

開発を始めるときは、ソースコードを最新に保つ必要があります。Gitはブランチと呼ばれるリポジトリの状態をいくつか持っています。何も操作していなければ*master*ブランチ担っていると思います。ブランチを確認するには、以下のコマンドを使用します。アスタリスクが付いているものが現在のブランチです。

$ git clone https://~~~ or git://
$ cd [project-dir]
$ git branch
* master

GitHubフローではmasterブランチはデプロイ用で、最新の本番環境で実行されることを想定しています。そのため、```開発はmasterブランチでは決して行ってはいけません```。masterブランチの最新状態から開発を始めるため、以下のコマンドを使用します。これでリモートリポジトリ(GitBucket・共有サーバ)から最新のソースコードを取得することができます。

$ git pull

## 開発は作業用ブランチを切る

先程、「開発はmasterブランチでは決して行ってはいけません」と言いました。それでは、どうすればよいのでしょうか？ 答えは、開発用のブランチに切り替える(ブランチを切ると表現します)という作業をします。

$ git checkout -b [branch-name] // 新しいブランチを作る場合
$ git checkout [branch-name] // 既にあるブランチに切り替える
$ git branch // 現在のブランチを確認

開発用のブランチ名は、そのとき作業する内容ごとに切り分けます。この作業の内容は、失敗したときに大きな手戻りを防ぐ意味でなるべく細かい方が良いと思われます。ブランチ名の例を幾つか上げます。

機能追加
- create-xxxx
- implement-xxxx

機能変更
- update-xxxx
- modify-xxxx

機能修正
- fix-xxxx
- refactor-xxxx
- delete-xxxx

なるべく、シンプルに意図が伝わりやすい名前にすると良いでしょう。

## 開発開始

ブランチを切ってしまえば、master(本番環境)は守られるため、自由に開発可能です。コミットの頻度は、ブランチが小さく切っていれば1~3度ぐらいで済むはずです。これも手戻りが少ないよう、関数やクラスが1つ完成したらコミットするようにしましょう。

$ git add .
$ git commit -m "コミットコメント(変更の内容・理由を簡潔に)"
$ git log // コミットの確認

## 作業内容はリモートへ

気が済むまで変更が終えたら、ブランチごとリモート(GitBucket・共有サーバ)へコミットを上げます(push)。originと言うのは、習慣でデフォルトのリモートブランチを指します。

$ git push origin [branch-name]

## 変更を確認する

あなたのプッシュした先のリモートリポジトリを確認してみましょう。この場合は、GitBucketで対象となるリポジトリページを開きます。そしてブランチをクリックして、新しいブランチが増えていることを確認しましょう。


## 相手の変更をレビューする(共同開発者目線)

ここで、あなたではない、他の共同開発者の目線になりましょう。いきなり変更をmasterに反映してはいけません。別の開発者に変更を見てもらいましょう。また別の開発者も機能を変更している最中かもしれません。レビューするには、手元の環境で以下のコマンドを使用します。ブランチを手元で切る場合に加えてリモートブランチを指定しただけですね。

$ git pull
$ git branch [new-branch] origin/[new-branch]
$ git checkout [new-branch]
// 一度でやる場合は、以下
$ git checkout -b new-branch origin/new-branch

$ git branch // ブランチの確認

あとは、変更内容をコミット履歴等と照らし合わせながら、確認しましょう。このとき面倒を避けるために、ファイルの変更等をしない方が吉です。

## 変更をmasterへ マージする(リモート編)

相手が変更内容を確認し、レビューが終わったら、GitBucketでmasterブランチへの反映(マージ)をします。リポジトリのページを開き、左のメニューから**Branches**を選択します。そこから```New Pull Request```をクリックします。


すると、自動でマージをするためのプルリクエスト(変更要望)が生成されます。コメントは残しても、残さなくても構いません。問題なければ、```Create pull request```を押します。


次に、本来ならここでプルリクエストのための議論をするべきですが、既にレビュー済みなので、```Merge pull request```を押します。


マージが上手く行ってることを確認したら、不要になったリモートブランチを削除します。```Delete branch```を押します。


## 変更をmasterへ マージする(ローカル編)

リモートでのマージをローカルで反映します。ブランチをmasterに戻して、pullするだけです。

$ git checkout master
$ git pull

リモートと同様、不要になった開発ブランチを削除します。

$ git branch -D [branch-name]
$ git branch
* master // こうなってれば成功

# まとめ

これで、安全かつ簡単に開発を進めることができます。ポイントは、開発は本番とは別のブランチで安全に行う。マージはリモートでクリックのみの簡単操作で終わらせる。やってしまえば、これだけです！