やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

GitPythonの情報ざっくりまとめ

GitPythonについて簡単に調べてみた。

方針

前回

公式

参考

調査の要点

  • GitHubアップローダで使うコマンドを網羅する
    • GitPythonで置き換えられるか調査する
  • gitコマンドでのエラーを例外として発生させているか確認する
    • 例外発生するならGitPythonで置き換える

gitで行った活動を管理する

  • コントリビューション作成について考える
    • コントリビュートに該当するアクションを網羅する
      • アクションごとに記録すべきデータを網羅する
        • DBとテーブルを作成する
          • マスターテーブルを作成する
            • 固定レコードを作成する
    • GitHubアップローダで対象とするアクションを網羅する(おそらく以下)
      • repository
        • create
        • delete
        • modify
        • commit
      • issue
        • create
        • comment
    • GitHubアップローダで対象アクションの度にコントリビュートのひとつとしてDBに記録する
    • SVG作成する

実装コスト膨大

とくにコントリビューションのデータをアクション別データに記録するところが大変。

現状のまま単なる数値なら楽。その集計値もGitHubにおまかせなので楽。それらの自前実装はかなり大変そう。現実的でない。

gitアクションはGitHubではEventTypesと言っているのだと思う。こんなものに手を出したらいつまでたっても実装が終わらないだろう。

対象アクションは何か

GitHubSVGには「A summary of pull requests, issues opened, and commits to the default and gh-pages branches.」とあった。おそらく以下のものを作ったときにカウントされるのだろう。

  • pull requests
  • issues
  • commits
  • branches

効果大

「誰が、いつ、どのリポジトリに対して、何を行ったか」を明かにできる。

GitHubのユーザページにある草グラフそのもの。活動を俯瞰し、マウスオーバーで具体的なアクションへのリンクを出せる。commitならソースコードが出せる。issueならissueを表示できる。

ここまできたらGitHubにおける個人活動の記録と監視についてはほぼ完璧と言える。理想的だが、実装が大変すぎて無理。GitHubサイトでやるのが一番早いが、最近1年間分しかできないのが残念。

所感

GitPythonの調査までを当面の目標とする。gitコマンドでエラー時に例外発生してくれるなら、GitPythonに置き換える価値があると判断できる。CUIコマンド化へのメドが立つ。