Git＆GitHub共同開発　実践手順書（初級編）

はじめに

この記事は、

Git 勉強したけど、よくわからない。
GitHub 使いたいけど、１人だから意味があるようなないような。
プルリクしてみたい。

みたいな方向けのハンズオンを意識した共同開発の基本操作を体験するための手順書です。

なお、書いている僕自身エンジニアでもなく、ハッカソンに一回参加したことがあるだけで、また共同開発に対して豊富な知識があるわけでなく、自分の経験の中の学びを基に記載したものですので、現役エンジニアの方が読まれる機会がありましたら、アップデートをしていきたいと思いますので、ご指導のほどよろしくお願いします。

この記事の範囲

筆者が理解している Git（ときに Github を含んで Git といいます 🙇‍♂️）の操作までです（未熟なもので 💦）

ローカルリポジトリのコミット
ローカルリポジトリでのブランチ
リモートリポジトリへのプッシュ
開発用ブランチへのマージ
リモートリポジトリからのクローン

あたりを抑えた、Gitのはじめ方、そして、開発時の基本的な操作について、操作のサイクルを意識して書いています。

必要なもの・こと

Git の環境

この手順をする際は、事前に Git と GitHub のセットアップを済ませておいてください。
ネットで検索すれば、いろんな方が丁寧な手順を書いてくれていますので、本記事では詳しく記載しません。

必要な知識

この記事では Git ってなんだろうということは、あえて説明しません。ネットで検索すれば、わかりやすい説明がされてるサイトも多々ありますので、そちらを参照ください。

そして、ディレクトリを移動するためのコマンド操作とカレントディレクトリがなにか。これは、ぜひ理解してから次の手順に進まれたほうがよいと思います。

Git で共同開発をする場合の手順

それではさっそく手順を進めます。

ぼくは Windows を使っているので、Windows ユーザの想定で書きます。
また、VSCODE を使ってる方向けに、ちょっとした簡単操作なども時々書きます。

操作のシーンを 4 つに分けて、導入から実際の開発時の手順を説明します。

＜シーン１＞
　ローカルリポジトリでのバージョン管理

＜シーン２＞
　リモートリポジトリとローカルリポジトリの接続

＜シーン３＞
　開発環境を整える

＜シーン４＞
　開発しよう！develop ブランチにマージをして完成へ

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＜シーン１＞ローカルリポジトリでのバージョン管理

まずは、ローカルリポジトリ、自分のパソコンの中だけでバージョン管理をしてみましょう。

以下の操作は、VSCODE で操作した場合の用語を用います。あと基本的にコマンドでも GUI でも操作できますが、本記事においては、僕基準で GUI とコマンドを混ぜて説明します。

1. 自分のパソコンに、開発するためのフォルダを準備します。僕の場合、開発するフォルダは user のディレクトリの直下のディレクトリに「projects」というフォルダを作って、その中に、開発する project の名前のフォルダを作ります。今回のプロジェクトは、「tryGit」とします。
   Windows の場合、C:\Users[ユーザ名]\projects\tryGit 　みたいな感じになると思います。

2. C:\Users[ユーザ名]\projects\tryGit に移動。作ったディレクトリをカレントディレクトリにします。（この時点で VSCODE は、tryGit フォルダで開きなおす方が、いろいろ混乱しなくて Good です。）

3. 下のコマンドを実行する。これにより、カレントディレクトリ直下に、「.git」という隠しフォルダができます。この隠しフォルダがあるフォルダが、バージョン管理をするルート的なフォルダになります。

   git init
   

4. （バージョン管理を体験するために）カレントディレクトリの中に、index.html と style.css を作ってみましょう。git init を実行したフォルダの配下のデータなので、バージョン管理の対象となります。VSCODE の左にあるエクスプローラは変更等のあったファイルは下の画像のように、アルファベットや色が付きます。色がついているものは、コミットしていない変更があるということになります。
   

5. ここから、変更の履歴を git にバージョンとして登録（コミット）していきます。まずは、変更履歴をコミットするためのステージに乗せましょう。ステージに乗せることをステージングといいます。変更履歴は、ステージに乗って、そこからコミットという流れが原則です。

   ＜コマンドでステージング＞
   下のコマンドで実行しましょう。とりあえず全部ステージングというコマンドです。もちろん全部をステージングしないということもできますが、馴れるまでは、常に全部でいいと思います。

   git add -A
   

   ＜ VSCODE の GUI でステージング＞
   下の〇を振った部分を押すだけです。
   

