30歳からのプログラミング

30歳無職から独学でプログラミングを開始した人間の記録。

GitのTagの使い方

今までGitでタグを使うことはなかったが、勤務先で使っているので、勉強。
Git自体の理解(特に考え方や概念に対する理解)がかなり怪しいので、最初はよく分からなかった。備忘録としてまとめておく。

そもそもタグとは何か

コミットのエイリアス、という認識でいいようだ。
コミットに対して分かりやすい名前を付けたのが、タグ。

つまり、コミットを指定して行う操作は、コミットの代わりにタグを指定してもいい。
例えばgit show コミットIDgit checkout -b ブランチの名前 コミットIDは、コミットIDの部分をタグの名前に置き換えても同じことが出来る。

基本的な操作

タグを打つ

$ git tag タグの名前 コミットID

コミットIDを省略した場合は、現在のブランチの最新のコミットに対して、タグが打たれる。

タグの一覧を見る

$ git tag

タグの内容を確認する

$ git show タグの名前


現在のブランチには存在しないタグであっても、問題なく見れる。
というが、タグには、ブランチという概念がない。
そもそもコミットにはブランチという概念がないのだと思う。
このあたりが、そもそもよく分かっていなかった。
hogeブランチのfugaコミット」が存在するのではなく、fugaコミットが独立して存在しており、それをhogeブランチが持っている、という解釈のほうが正しいのだと思う。正確な仕様はまた違うのだろうけど。

ブランチが関係してくるのは一部のケースだけであり、基本的には、タグを使う際はブランチは意識しなくていいのかもしれない。


タグを削除する

$ git tag -d タグの名前

タグの名前を変更する

$ git tag 新しいタグの名前 古いタグの名前
$ git tag -d 古いタグの名前

一つのコミットに対して複数のタグを打つことが出来る。
なので、変更後のタグを追加し、そのあとで古いタグを削除してしまえば、リネームできる。

タグをリモートリポジトリと共有する

タグは、通常のプッシュやプルでは、共有できない。

タグのプッシュ

以下のコマンドで、当該タグの情報をプッシュできる。

$ git push リモートリポジトリ タグの名前

全てのタグの情報をプッシュする場合はこのコマンド。

$ git push リモートリポジトリ --tags

タグのプル

$ git pull リモートリポジトリ --tags

リモートリポジトリのタグを削除

ローカルリポジトリでタグを削除した状態で$ git push リモートリポジトリ --tagsとしても、削除の情報は共有されない。
以下のコマンドで削除する必要がある。リネームによって古いタグを削除した場合も、当然行う必要がある。

$ git push リモートリポジトリ :削除したタグの名前

GitHubでの表示

他のホスティングサービスでも同様だと思うが、GitHubでコミットを見ると、タグの情報を確認できる。
以下のように、表示される。

コミットID(タグ) GitHubでの表示
1bacc28
8ef5ecf
ae548ed (4.0) 4.0
b8bdadb 4.0
f39a14a (3.0) 4.0 3.0
7bba876 4.0 3.0
0b2392a (2.0) 4.0 … 2.0
de1b3bf 4.0 … 2.0
5c173e8 (1.0) 4.0 … 1.0
dc5d009 4.0 … 1.0
d8df26c 4.0 … 1.0

コミットIDは、上に行くほど新しい。

基本的には上記の表のように表示されるが、正しく表示されないことがある。
試行錯誤した結果、GitHubで設定しているデフォルトブランチ、そのブランチに存在しないコミットについては、タグ情報は表示されない模様。
例えば、0b2392a2.0を打っているコミット)以降のコミットがデフォルトブランチに存在しない場合、それらのコミットのタグ情報は空白となる。
それより前のコミットについては、上記の表と全く同じように表示される。

簡単にTwitterAPIの認証を行えるnpmモジュールを公開した

TwitterAPIの認証を行うために必要な署名を、簡単に作成できる。
APIキーなどの必要な情報を渡せばエンドポイントとリクエストヘッダを返すので、それを使ってリクエストするだけで済む。

このモジュールを作成した目的

  • OSSの実践。その練習として。
    • 他人が使うことを前提としたコードを書く。コマンドやドキュメントの整備など。
  • npmモジュールの公開をやってみる。一通りの流れを一度経験しておきたかった。
  • GitHub Flowの導入。
  • Lintの実践。
  • テストの実践。

以上が、目的。
いずれも、達成できたと思う。

以前からOSSをやりたいとは思っていたが全然やれていなかった。何となく心理的なハードルがあったのかもしれない。
だが、職業プログラマにもなれたことだし、セキュリティが重要なものでない限りはどんどん外に出していこうと考えを改めた。
プログラマとして守るべき評判もプライドもないわけだし。

ということでOSSをやりたい気運が高まっていたのだが、ゼロから何か作るのは時間がかかる。
そこで、以前作ったTwitterクライアントの認証に関する部分を切り出し、ライブラリとして出そうと思った。
npmモジュールの公開も一度やっておきたかったから、丁度いい。

作業にあたっては、最近やっと経験したGitHub Flowを導入することにした。一人でやるからあまり関係ないのだが、トピックブランチを作ってプルリクエストを行って、というフローに慣れておいたほうがいい気がしたので、そうした。

ESLintの実践という意味もあった。
これも、以前からやらねばと思っていたし、勤務先でも使っているので、練習しておきたかった。
Airbnb JavaScript Style Guideを採用した。
最初は鬱陶しかったのだが、確かにこれに従うことで、コードが綺麗になるし、一貫性が生まれて整然とする。

せっかくライブラリを書くのだから、テストもしたかった。練習のいい機会だろうから。
今の自分なりに、ちゃんとしたテストを書けた気がする。
特に、非同期でも上手くテストするためにPromiseでラップしたのは、よかったと思う。
出来る人たちにとっては大したことではないだろうが、自分のなかで一つ、経験が増えたというか、幅が広がった感覚がある。

以前書いたコードの流用だからそれほど達成感はないのだが、最初の一歩は踏み出せたので、これからどんどんOSSをアウトプットしていきたい。