読者です 読者をやめる 読者になる 読者になる

複数人プロジェクトにおけるGithub開発フロー

参考サイト

ここを参考にさせていただきました。

GitHubを使った今時のWebアプリ/システム開発の流れ - Rails Webook

フロー

1. プロジェクトをクローンする

プロジェクトをクローンする。

$ git clone URL

forkするのかなぁと思っていたのだけど、どうやら違うっぽい。OSSにコントリビュートするときに、forkを使うとのこと。OSSバージョンの開発フローもまたまとめておこう。

2. masterブランチを最新の状態にする

これ大事なので忘れないようにしたい。

$ git checkout master
$ git pull

毎回最新を保つように。

3. masterブランチから新しいブランチを切ってpush

僕の今のプロジェクトの場合だと、トピックブランチをみんな切って開発するようにしてて、命名規則username_topicみたいな感じ。

$ git checkout -b "トピックブランチ名"
$ git push orign "トピックブランチ名"

ブランチを切ったらpushしておく。これ大事だなー!

そして名前もしっかりつければ、リモートリポジトリでブランチ一覧を見ればみんながどんなタスクに取り組んでるのか分かり易い。

トピックブランチも、コードレビューしてもらいやすくするために、比較的細かめの粒度を意識したいところ。

4. 開発してpush

トピックブランチのタスクにきちんと見合うように開発を進めて、そのブランチにcommit, pushしていく。

$ git add .
$ git commit -m "Commit Message"
$ git push -u origin "topic_branch"

5. pull requestを作成・コードレビュー

pull requestを作成してフィードバックをもらいながら改善していく。

6. 他の開発者に同意をもらう

マージできるレベルまで到達したら:+1, +1,LGTM(Looks Good To Me)などの同意をもらう。

「2,3人以上がレビューし、その結果+1などのコメントが2,3個以上存在したらPRを行った開発者がmasterブランチにマージできる」みたいなルールを決めておく。

7. rebaseしてcommitを束ねる

masterブランチにmergeしたときに、後からcommitが多すぎて見づらいわ!ってならずに、一つのmergeで一つの機能が実装できてるイメージになった方がいい。ということでmergeする前に必ずrebaseしてcommitをまとめてからmergeする。

$ git rebase -i HEAD~3 

基本はpickは1つにして、その他をfixupで過去のコミット1つにまとめます。

コードレビューが終わってからrebaseすること、レビューしやすいようにコミットの粒度は小さくしておこう。

8. ついにマージ!!

そしたらやっとマージ!!!おめでとうすぎる!!!

TODO

この記事がすごくよかったので参考にして近いうちにアップデートしたい。

GitHub - 開発フロー研修 @ Wantedly - Qiita