やってみる

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

GitHubアップローダにコミットメッセージとIssue登録を同時に行う機能を追加した

起動引数-mで1行分のメッセージを指定することで。

成果物

GitHubGitHub.Uploader.Issue.201706191032

コマンド例

$ python3 GitHubUploader.py -u some_user -m "タイトル"
$ python3 GitHubUploader.py -u some_user -m "タイトル" -m "本文1行目。" -m "本文2行目。"
  • 起動引数-mがある場合のみ、Issue登録とIssueを閉じるコミットメッセージを作って登録する
    • -mがない場合はこれまで同様、ターミナル入力し、コミットメッセージのみ
      • コミットメッセージの1つ目はfix #Issue番号 タイトルの書式になる。
  • 1つ目の-mの値をタイトルとする。2つ目以降を本文とする。

用途

commit単位とIssue単位を同一にさせることで、履歴管理を単純化させた。

このツールの方針

このツールは元々、gitコマンド init, add, commit, push のコマンドを隠蔽してある。また、WebAPIのリポジトリ生成をすることでWebサイト操作も省略できる。単純化させたために細かい制御ができない。「楽してアップロードできればいい」くらいの気持ちで使うツール。細かい履歴管理よりも、楽に記録や公開することを目的にしている。

1commit1issueの妥当性

今回はcommit単位とIssue単位を一本化した。本来ならcommitのほうがローカルで小さい単位のはずである。しかし、1つのcommitで1つのIssueをクローズできるメッセージの記法fix #Issue番号があることから、1commit1issueの対応付けができると判断した。

大規模なプロジェクトならcommitとIssueを使い分けたくなるはず。しかし、小規模であれば使う必要が無いか、使い分ける必要がない。使い分けたいようなプロジェクトの場合には不向きである。使い物にならないと断言する。

効果

1commitあたりの透明(公開)性があがる。

Issueをみればコミット履歴になる。コミット履歴はcommit logのようにしないと閲覧できないがIssueからも見れるようになる。

ただ、何も問題ないのにcommitするたびにIssueを作って閉じるのはどうかと思う。Issueの本分である「問題」が埋もれてしまいかねない。将来的にはラベルで使い分けるのが望ましいと思う。

Issuesのラベルを管理(編集)する方法 - 22時に寝ようと思って2時に寝る。

もしくはIssueは作らないがコミットメッセージは渡したものでcommitする、という選択肢も用意すべきかも知れない。

課題

  • Issueのラベルを設定したい
  • commitメッセージとIssueを分けたい(Issue側はMarkdownでも書けるから使い分けたい時もありそう)
  • Issueを取得し、保存したい
    • GitHubのコントリビュート(草)を作成するのに使えそう
      • Issueの取得と保存ができれば起動時にコントリビュート(草)の取得をせずに済む

所感

どんどんゆとり仕様になっていく。もうIssueの意味がないレベル。