現場で使うGitHubの知識を学習！　デイトラJavaコース初級基礎編Day20「GitHubの現場での使われ方、チーム開発するときに必要な知識」

ハック

こんにちは！運営者のハックです。

今回は「Javaコース初級基礎編Day20「GitHubの現場での使われ方、チーム開発するときに必要な知識」の学習再挑戦について紹介します。

チーム開発をする際のGitHubの現場での使われ方を学習しよう
1. Git-Flow
2. GitHub Flow
まとめ　　Git / Githubを用いて開発を進めることはエンジニアとしては必須

チーム開発をする際のGitHubの現場での使われ方を学習しよう

昨今ではGit を使ったチーム開発が当たり前となってきています。
Git 運用の方法はチームによって異なるものの、基本的にチーム開発におけるバージョン管理は「Git-Flow」と「GitHub-Flow」のいずれかが採用されていることが多いです。
ただし、どちらかを必ず適用しないといけないというわけではなく、実際には現場の方針によりカスタマイズされていたりします。

今回の学習ではあくまで Git でのチーム開発を行う際には、このような考え方があるということを抑えておきます。

Git-Flow

引用：Gitflow ワークフロー | Atlassian Git Tutorial

Git-Flowは、プログラムの開発を効率的に進めるための「ルール」や「作業の進め方」の一つです。特に、チームで作業をする時に役立つ方法です。
Git-Flowでは、コードのバージョン管理をするGitを使い、５つの「枝」（ブランチ）を使い分けます。ブランチ毎に役割が明確に決められていることが特徴です。

主なブランチ（枝）の種類

メインブランチ（Main or Master）:このブランチは「完成品」のコードを保持します。つまり、ユーザーに提供するプログラムの最終版がここにあります。
開発ブランチ（Develop）:新しい機能や修正など、「開発中」のコードを保持します。ここで作業が安定したら、メインブランチに移動させます。
機能ブランチ（Feature branches）:新しい機能を作る時に使います。この小枝（ブランチ）で開発を完了させてから、開発ブランチに統合します。
リリースブランチ（Release branches）:プログラムをユーザーに提供する前の最終確認や小さな修正を行うための枝です。ここでの準備が整ったら、メインブランチに移動させて、ユーザーにリリースします。
修正ブランチ（Hotfix branches）:ユーザーからの緊急の修正が必要な時に使います。直接メインブランチから枝分かれさせ、修正後すぐにメインブランチ（と開発ブランチ）に戻します。

ねこ奈

スマホアプリとかでよくバージョン1.1とか出るのは、リリースブランチからメインブランチに移動されたってことなんだにゃ。

モナ

そういうことです。

スマホアプリのバージョン1.1や1.2などのアップデートは、通常リリースブランチを使用して最終的なテストと調整が行われた後、メインブランチに統合されてリリース（公開）される流れになります。

Git-Flowは開発、修正毎にリポジトリを作成できるため、リリースタイミングに関わらず、並行して作業を進めることができるのが強みです。

GitHub Flow

引用：カゴヤのサーバー研究室

GitHub Flowは、特にWebアプリケーション開発でよく使用される、シンプルで直感的なバージョン管理の運用方法です。２種類（main , topic）のブランチを使用して開発を行います。この方法は、プロジェクトが常にデプロイ（展開）可能な状態を保つことを重視しています。
GitHub Flowは、特にリリースサイクルが短いプロジェクトや、小さなチームで迅速なフィードバックが求められる環境に適しています。

GitHub Flowの基本的な流れ

新しいブランチの作成:
- 機能追加やバグ修正を始めるために、主要なブランチである「masterブランチ」から新しいブランチを作成します。
- このブランチは、作業内容を示す名前が付けられます（例: new-feature, fix-bug）。
機能の開発:
- 新しく作成したブランチでコードの追加や修正を行い、小さい変更ごとに頻繁にコミットします。
プルリクエストの作成:
- 開発が完了したら、GitHub上でプルリクエストを作成し、マスターブランチに変更を統合する提案を行います。
- これにより他の開発者からのフィードバックやコードレビューを受けることができます。
レビューとテスト:
- プルリクエスト作成後、他のチームメンバーがコードをレビューし、自動化されたテストを通じてコードが期待通りに動作するか確認します。
マスターブランチへの統合:
- レビューとテストが完了し、すべてのチェックがクリアされたら、プルリクエストを承認し、マスターブランチに変更をマージします。
デプロイ（展開）:
- マスターブランチに変更がマージされた後、新しいコードを実際の環境にデプロイし、新しい機能がユーザーに提供されます。

GitHubを使ったチーム開発のコマンドライン操作例

# リポジトリをローカルにクローンする
$ git clone リポジトリ名 ディレクトリ名

# 新しいブランチを作成して切り替える
$ git checkout -b branch名

# 変更をステージングエリアに追加し、コミットする
$ git add .
$ git commit -m "変更内容を記載"

# リモートリポジトリに変更をプッシュする
$ git push origin HEAD