前職でシステムエンジニアをやっていたころに、TortoiseSVNというバージョン管理システムを使ったことがあります。そして、退職したのち、「GitHubは使えるようになったほうがいい」という情報を知って、アカウントを作りました。
が、結局よく使うことはありませんでした。
時間が経つと忘れてしまうことが多くなってきます。これから、ブログでコードの数が増えていくと思うので、ここらでGitHubについての学習をしていきたいと思います。
"なんちゃってプログラマ"の略でなんグラマです。プログラムを書いたり、ガジェットを紹介したりします。
・お問い合わせ
・プライバシーポリシー
バージョン管理とは
基本に立ち返って「そもそもバージョン管理って何？」というところから調べました。
バージョン管理とは、主に以下です。
- ある時点のコードをバージョンごとに記録する
- いつでも過去のバージョンに戻すことができる
人間は過去に行ったことを忘れてしまいます。
バージョン管理をしていないと、現在のバージョンでトラブルが起きた時に「いったん前のバージョンに戻そう」ということが難しくなってしまうのです。
Gitとは
バージョン管理システムの一つで、開発者のローカル環境で履歴を保持するためオフラインでも利用が可能です。
主に以下のことができます。
バージョン管理
ファイルやソースコードの変更履歴を時系列で記録する。任意の時点に戻すことが簡単にできる。
ブランチ管理
まず、ブランチとはあるバージョンからコピーして別の道を作ったものです。
別の道を作ることを「ブランチを切る」と言います。
ブランチを切ることで、mai（本線）と並行して別の作業を行えるます。作業が終わったら、マージします。
マージ
異なるブランチで行った変更を一つに統合する。
GitHubとは
Gitの仕組みを利用した、開発者のためのWebサービス。クラウド上でGitを用いたバージョン管理ができます。
ローカル環境で作成したコードを、GitHubにアップする（プッシュする）ことで他の開発者とコードの共有ができます。
ひとまず、ここでは以下の2つの機能を覚えることにしました。
issue（イシュー）
リポジトリにあるバグやタスクを取り出して、「誰が」「何を」「いつまでに」するのかを可視化することができます。
issueを作成した時は、通常issueに対するブランチを切ります。
Pull Request（プルリクエスト）
ブランチ上で行った変更をmain（本線）にマージするためのリクエスト。
コードレビューの後、マージする。
【なぜissueとPull Requestを最初に覚えたのか？】
実際のシステム開発では、バグや実装したい機能ごとにスケジュールや人員が割り当てられます。
これは、GitHubでいうところのissueにあたります。そのため、まずはissueを覚えることにしました。
そして、issueごとにコードレビューが行われマージされます。この流れの初期段階がPull Requestにあたるため覚えることにしました。
リポジトリとは
リポジトリとは、バージョン管理システムで管理しているファイル、その変更履歴の一式を記録している"箱"のようなものです。
ローカルリポジトリ
ローカル環境で作業するリポジトリ。自分だけの作業環境で、こまめに変更を記録していくことが一般的。
ローカルリポジトリに変更を記録することをコミットという。
リモートリポジトリ
GitHubなどのネットワーク上にあるリポジトリ。自分だけでなく複数人で履歴を共有するためのもの。
ローカル環境で蓄積されたコミットを記録する。
ローカル環境でのコミットを、リモートリポジトリに記録することをプッシュという。
GitHubを使った開発フロー
この記事のまとめとして、GitHubを使った実際の開発フローのイメージを書いていきます。
①GitHub上でissueを登録する
バグが発生したり、機能を追加したりする際に、まず「何を」「誰が」「いつまでに」やるのかをissueとして記録する。
②ローカル環境を最新化する
GitHubのmainブランチをpullする。
③ローカル環境でブランチを切る
issueに紐づくブランチをmain（本線）から分岐させて作成する。issueに対する作業を、このブランチで行う。
④実装→テスト→コミット
テストまで終了したら、コミットをする。
⑤リモートにpushする
ローカル環境のブランチのコミットをリモートへpushする。
⑥プルリクエストを出す
プルリクエストを作成して、レビュー依頼を出す。
⑦マージする
レビューが終了したら、作業したブランチをmainブランチにマージする。
⑧クローズする
対応が完了したissueをクローズして終了。
