今だからこそイチから始めるgithubの基礎
AIがサクッとコードを書いてくれるようになり、様々なエンジニアのバックグラウンドのない方達がコードを書けるようになりました。
しかし、それゆえの危険性もあります。
今回はそんなことを日々色々感じる中で gitについてとりあげようと思います。
そもそもgitとは
gitとはバージョン管理システムである
gitとはバージョン管理システムです。
commitという単位で変更を記録していきます。
このようにcommitの全てはcommit履歴として保持され「いつ・誰が・どのような」変更を行なったか明確に記録されています。
branch
branchはこのcommit履歴を分岐させるものです。
新しい機能Aと新しい機能B、バグの修正、リリース前の調整、それぞれを同時に開発することが難しいケースがあります。
バージョン管理のいいところ
このバージョン管理によって何が嬉しいのでしょうか？
以下のようなメリットがあります。
復旧可能である
まずシステムに追加の開発を行なっていくと少なからずバグ・障害が発生します。
コードをgit管理しておくことによって特定のタイミングに戻ることができます。
このタイミング=commitであるため、commitをどれだけ細かく分割するかは大事なポイントです。
このcommitに対してもプラクティスがあり、下記の記事など参考になります。
変更の意図を把握できる
こちら当たり前ではありますが、重要なことです。特に昨今RPA・ノーコード・ローコードツールが普及した中、ツールの中にはバージョン管理を行わないツールもあります。
そんな中でgitはシステム開発のログを差分や意図とともに残していくことができます。
commitのベストプラクティス
上記の復旧可能であり変更の意図を把握できる、そして後述する共同開発のためにおいては"良い"commitが必要となります。検索するといくつか出てきますので参考にしてみてください。一つの記事を下記に記載し、一部抜粋してみます。
-
Atomic and focused: 原子性&集中されている。つまりはあれこれ一つにまとめないということです。"認証の追加とデザインの変更"ではなく、これらを二つに分けて"認証の追加"と"デザインの変更"という二つのcommitに分けます。
-
Descriptive Commit Message: 説明的なcommitメッセージ。"バグの修正"ではなく"ユーザログインにおける null pointer例外処理の修正"と詳細に説明します。
また、さらに話が -
コミット頻度：小さすぎず、大きすぎず。1コミット＝意味のある変更にする。関係ない変更は混ぜない。
-
メッセージ：何を、なぜ変更したかが分かるように明確に書く。
-
ブランチ活用：新機能・バグ修正・実験はブランチを切り、プルリクでレビュー＆マージ。
-
コミット整理：マージ前に細かい修正をまとめて履歴をきれいに。
-
自動テスト：CIでコミットごとにテストを回し、バグ混入を防ぐ。
-
Husky：ルール違反コミットを防止し、品質維持に役立つ。
共同作業が可能
その前に少しgitとgithubの違い
ここから少しgithubの話に入っていきます。エンジニアが git と口にする時、githubの話をしていたりしますが、gitとgithubは別物です。 git自体は分散型バージョン管理システムです。
githubは このgit repositoryをクラウド上にホスティングできるサービスの一つです。（他にもgitLabや、Azure, AWS等も同等のサービスを持っていたりします。）
このサービスがあることによって、共同開発がより進めやすくなります。
(git単体でも共同作業は可能です。。。が私は github等を使わずに共同作業したことはありません。）
gitで共同開発, branch, pull request
共同開発するためのツールはgit, githubそれぞれにたくさんありますが、基礎であり中心であるのはpull requestです。
pull requestは システムのコードを分岐させ、開発した内容をもとの本流へ返す、その時にレビューを依頼しフィードバックおよび承認を得る作業です。
以下の画面は pull requestの一例です。
自身の変更の意図、変更箇所が明確にわかります。
レビューアーは気になる点があれば指摘し、問題がなければ承認します。
このチェック体制や洗練の工程を挟むことによって、システムはより良いものへ発展します。
pull requestで気をつけること
pull requestはコミュニケーションの一つです。
特に「指摘」という性質を持つため人を傷つける可能性もあります。
そのため躊躇したり言い出せなかったり、細かいコードの至らなさを無視していってしまうと、結果として負債が出来上がってしまうこともあります。
pull requestで気をつけるべきことはいろんな素晴らしい記事がありますので、ぜひ検索してみてください。
gitに保存するべきものすべきでないもの
結論からいうと画像や csv等は gitに保存するものではありません。
(画像についてはちょっと諸事情で例外あるのですが、「データ」を保存する場所ではないのです）
昔のエンジニアの先輩の言葉に「システム(障害)はコードかデータ、あとたまにインフラ」と言われたことを思い出します。
（この言葉はエンジニアとして8年経った今でもよく意識します。）
ではgitに戻ると、gitで管理しているのはまさにコード＝ロジックの部分なのです。
保存すべきはロジック（コード）
gitはロジック、仕組みの部分を保存しています。
至極当たり前のことではありますが、この主張を裏付けるため、逆説的になぜデータを保存しないかいかに述べていきます。
データを保存してはいけない。
まずデータとはなんでしょうか？csv、エクセル、画像、音声、動画、パスワード、トークン、これら全てをここでデータと呼ぼうと思います。
csv等
まずcsv等のデータは別で分離するべきです。後述する点と被るのですがセキュアなデータがgitに乗るのも論外です。
また、それらのデータに変更があるたびにcommit履歴に参照される、これもナンセンスです。
データ量も多ければ多いほど論外です。git自体がそれに対応するように作られていません。
こういうものはデータベースであったりファイルストレージで分割して管理されるべきです。
データにはデータの守るべき規則（データ型、主キー制約）もあれば、画像にも共通しますが、求められる別の利便性もあるかもしれません（圧縮、データライフサイクルの適用）。
ただし、一部テストコードとして利用しているものや、configファイルに相当するものを保存しておく例外は存在します。
画像
画像もほぼ上記と同様です。
最近はREADMEを綺麗にしたり、あとはgithub pagesのような静的ページを作るような例外もあります。
パスワード
パスワードは当然ながら全く別の管理を求められます。高い機密性が必要であり正しい認証を持ってアクセスされるべきデータです。
パスワードは性質次第ですが、見つかった瞬間に悪用可能なものもあります。
公開してしまうと数分以内にアクセスされ、そのまま数分以内に悪用されるというデータが存在します。
It takes hackers 1 minute to find and abuse credentials exposed on GitHub
なんと GitHub では公開後わずか2分以内 に、 NPMJS では1分以内 にカナリアトークンへのアクセスが確認されたのです。悪意のあるボットは、常に新たなコードを監視し、機密情報を探し求めているということが、この実験で如実に示されました。
個人的にはprivate repositoryだから、organization accountの範囲内だからOKということはもっての他で死んでもパスワードはgit上にあげないでほしいです。
（とか言いながらたまにミスってtokenあげちゃったことは何度かあります・・・）
もう一回：保存すべきはロジック（コード）
上記の理由からgit上にデータを管理してはいけません。
途中サラッと書きましたがデータをgitで変更するとcommit履歴に残ることも強く意識してください。
それらが許容できる、または応用できるのであればそれらも可能です。
ただし、闇雲同じリポジトリ上に存在させているものを何でもgit管理しようとしてはいけません。
そういうものは gitignoreで除外して、システムのロジックを保存していきましょう。
ここまではgitの基礎のなかでも頻繁に使うものを、8:2の法則でいえば8の時間を締めるよく使う2の技をお伝えしてきました。
しかしgithubではもっともっと、書ききれないくらいの機能がたくさんあります。
その中でも上記のお話の次くらいに大事だと思うものをいくつか書いていこうと思います。
githubをより活用する
README書こうね
READMEはコードの説明書のようなものです。一定フォーマットはあるものの、こう書くべきという絶対的なスタンダードは無い（はず）です。
昔はバグや障害があったら「コードを読め」とか言われましたが、そういう組織・システムに限ってクソ難読なコードもあります。
READMEなんてあるに越したことはありません。
特に昨今AI駆動開発な時代ですし、AIにとっての可読性を高め仕様駆動な開発が期待できますし、逆にコードを書いてから勝手に生成してくれる形も取れます。
ぜひ書いていきましょう。
github issue
タスク管理・チケット起票みたいなものです。
以下の画像はnumpyの例ですが、ズラーっとバグ修正であり、改善要望が上がっています。
担当者をつけたりProjectの分類など基本的な機能があります。
最近はgithub copilotでコードを参照しながらissueも書けるようになり、よりよい課題提起もできるようになっています。
github actions
個人的にはかなり活用しているgithub actions、間違いなくCICDの中心の一つと言える機能だと思います。
これはgithub上で発生したイベントをもとに特定の処理を実行することできます。
詳細はドキュメントにはありますが、よくある一番便利なケースでいえば
- pull requestと同時にコードをフォーマットする
- main branchに mergeされると共に、本番のコンテナをデプロイする
- remote pushと同時に 自動テストを走らせる
- Teamsへの通知
上記４点が私がよく使うケースです。
探してみるといろんなテンプレートもありますし、ぜひ検索して使ってみてください。
github copilot
github copilotはまさに今のgithub上での開発の目玉であると考えています。
これはVS Code上などで動く copilotの 会話・Agent機能もそうですし、githubのweb上のconsoleで動く copilotなどもそうです。
今最も使っている機能としては「pull requestの copilotによる review」「pull requestおよびissue」です。
私自身はまだ使い始めですが、今後github自身がこちらに力を入れていくことは間違い無いと思っています。最近の2025年のAOAIの「エージェントファーストな開発環境 - GitHubプラットフォームの進化と展望」という発表からも「AIをチームに入れる」という強いメッセージからも感じとりました。
どんどんAI*code*githubというプラットフォームの三つが混ざり合ってより良い開発体験・開発環境に到達すると信じています。
参考書籍・リンク
サル先生のGit入門
新卒の時、社内研修でこれを勉強しておいてと言われました。commitとかbranchの基礎はこれを見ればいいと思います。
numpyのgithub
実際のgithubの活用を見たければ自分の好きな・使っているライブラリのrepositoryを見ればいいと思います。私が新卒の頃の上司は何故か（いまだに何故かしっかり聞けていないのですが）numpyを見ておけとよく言われました (Pythonに限る)
男は黙って公式ドキュメント
まずは基礎を学ぶ上で大事なのは、可能であれば公式ドキュメントを推奨しますが、特にベストプラクティスの観点でもgithubは結構まとめています。
まずはここからスタートしましょう。
Git と GitHub の学習リソース
github公式の学習コンテンツ集、時間のある人は。
個人的な意見ですがあまり何冊も書籍を購入して学ぶ領域では無い気がします。
検索して上位に出てくる書籍はどれも名著な感じがするので一冊あればきっと大丈夫で、あとはひたすらチームで触ってみるのが良いと思います。
きっと人数が多いほどいい経験になると思います。
1人でも色々学べますし、1人開発だろうとコードの規模によってはほぼ必須ですが、もし可能であればぜひgitを通してチーム開発を早いうちに体験できた方が良いです。
よいgit lifeを。
Discussion