6. ステージに載せたらコミットをしましょう。下の画面の薄く「メッセージ（…」と書いてあるところに、変更の概要をわかりやすく入力して「✔ コミット」ボタンを押したらコミット完了です。慣習的に一番最初のコミットは、「ファーストコミット」と入力することが多いのかなと思ってます。ちなみに、これが完了してからエクスプローラを見てみてください。変更があったファイルの色やアルファベットが消えています。変更の履歴がコミットされたためです。
   

以上を繰り返してくことで、ローカルリポジトリのバージョン管理（基本）ができます。

＜シーン２＞リモートリポジトリとローカルリポジトリの接続

次に先ほどのローカルリポジトリを、リモートリポジトリに接続してみましょう。

1. GitHub にログインし、リモートリポジトリを作成する（あえてこの辺は記載しません。わかりやすく書いてある記事が多々ありますので）。とりあえず、ポイントとしては、特に理由がなければプライベートで作るくらいかなと思っています。

2. リモートリポジトリを作ったら「<>Code」というタブに移動しましょう。そこにめちゃくちゃ親切に３通りのセットアップが書かれています。クイックセットアップ、新しいリポジトリをコマンドで作る方法、既存のリポジトリをコマンドでプッシュ（リモートリポジトリにアップ）する方法です。今回は、既存のリポジトリを作っているので、書いてあるコマンドをリモートリポジトリにアップしたいローカルのカレントディレクトリのターミナルで順番に実行したら OK です。

それでは以下コマンドの解説です。

# ローカルリポジトリに、origin（リモートリポジトリ）をリモートで接続するコマンド。
# このコマンドを実行したあとに　git remote　とだけ入力すると　「origin」と表示されれば、リモートリポジトリと接続されているということになります。
#実際のコードはGitHubで確認したとおりです。

git remote add origin https://github.com/〇〇/tryGit.git


# ローカルのブランチ名をmainブランチに変更するコマンド。
# VSCodeの左下を見てください実行する前後でブランチ名が変わります。

git branch -M main


# ローカルのmainブランチの情報をリモートにPush（アップ）するコマンド。
# GitHubのリモートリポジトリでコマンド実行する前後を見比べてみてください。リモートにmainというブランチができてることが確認できると思います。これがPushによるものです。

git push -u origin main

以上で、ローカルとリモートの接続ができました。

＜シーン３＞開発環境を整える

次は開発するための環境を整えましょう。
整えるにあたって、ブランチについて説明します。

＜ブランチとは＞
和訳だと「枝」ですね。イメージとしては、ルート（道）が、しっくりきます。複数の人で作業するとその人の数だけ作業ルートがあるみたいな。そして、ブランチは、以下のように大別されると僕は思ってます。

ブランチ	解説
mainブランチ	完成品の状態を保持するブランチ
developブランチ	開発の段階のみんなの作業を集約するブランチ（各作業してるブランチがここに集合します。
featureブランチ	各作業をする人などのブランチ。僕はfeature/〇〇　の〇〇に名前とか、を書くスタイルが好きです。何よりブランチみたときなんのブランチかわかりやすいのがGOODだと思います。

と、いうことで開発環境を整えるべく開発における develop ブランチを整備しましょう。

1. ローカルリポジトリ（普通 main ブランチのはず）のターミナルで、次のコマンドで develop ブランチを作る。（ブランチ切って移動というコマンドもあるけど、とりあえず。）このコマンド実行後に、git branch でブランチの一覧を見るとブランチができてるのがわかるはずです。ちなみに*がついてるのが現在のブランチです。

   git branch develop
   

2. develop ブランチに次のコマンドで移動

   git checkout develop
   

3. リモートリポジトリに次のコマンドで Push する。このコマンドを実行したあとにリモートリポジトリを見てみてください。main ブランチしかなかったのに、develop ブランチがあります。ここでポイントととして、以下のような push した場合、ローカルのブランチ名がリモートのブランチ名としてブランチが生成又は更新されることを覚えておくと 👍 です。おまけ的ですが、リモートリポジトリのデフォルトのブランチは最初 main になっていますが、開発中は develop をよく使うので、develop を default にするのがオススメです（これをすることで、このあと説明をするプルリクの時に行き先の間違い防止になります。）。

   git push -u origin develop
   

これで、開発した人達が、それぞれのブランチから結合させる場所 develop ができました。
　次が、手順の最後です。実際の開発をしてしましょう。

＜シーン４＞開発しよう！develop ブランチにマージをして完成へ

