Gitはバージョン管理規格にタグを演奏します
序文
この記事では、シーンVCS（バージョン管理システム）を行うために使用Gitのためのものです。
その分散アーキテクチャがもたらすように、Gitのプログラム猿を使用commit喜びを。コードは、私は非常に神経質得紛争にする必要があり、それぞれがコードをコミットし、この集中管理システムのSVNバージョンを使用するようにしないでください。
頻繁commit背後に、結果が密集から提出されたレコードの長いリストをもたらすことです。
プロジェクトが問題になると、問題は、ノードのコードをチェックする必要がある、少し頭痛になります。
ありますcommit messageが、不明瞭な記述を見つけ、問題の難易度はまだあります。
この記事の焦点は、Gitののタグ付け機能を介して行われgit tag、この問題を解決するために、および（セマンティックバージョン管理仕様）SemVerの名札付き仕様。
まず、タグ付け
役割をタグ付けすると、プロジェクトのノードに加え、セマンティック名、エイリアスの機能バージョンを開発することです。
付帯情報の書き込み中に、あなたは簡単に戻って、将来の保守プロセスを予測し、確認することができます名前タグを付けます。
また、ラベルはまた、現在のプロジェクト下位互換性、および反復修正APIの概要を記録することができます。
1.1タグ付けコマンド
再生するために推奨されるとの情報をメモしてラベルので、あなたは、変更の状況のラベルのバージョンを確認最大限に高めることができます。
// 命令格式
git tag -a 标签名 -m "附注信息"
// 示例
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"栗の場合1.2
出版物を待っているアンソロジー、そこにある
a、b、c、d4つ。
今ではGitの管理の進捗状況。
1. 2つの後commit添加する操作、a.txtおよびb.txtコードを変更するために、後は、リモートリポジトリを押します。
ウェアハウス・スキーマ次のように：
master -> * 添加b.txt
|
* 添加a.txt
|
* 初始化2. 気分を残す方法で、ラベルを作るために、現在のコーパスへ
// 打标签
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"
// push 标签到远程仓库 git push origin v0.1.0ウェアハウス・スキーマ次のように：
master v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化3. 2つの後にcommit追加の操作、c.txtおよびd.txtコードを変更するために、後でリモートリポジトリを押します。
ウェアハウス・スキーマ次のように：
master -> * 添加d.txt
|
* 添加c.txt
|
v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化4. アンソロジーは、ラベルのバージョンを作るために、最後に終了しました
// 打标签
git tag -a v1.0.0 -m "文集完成，共4篇文章，等出版。"
// push 标签到远程仓库 git push origin v1.0.0ウェアハウス・スキーマ次のように：
master v1.0.0 -> * 添加d.txt
|
* 添加c.txt
|
v0.1.0 -> * 添加b.txt
|
* 添加a.txt
|
* 初始化5.一定の期間の後、私はアンソロジーを知りたいv0.1.0ような状況のバージョン
// 输出v0.1.0的详情
git show v0.1.0
// 输出结果
tag v0.1.0 Tagger: wall <582104384@qq.com> Date: Wed May 23 15:57:13 2018 +0800 完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！ commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall <582104384@qq.com> Date: Wed May 23 15:27:10 2018 +0800 添加b.txt diff --git a/src/b.txt b/src/b.txt new file mode 100644 index 0000000..f9ee20e --- /dev/null +++ b/src/b.txtここでは、コンテンツや情報ノートの時間タグ付けをはっきりと見ることができます。
変更を確認するためにハッシュ文字列によって表されるバージョン番号を必要としない別の便利な点は、あります。
ここでは、バージョン番号を持つクエリの結果は以下のとおりです。
// 用版本号查看
git show 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6
// 输出结果
commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall <[email protected]> Date: Wed May 23 15:27:10 2018 +0800 添加b.txt diff --git a/src/b.txt b/src/b.txt new file mode 100644 index 0000000..f9ee20e --- /dev/null +++ b/src/b.txt @@ -0,0 +1 @@ +This is B. \ No newline at end of file1.3まとめ長所と短所
- 覚えにくい非友好的なバージョン番号のハッシュ文字列、
- 開発情報のセマンティックタグ、開発者に優しい、抽出しやすいノート
第二に、セマンティックバージョン管理の仕様
上記のような栗は、それが使用して見ることができるv0.1.0とv1.0.0タグを演奏します。
実際には、ここでは、一連の続くセマンティックバージョニング仕様（セマンティックバージョニングを）。
次の仕様の概要：
バージョン形式：メジャーバージョンマイナーバージョン番号リビジョン番号、バージョン番号は次のようにルールがあるインクリメントされます。
- メジャーバージョン番号：あなたは互換性のないAPIの変更を行い、
- マイナーバージョン番号：あなたが新しいと機能的な下位互換性を行うと、
- リビジョン番号：あなたは、固定された下位互換性の問題を行います。
コンパイラとバージョン番号情報の最初のバージョンは拡張機能として、後述の「メジャーバージョン。マイナーバージョン番号。リビジョン番号」に追加することができます。
なぜ、この仕様は、死の谷「依存関係地獄」として知られているソフトウェア管理者の存在の領域を、避けることであるべきです。
仕様の詳細は、参照は、次のリンクで得ることができます。
第三に、参照
[1] セマンティックバージョン2.0