プログラムソースコード管理だけじゃない
GITの活用法
Gitを知ろう!
このセミナーは、GITは聞いたことあるけど、 使ったことない人に ちょっとだけ興味を持ってもらう事を 目的にしています。
GIT とは?
- みんなが自分のPCで履歴を持てる仕組み - ネットがなくても作業&履歴管理ができる仕組み
GITの歴史
Linuxの開発者の Linus Torvalds が、 2005年4月にわずか3日ほどで Gitの初期バージョン を書き上げた。
Linuxカーネルの開発で、 「BitKeeper」の ライセンス問題 が起きたため。
「git」はイギリスのスラングで 「嫌なやつ」「バカ」という意味もあり、 Linusが自分自身を指してそう名付けたとも言われている。
Linusは「私はクソ野郎(Bastard)で、 私の作るツールはクソ野郎向けのツール(gitのこと)だ」と 笑いながら言っていた。 つまり強力で便利だけど、最初は扱いが難しかった。
GITのヒント
GITは、エンジニアだけの道具ではありません。 あらゆる職種で、“変化するもの”や“共同作業”にかかわるなら、 誰でもその恩恵を受けることができます。
- ソースコードの管理とバグ修正の履歴追跡 - 機能追加ごとのブランチ運用で安全な開発 - チーム開発でのコンフリクト(衝突)解決やレビュー対応
- キャンペーン施策案や提案資料のバージョン管理 - 修正履歴を活用して「なぜこのアイデアになったか?」を遡れる - チームメンバーで資料を共同編集し、レビュー履歴を共有
- UIデザインやロゴ案など、デザインファイルの変更履歴管理 - バージョン違いの比較や、複数案の分岐管理に便利 - フィードバックを記録し、反映した修正の流れを可視化
- 原稿や記事の校正履歴を残せる - 編集前後の比較が簡単で、過去の表現にすぐ戻れる - 複数人での執筆プロジェクトでも、作業分担と統合がスムーズ
- 提案資料や価格表のバージョン管理(クライアント別など) - 修正日・修正者の記録が残るので、チーム間での認識齟齬を防げる - 過去にどんな資料を使ったかを履歴から確認可能
- 社内規定やマニュアルの履歴管理 - 全社配布文書を安心して更新・共有できる仕組み - 社内向けプロジェクトのドキュメントもGitで管理すれば一元化が可能
- 教材のバージョン管理・カリキュラムの履歴管理 - 複数人で作る研修資料のレビュー&編集履歴が残せる - 研修用リポジトリを配布して、受講者とやりとりすることも可能
事例紹介
担当者から相談を受けてページ改善をした内容の紹介。
Markdown言語を合わせて学習することで、テキストで資料作成などが簡易にできるようになった。
Markdownは、色々なメモ帳アプリなどでも使えるため、覚えていると通常の作業効率もアップします。
ちなみに、このセミナー資料もMarkdownのテキストで作成しています。
構成 : VScode + Marp(プラグイン) + Mermaid(図などの描画)+ 画像ファイル
バージョン管理の仕組み
Gitに出てくる用語
共有リポジトリと言われる場合もある。 他の開発者と変更を共有するために使用されます。 多くの開発組織は、 Githubをリモートリポジトリとして使っている。
各開発者は自分のパソコンに リポジトリの完全なコピーを持ちます。 これにより、インターネット接続がない状態でも 開発作業を進めることができます。
ファイルの変更内容を、履歴として保存する操作。 「ここまで作業した」という区切りを記録することで、 後から見返したり、元に戻すことができるようになります。 コミットには「変更内容のメモ(メッセージ)」をつけます。
ローカルリポジトリのコミット内容を リモートリポジトリに送信する操作。 チームメンバーと変更を共有するために使います。
リモートリポジトリから最新の変更を取得し、 ローカルリポジトリに取り込む操作。 他の人の作業内容を反映させたい時に使います。
別々のブランチで行われた変更を一つに統合する操作。 たとえば、機能追加用ブランチで作業した内容を メインブランチにまとめるときに使います。
複数のブランチで同じ部分が違う形で変更されたとき、 どちらを採用するか決められず、Gitが自動でマージできない状態。 手動で解決が必要になります。
リモートリポジトリの内容を、 自分のパソコンにまるごとコピーして ローカルリポジトリとして利用できるようにする操作。
特定のコミットに「ラベル(目印)」を付ける操作。 よく使われるのは、リリースバージョンの記録(例:v1.0.0)。 あとから「あの時点」をすぐに見つけるのに便利です。
A──B──C──D──E ↑ [v1.0.0]
コミットする前に、「このファイルを保存対象にする」と選ぶエリアのこと。 変更をいったん“控え室”に置くようなイメージです。 その後、`git commit` で履歴に残します。
あるブランチの変更履歴を、別のブランチの上に載せ替える操作。 ブランチの流れを直線的に整理したいときに使います。 ただし、使い方を間違えると履歴がぐちゃぐちゃになるため注意が必要です。
リベース前
main: A──B──C feature: └─ D──E
リベース後
main: A──B──C──D──E
開発の分岐を管理するための機能。 新しい機能開発やバグ修正のために、 メインの開発ラインから分岐して作業を進め、 後でメインラインにマージすることができま
無料で学習できるサイト
https://learngitbranching.js.org/
https://gitimmersion.com/
https://ohmygit.org/
GIT便利ツール
https://git.gaozih.com/
https://git-school.github.io/visualizing-git/
https://codesandbox.io/
ブラウザでコマンド操作
https://github.com/features/codespaces
学習サイト
公式のGit解説書のオンライン日本語版 https://git-scm.com/book/ja/v2
導入編
- GUI(アプリケーション)は、見た目でわかりやすい。 - CUI(コマンド)は、全ての機能が使える。
https://www.sourcetreeapp.com/
https://git-scm.com/downloads
基本操作
Githubのリポジトリ操作
このURLにアクセス
githubから、リポジトリをローカルに clone (コピー)する
git clone https://github.com/yugeta/sample
新規ファイルを追加 ファイルの内容を更新
git add . ← ドットを忘れずに git commit -m '修正作業'
git log
コマンドを実行して表示された文字を理解してみましょう。
NAS活用事例
NAS(Network Attached Server)に、 Gitサーバーがインストールできる機器があります。 - Synology - Qnap (うちの会社はコレ) - UGREEN (他にも色々あります・・・)
1. 会社(組織)内のみで管理できるので、情報漏洩の心配がない。 2. Githubは、容量制限や、各種セキュリティ制限があるが、 そうした制限が一切ない。 3. Actionsなどの機能が無料で使い放題。 (Actionsは、ホームページのオートデプロイなどで使う機能)
1. 社内や自宅に置いているため、電気代がかかる。 2. 設置作業や、保守管理などが自己責任。
1. NASのバックアップにGithubなどのクラウドサービスを使う。 2. 運用ルールはクラウドサービスに合わせる。 3. Actionsは、NASサーバーで行うことで、無駄な金額発生を防ぐ。 4. 外部会社との連携はGithubで行う。 (クラウドでは、publicとprivateを使い分ける) もちろん、Githubのみでの運用も問題ありません。
運用ルール例
- main ブランチのみで作業 - コミットメッセージは「何をしたか」が明確になるように記述 例:fix: ログイン時のバグ修正 - 毎日の作業終了後に git push - タグでバージョン管理(例:v0.9)
- main:リリース用ブランチ - dev:開発中の統合ブランチ - 個人作業ごとに feature/ ブランチで作業 例:feature/add-login - 完了後、dev にプルリクエスト(レビュー) - main へのマージは代表者のみ実施(週1など) ※プルリクエストは、Githubの機能です。
- main:常にデプロイ可能な状態を維持 - 作業ごとに feature/ ブランチを作成 - プルリクエストベースでレビュー&マージ - GitHub Actions等で自動テスト連携 - main へのマージ後、自動デプロイ(CI/CD)
- main:本番用(タグ付きでリリース管理) - develop:次リリース向けの統合開発ブランチ - feature/:新機能追加 - release/:リリース準備用ブランチ - hotfix/:本番での緊急修正 - 厳密なレビュー・CIテスト・承認フローあり
- main:本番用(タグ付きでリリース管理) - develop:次リリース向けの統合開発ブランチ - feature/:新機能追加 - release/:リリース準備用ブランチ - hotfix/:本番での緊急修正 - 厳密なレビュー・CIテスト・承認フローあり CIテストは、継続的自動テストの意味。
ブランチ構成 - main:公開状態のマニュアルや文書を置く - edit/○○:内容修正や更新ごとの作業ブランチ 例:edit/2025-rule-update ルール例 - 修正内容ごとに必ずブランチを分ける - プルリクエストでチーム内レビューを行ってから main へマージ - コミットメッセージは「何を変えたか」を簡潔に 例:fix: 入社手続きの説明文を更新
ブランチ構成 - main:最新の正式提案資料など - proposal/クライアント名:顧客別の資料バージョン 例:proposal/ABC-corp ルール例 - 資料提出前にレビューを行い、確認者がチェックしてからマージ - バージョン番号タグで、提出資料を明確に記録 例:v2025-07-05-ABC 推奨フォーマット - .pptx もGitで管理可能 (バイナリなのでdiffは取れないが履歴保存には使える)
ブランチ構成 - main:公開中のコンテンツ - draft/タイトル:記事や投稿の下書きブランチ 例:draft/ai-tool-review ルール例 - 下書きは1ブランチ1記事 - レビューを受けてから main にマージ、公開時にタグを付ける 例:tag: blog-2025-07-10 運用補足 - Markdown形式で書くと、差分も確認しやすく便利 - 画像は /assets/ などにまとめて管理
ブランチ構成 - main:最新の全社向け文書・規定集 - review/○○:修正案や監査用の修正ブランチ 例:review/契約書フォーマット改訂 ルール例 - 文章の修正は issue に起票してから対応 - 修正理由と背景をコミットメッセージに残す 例:refactor: 法改正に合わせて条文を更新 セキュリティ - クローズドなGitサーバー (GitHub EnterpriseやGitLab、NASなど)を活用
ブランチ構成 - main:最新の公開済み教材 - update/年度やテーマ:改訂用ブランチ 例:update/2025-spring-basic ルール例 - 研修終了後のフィードバックを元に内容を更新 - バージョンタグ付きで教材配布履歴を管理 例:v2.1-新人研修2025春 補足 - マークダウン教材とPDFをセットで管理することで、 編集と配布の両立が可能
- コミットメッセージの書き方統一 例:[fix] バグ修正 / [add] ログイン機能追加 - 禁止事項:mainに直接pushしない、force pushしない - レビュー体制:最低1人以上のレビューでマージ可能 - 命名ルール:feature/xxx, bugfix/xxx, hotfix/xxx
何を、なぜ、どのように変更したのかを明確にする チームメンバー間の認識齟齬をなくす あとで履歴を見ても「意味が通じる」ようにする
書き方の型(シンプル版)
php-template コピーする 編集する <種別>: <変更内容の要約> <b>例</b> fix: 誤字を修正 add: 新しい提案書テンプレートを追加 update: 2025年度の研修資料を最新版に更新
誰が見ても「何をしたか」がすぐに分かる レビューや調査がスムーズになる ドキュメントとしても役立つログが残る
アクセス権限について
- 間違った操作や意図しない変更からリポジトリを守る - チームメンバーの役割に応じて、安全かつ効率的な運用を実現 - 「誰が何をできるか」を明確にし、トラブルを未然に防ぐ
直接 push を禁止(強制) 誤操作による上書き防止 プルリクエスト(Merge Request)経由のみマージ可能 レビューを必須化 レビューア2人以上で承認 チームでの品質担保 CIテスト通過必須(開発用の場合)
main に push できるのは管理者・メンテナーのみ develop, feature/* は開発者もpush可 docs/ フォルダのみ編集可能なチーム(非エンジニア用)を作成可能
Git初心者には限定的な権限を付与(例:閲覧・編集のみ) docs用サブリポジトリを作って権限を分離 プルリクエスト時に説明テンプレートを用意 例:「何を、なぜ変更したか」「レビューしてほしいポイント」
リポジトリのオーナーが定期的にメンバーリストを確認 不要なアカウント・チームは速やかに削除または無効化 設定変更や削除操作のログ取得(GitHub Audit Log、GitLab Activityなど)
運用ポリシーをREADMEやCONTRIBUTING.mdに明記する Slackやメールと連携してPRの通知を飛ばす 週次でマージログやアクティビティをレビュー
教育研修の計画
Gitの基本概念と操作を習得し、 業務ドキュメントや資料を安全かつ効率的に管理できるようにする。 チームでの共同作業時に起こる「上書きミス」や「履歴の混乱」を防止する。 非エンジニア職にも使いやすいGit運用習慣を根付かせる。
オンライン演習: GitHub Codespaces、GitPod、または仮想PC環境 スライド教材 Marp形式やGoogle Slidesなど ハンズオン用の教材リポジトリ 例:sample-docs, training-branching チートシート Gitコマンド早見表
Gitの役割やメリットを説明できる 自分の作業をコミット・プッシュして履歴を残せる チームメンバーの変更をpullし、自分の作業と統合できる ブランチやレビューを使った共同作業の流れを理解できる
いきなりコマンド操作ではなく、「なぜ使うのか?」から始める GUIツール(GitHub Desktop / GitKraken など)を併用 ミスしても安心な「演習用リポジトリ」を事前に用意 ハンズオンの後に「実際の業務でどう使えるか」を結びつける
マニュアル更新プロジェクトでGit活用の実演 コミットメッセージやPRレビューのワークショップ 自社ルール化ドキュメント(CONTRIBUTING.md)の作成ワーク
抵抗勢力への対応策ほか
演習を通して、「自分の作業に使える」と実感させる 例:研修資料の修正履歴がきれいに残っている例を見せる
GitHub Desktop / Sourcetree / Visual Studio Codeなど 「コマンド覚えなくていいんだよ」と伝えるだけで安心感が生まれる
まずは一人で使う/ドキュメントだけで使うなど 成功体験を積んでもらい、他チームへ自然に波及
「現場がやれと言ってる」より「上の人がもう使ってる」が効く 管理職が使えば、評価基準にも組み込みやすくなる
研修用リポジトリは壊しても大丈夫な設計に revert や reset を教えておけば「戻せる安心感」になる
Git導入前後でのドキュメント履歴の比較例を提示 「こういう場面で助かる」という具体例を共有
「覚えることが多い」ではなく「やることが減る」と伝える ITっぽさよりも「文書の整理術」「編集の見える化」として紹介 「あなたのためのツールです」と寄り添った説明が◎
「コミットメッセージ大賞」などのゆるイベント Git用語かるた、Gitビンゴなどの学習ゲーム 導入初月は“Git相談役”を決めておく SlackやTeamsで「Gitの小ネタ」投稿を週1回
質疑応答
ご静聴ありがとうございました。
やりたいことから逆引き形式でコマンドを探せる
ブランチ・コミットの構造を視覚的に学べる
Gitを使った開発がそのままWebブラウザで体験できる環境
VSCode風で、学ぶより「触る」感覚