
「分析やノートブックは作れるけど、壊れない運用の“型”がない…」
「final_v3_fix2_LAST.xlsx地獄から抜け出して、レビューと自動化まで一気通貫で回したい!」
この記事では、未経験〜初学者が週10時間×1〜2週で、Gitの基本 → GitHub Flow → PR/レビュー → Issue運用 → タグ/リリース → GitHub Actions(最小CI)までを、“現場でそのまま使える”テンプレとチェックリストで網羅します。
Notebook運用の地雷回避(出力クリア/差分)や.gitignore雛形、PR/IssueテンプレもコピペOKで配布します。
この記事で身に付く力
-
main保護+PR必須+小さなコミットという“壊れない型”
-
再現できるフォルダ構成と
.gitignoreの雛形(ノートブック運用の地雷回避付き) -
レビューとIssueの回し方(PR/Issueテンプレをコピペで導入)
-
タグ/リリースと最小CI(GitHub Actionsひな形で“配布前に壊れない”を担保)
はじめに:現場で起きる“Git不在”の悲劇
「final_v3_fix2_LAST.xlsx」だらけ/履歴が消えるZIP共有/本番ブランチへ直コミット→全員の作業が停止。
解決策はシンプル:GitHub Flow(main保護+PR運用)をベースに、小さく作ってレビューし、自動チェックを通してからマージする。
本記事では、週10時間×1〜2週でここまで到達することを想定して、必要最小限に絞って解説します。
セットアップ:最初に一度だけの設定
# あなたの名前とメール(コミット作者として記録されます)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
#新規リポジトリのデフォルトブランチ名をmainにする
git config --global init.defaultBranch main
# 改行コードの自動変換設定(Windows混乱の軽減)
# Windows: autocrlf=true でもOK。Mac/Linuxは基本 input で十分。
git config --global core.autocrlf input
# 差分やログをカラー表示で見やすく
git config --global color.ui auto
✅ ポイント:--globalは“PC全体の既定値”です。
プロジェクトごとに変えたい場合は、--globalを外して、リポジトリ直下で実行してください。
プロジェクト雛形と .gitignore(コピペOK)
「何を追跡し、何を追跡しないか」を最初に決めると事故が激減します。
project/
├─ data/
│ ├─ raw/ # 受領データ(非追跡にすることが多い)
│ └─ warehouse/ # SQLiteなど(非追跡)
├─ notebooks/
├─ src/
├─ reports/ # 図/Excel/PDF(必要に応じ非追跡)
├─ tests/
├─ .gitignore
├─ requirements.txt
└─ README.md
# Python
__pycache__/
*.pyc
.venv/
.env
# Data / Outputs
/data/*
!/data/README.md
/reports/*
!/reports/README.md
*.sqlite
# Jupyter
.ipynb_checkpoints/
# OS/editor
.DS_Store
Thumbs.db
原則:生データ/DB/大きな成果物は追跡しません(入手手順はREADMEへ)。
空フォルダはREADME.mdや.gitkeepで保持しましょう。
最初のコミットとメッセージ規約
cd project
git init
echo "# プロジェクト名" > README.md
git add .
git commit -m "feat: 初期雛形を追加 (構成/ignore/README)"
コミットメッセージの型(Conventional Commits簡易版)
feat:機能追加、fix:バグ修正、docs:ドキュメント、refactor:仕様不変の整理、chore:付帯作業- 1行目は50文字程度で要約。詳細が必要なら空行を挟んで背景や影響範囲を書きます。
GitHub接続とmain保護(PR必須化)
# GitHubで空のリポジトリ(project名)を作成後に接続
git remote add origin https://github.com/yourname/project.git
git branch -M main
git push -u origin main
GitHubのSettings → Branchesでmainを保護しましょう。:直接push禁止/PR必須/レビュー1名以上/ステータスチェック必須。
これで“壊れた状態がmainに混ざる”事故をほぼ防げます。
GitHub Flow:小さく作って小さくレビュー
原則は5つ
- mainはいつでも配布可能(常に動く)
- 作業はトピックブランチで
- 少し進んだらドラフトPRを作る(早めに見える化)
- レビュー→CI通過→マージの順
- 配布時はタグを打つ
# 新機能用のブランチを切る
git switch -c feat/monthly-report
# 変更→テスト→コミット
git add -p
git commit -m "feat: 月次集計のSQLとNotebookを追加"
# GitHubへプッシュ
git push -u origin feat/monthly-report
✅ ベストプラクティス:コミットは“意味の塊”で小さく。レビューが速く、コンフリクト時の切り戻しも安全です。
日常で強いコマンド(小技集)
git status # 今の状態を確認
git diff # 差分(変更点)を確認
git add -p # 変更を対話的に選んで追加
git commit --amend # 直前コミットを上書き(未push時のみ)
git stash && git switch main # 作業を一時退避してmainへ
git log --oneline --graph --decorate --all # 履歴を図で把握
マージとリベースの使い分け
基本はマージ(PRでMerge commit or Squash)。履歴の追跡が簡単です。
リベースは“自分の作業ブランチをmainへ追随”するためのローカル整理に限定。
# 自分のブランチにmainの変更を取り込みたいとき
git switch feat/monthly-report
git fetch origin
git rebase origin/main
# コンフリクト解消→テスト後に、リモート履歴を置き換える(自分のブランチだけ!)
git push --force-with-lease
⚠️ 注意:共有済みブランチへのrebase/--forceは厳禁。履歴が消えて同僚の作業が壊れます。
Notebookの“事故らない”運用(現場メモつき)
3つのポイント
- 出力をクリアしてコミット(サイズ削減&差分が読める)
- 図はファイル保存(
reports/)にし、Notebookはパスだけを記録 - 前処理は関数化して
src/へ(Notebookは実験・説明に専念)
差分可視化にはnbdimeやGitHubのNotebook Diffが便利です。
出力クリアの自動化(フック例)
# .git/hooks/pre-commit(chmod +x で実行権限を付与)
#!/usr/bin/env bash
find . -name "*.ipynb" -print0 | \
xargs -0 -I {} jupyter nbconvert \
--ClearOutputPreprocessor.enabled=True --inplace {}
ふみとの現場メモ
現場メモ:まずは「出力クリア」だけでもレビュー効率が段違い。
画像出力をNotebook外に逃がすと、バージョンの食い違い事故も激減します。
PR(Pull Request)とレビューの型(テンプレ配布)
PRは小さく/短く(目安:〜200行)。依頼前にセルフレビューで誤字・不要ファイルを除去。
目的→差分→動作確認の3点セットを明記します。
PRテンプレ(コピペOK)
## 目的
- 例:月次集計と図を追加し、Excel出力まで自動化
## 変更点(Before/After)
* SQL: WITH monthly を追加
* report.py: ExcelWriter で Summary タブ出力
## 動作確認
* `python src/report.py` で report.xlsx が生成される
## 影響範囲
* なし(新規追加のみ)
Issue運用(軽量スクラム)
Issue=タスクの単位。ラベル(bug/feat/docs…)とマイルストーンで整理。
Projectsで**ToDo → In progress → Review → Done**の流れを可視化。
Issueテンプレ(最小)
### 概要
### ゴール(受け入れ条件)
### 参考
タグとリリース(配布の節目を明確に)
# mainを最新化
git switch main && git pull
# 意味のある節目にタグを打つ
git tag -a v0.1.0 -m "初回リリース: 月次集計+Excel出力"
git push origin v0.1.0
セマンティックバージョニング(最短メモ)
- MAJOR:互換性破壊
- MINOR:後方互換の機能追加
- PATCH:後方互換の修正
リリースノート(GitHub Releases)に「何が変わったか」を短く残すと運用が楽になります。
最小のCI(GitHub Actions)で“壊れない”を担保
まずは落ちない仕組みから。段階的に整えていきます。
name: ci
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: { python-version: '3.11' }
- run: pip install -r requirements.txt || true
- run: python -m pip install pytest
- run: pytest -q || echo "tests not found; skipping"
最初は落ちない仕組みから。のちにflake8/black/ruffやNotebook出力クリア検査を追加すればOK。
セキュリティと秘匿情報の扱い
.envやAPIキーはコミットしない(.gitignoreに必ず追加)。- Actionsで使う資格情報は**
Secretsに保存**して参照。 - 誤コミットしたら:履歴から除去(
git filter-repoなど)+即時キー再発行。
読者タイプ別:最短導入プラン(3タイプ)
- 社会人(転職):GitHub Flow+PRテンプレ+CIを最短導入。READMEに再現手順を明記し、10分LTに“運用”を一枚追加。
>>【保存版】データ職のポートフォリオ完全ガイド|再現性・評価・LTまで - 副業(稼ぎたい):Excel納品PJにタグ/リリースを導入し、版管理と修正履歴を明瞭化。
>>【保存版】データレポート納品の型:要件定義→ETL→検証→可視化→Excel/PDF→引き継ぎまで、失注しないワークフロー完全版 - 主婦/夫(在宅):小さいPRを毎日。Notebook出力クリアと.gitignoreから着手。
>>【保存版】在宅×Python:子育てと両立する“1日1時間学習術”忙しくても伸びる最短メニューと運用の型
付録A:よく使うコマンド早見表
# ブランチ
git switch -c feat/foo # 作成+切替
git switch main # 切替
# 差分/取り消し
git diff # 差分
git restore --staged file # ステージ解除
git restore file # 変更取り消し
# 追跡をやめる(ファイルは残す)
git rm --cached path/to/file
付録B:READMEテンプレ(最小)
# プロジェクト名
目的:誰の、どの意思決定を支援するか(1文)
再現手順:
1) python -m venv .venv && source .venv/bin/activate
2) pip install -r requirements.txt
3) python src/report.py # Excel/図を出力
データ:data/raw/ 以下に配置(入手方法を記載)
付録C:トラブルシュートQ&A
Q. 誤って巨大ファイルをコミット → git rm --cachedで追跡解除→.gitignoreへ→新規クローン推奨。
Q. コンフリクトが怖い → 小さいPRとこまめなpull、git add -pで意味の塊を丁寧に。
Q. Notebook差分が読めない → 出力クリア+図はファイル保存で可読性UP。
この記事から次に読むべきもの(内部リンク)
-
-
【保存版】Jupyter Notebookの基本:環境構築・使い方・再現性・“読みやすいノート”設計まで完全ガイド
Jupyter Notebook は 学習・検証・共有 に最強のツールです。ただし設計を誤ると、 本ガイドは、未経験〜初学者でも 週10時間×1〜2週 で、 環境構築 → 基本操作 → マジックコマン ...
-
-
【保存版】SQLite×Pythonで作る“ローカルDWH”|ETL・集計・レポート自動化の最短手順
ローカルでゼロ構築、ファイル1つで完結、サーバ不要。 本記事はSQLite×Pythonで“毎日回る”ETL・集計・レポート自動化を最短で作るための完全ガイドです。データ設計→DB作成→ETL(取り込 ...
-
-
【保存版】データレポート納品の型:要件定義→ETL→検証→可視化→Excel/PDF→引き継ぎまで、失注しないワークフロー完全版
“いい分析”より“伝わる納品”。副業や実務で評価されるのは、意思決定に効く1枚と再現できるパッケージを期限通り出せること。 本記事は、未経験〜初学者が 週10時間×2〜3週 で、要件定義 → データ受 ...
-
-
【保存版】データ職のポートフォリオ完全ガイド|再現性・評価・LTまで
ポートフォリオって「作ったものの置き場」でしょ? いいえ。採用側が見たいのは「意思決定に効いた証拠」と「再現性」です。 本ガイドは、未経験〜初学者が週10時間×4〜6週で、テーマ選定→要件定義→データ ...
-
-
【コピペOK】pytestで“壊れないPython”を作る12ステップ
「昨日は動いてたのに、今日は壊れた…」 データ分析やETL、機械学習のコードで多発するこの悲劇。実は“テスト不在”が9割です。 本記事は、pytestで“壊れないPython”を作るための実務ガイドで ...
伴走のご提案(任意)
Gitを押さえると、在宅×副業でも毎月回るレポートやML実験が安全に進みます。短期でブランチ運用→PR→CIまで整えるなら、質問対応とレビューのあるスクールが近道。
TechAcademy データサイエンスコース(受講料:174,600円~ ※更に割引あり)

株式会社キカガク AI人材長期育成コース(受講料:237,600円~)

最近のコメント