Posted at

知らないとヤバい!チーム開発で必要な【GitHub Flow】


はじめに

最近、プログラミングスクールが増えてきましたが、チーム開発の現場で必須のGithubの使い方を学べるところはまだ少ないんではないでしょうか?

趣味で個人アプリを開発する場合は、必要ありませんが有名なWEBサービスは、ほとんどがチーム開発です。そのチーム開発に必要な開発フローについてご紹介します。


目次


  • Githubのmasterブランチとその他ブランチ

  • ブランチをマージする

  • masterブランチは、常時デプロイできる状態にしておく


Githubのmasterブランチとその他ブランチ

masterブランチとは、最初にコミットをするとできるブランチです。複数人でアプリを開発する際は、このmasterブランチをクローン(コピー)してそれぞれのブランチで作業します。

そうすることによって、作業を細分化することもできますし、もしコードの書き間違いがあってもmasterブランチに影響がでないのでより効率的に開発を進めることができます。


ブランチをマージする

開発者がそれぞれのブランチで、開発ができてもその内容をmasterブランチにマージ(結合)しなければ反映されません。


masterブランチは、常時デプロイできる状態にしておく

ここまででmasterブランチとブランチがどのようなものかだいたい理解できたかと思います。

例えば、それぞれの開発者が、masterブランチにコミットしているとします。もしその開発コードにバグやエラーがあったら稼働中のWEBサービスが止まってしまいます。

それを防ぐためにそれぞれのブランチでコードに問題がないかなど確認した上でmasterブランチにマージします。


新たな作業をする時は、masterブランチから新しいブランチを作る

機能の追加やバグの修正ごとに新しくブランチを作成します。ここで重要なのですが、ブランチ名には「誰が見てもその作業がわかる」ようにします。


ブランチを定期的にpush(リモートリポジトリに反映させる)する

各開発者のローカル環境で作成したブランチでは、他の開発者がどのぐらい進んでいるかわからないため定期的にリモートリポジトリにプッシュしましょう。


プルリクエストでコミュニケーションをとる

プルリクエストは、差分を確認する機能やコードの行にコメントを入れられる機能があります。プルリクエストを使うことによって他の開発者からレビューをもらったりアドバイスをもらったりしてより効率的に開発を進めることができます。

FireShot Capture 104 - shinpei555_pet_docter - github.com.png

画像の【Pull requests】の部分になります。


他の開発者が確認・レビューが終わればmasterにマージする

ブランチでの作業が完了後に、プルリクエストを通して他の開発者からレビューをもらいます。他の開発者の目を通すことによって、ミスや思い込みによるバグがmasterブランチに混ざることを防ぐことができます。もし作業内容に問題があれば修正します。


marterにマージしたらすぐにデプロイする

masterブランチへのmergeが行われた時は,マージ直後に必ずmasterブランチの内容が正常にデプロイできるかどうかをチェックする必要があります。もしバグが混入していたとしても、バグの特定が早くなったり、git revertで該当のコミットを打ち消すなど迅速な対応が可能になります。


おわり