シーン３までは、環境作りでしたが、シーン４は、実際に開発に参加する人達の操作手順です。
自分だけの feature ブランチを作って、リモートリポジトリに Push して、develop への Pull Request をして、develop にマージする。そうやって、develop がどんどん完成に近づいていきます。では手順を追ってみましょう。

0. 【ちょっと番外】上のシーンを１～３までなぞってきた人は、既に develop ブランチがありますが、作られた環境から参加した人はローカルにリポジトリがありません。こういうときは次の手順でリモートリポジトリからローカルリポジトリを作りましょう。clone をするとリモートリポジトリの名称のフォルダが実行したカレントディレクトリの直下にできます（個人的には、user 名/projects/　くらいで実行するのがいいのかなと思ってます）。ちなみにに以下コマンドの（https のアドレス。）の部分は、GitHub の clone しようとしているリモートリポジトリの画面の Code タブ内の Code という緑のボタンを押すと確認できます（SSH などでも接続できますが、とりあえず https で説明しています。）。

   git clone （httpsのアドレス。）
   

1. ローカルリポジトリで feature ブランチを作ります。feature ブランチは、それぞれ作業をする人単位や部品単位などで作るのだと（思ってます 💦）。今回は人単位に作るということで、feature/〇〇（〇〇は誰のブランチか特定できる名前を）。feature/hiro というブランチを切って、作ったブランチに移動します。

2. 【復習問題】feature ブランチの状態で、index.html をちょっと書き換えて変更履歴を作って、ステージング、コミットまでしてみましょう。（コミットのメッセージは、「セカンドコミット」とします。本番はもっとわかりやすいのにしてくださいね。）

3. 下のコマンドで、リモートリポジトリにプッシュしましょう。うまくいけば、GitHub のリモートリポジトリに feature ブランチができているはずです。

   # ブランチ名はご自身のブランチ名に書き換えてください。
   git push -u origin feature/hiro
   

4. GitHub にログインし、リモートリポジトリに行くと下の画面の黄色背景エリアと緑の「Compare & pull request」というボタンができているので、押してください。pull request をしてみましょう。pull request は、「プルリク」や「PR」と表現されることがあります。僕は最初 PR と見たときわかりませんでした 💦
   

5. 表示された画面でタイトルと概要を記載して、プルリクの元と先（自分の feature ブランチから develop ブランチ）をちゃんと確認してから「create pull request」を押してプルリクしましょう。プルリクした場合、基本的には自分じゃないメンバーにコードをチェックしてもらって、develop へマージされるのがたぶん一般的なのではと思います。

   ＜プルリクの元と先は要チェック！！！＞
   この画面のような元先になるように注意してください！！
   

6. プルリクを出すと、Pull Request タブに 1 の数字が付きます（もちろん他にあればもっと大きい数字になります。）。このタブの中では、プルリクに含まれる変更履歴やコミットが確認できます。また、コードのレビューをして、プルリクをした人に伝えることもできます。ちなみに、下の画面のように、プルリクの元先もチェックできるので、チェックする側のときはこの辺も見た方が 👍 です。チェックをしたら、「Merge pull request」を押して「Confirm merge」を押して、develop へのマージは完了です。緑の Open というマークがあったのですが、紫の Merged に変わります。

   

7. Code タブで見ていただくと、「セカンドコミット」と index.html が更新されているのが確認できると思います。以上で作業は終了です。おつかれさまでした。

   

   開発は、＜シーン４＞を繰り返すことで develop が完成へ近づいていくという形になります。

おわりに

いかがでしたでしょうか。
冒頭に記載したように、僕はエンジニアではないので、不正確な部分があるかもしれません。

ただ、Git で迷子になっている駆け出しエンジニアの方々の Git 苦手。よくわからないが解消できれば、と思い作成したものです。

また、記事の内容について、確認等ありましたら、Zenn のアカウント情報に SNS アカウントを掲載していますので、ダイレクトメッセージなどでご連絡いただければ、ぼくの知識でわかる範囲でになりますが、可能な限りサポート等（ご希望とあらばオンラインでレクチャーも可能）をさせていただければと考えています。

最後に、ぼくのスキルで無償で誰かの役に立てたらと思い TEKU-PORT（https://tekuport.com）というサイトを運営しています。現在の僕のスキルや経歴、展開する無償サービスなどを掲載していますので、お越しいただければ幸いです。

ここまで、拝読いただいてありがとうございます。

読んでいただいた方の少しでもお力になれれば幸いです。