バージョン管理にgithub、ブランチ、自動リリースを使用する方法は？
Git/Githubの基本的な概念のほとんどを理解しましたが、全体像を理解するのはまだ困難です。
これらは、私がこれまでに何とか機能させることができたものです。
- プッシュコミット
- ブランチを操作する
- Githubと継続的インテグレーションシステムであるTravis CIを統合する
- Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースの下でGithubにリリースをZipとして配置します。
ただし、これまでのところプロジェクトのアルファ/ベータバージョンのみを扱っているため、バージョン管理されたリリースを実際に見たことはありません。
したがって、バージョン管理、個別のバージョンの維持、バージョンのホットフィックスなどについて詳しく知りたいと思います。
次のことを確実にするにはどうすればよいですか。
- プロジェクトの異なるバージョン（バージョン1.1.0および2.0.0など）がある
- バージョンにホットフィックスをプッシュする、バージョンを1.1.1または2.0.1にバンプするなどの機能があります。
- 継続的インテグレーションシステムにコミット時にそのバージョンを自動的にビルドさせ、成功した場合は、その特定のバージョンのリリースを公開します。
私は次のオプション間で疑っています：
- すべてのバージョンでタグを使用する必要がありますか？もしそうなら、継続的インテグレーションシステムビルドはどのように自動的にリリースできますか？
- バージョンごとにブランチを作成する必要がありますか？もしそうなら、それは完全なトンのブランチを作成しませんか？
- バージョン番号を指定するにはどうすればよいですか？バージョン番号を指定する構成ファイルがあっても大丈夫ですか、それともそれよりも賢い方法がありますか？この場合、重要なのはJavaプロジェクトです。
git-flow を見てください。これは優れた（そして人気のある）分岐モデルです。
Gitフローの概要
分岐
永遠に残る主なトランクはdevelopとmasterです。 masterは最新のリリースを保持し、developは最新の「安定した」開発コピーを保持します。
コントリビューターはfeatureからdevelopブランチ（慣例によりfeature/で始まる）を作成します。
$ git checkout -b feature/my-feature develop
およびhotfixからのmasterブランチ（慣例によりhotfix/で始まる）：
# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master
# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>
これらのブランチは「使い捨て」です。つまり、メイントランクにマージされるまでの寿命は短いです。小さな機能をカプセル化するためのものです。
ブランチの仕上げ
コントリビューターがfeatureブランチを完了すると、それをdevelopにマージします。
$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature
hotfixブランチの処理が完了すると、masterとdevelopの両方にマージされ、修正プログラムが次のように持ち越されます。
$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number
これが継続的インテグレーションの側面です。
リリース
リリースのパッケージ化を開始する準備ができたら、「安定した」releaseブランチからdevelopブランチを作成します（featureブランチの作成と同じです）。次に、バージョン番号をタグでバンプします（下記を参照）。
個別のreleaseブランチを使用すると、バグを修正し、developブランチに最後の仕上げを追加しながら、releaseで新しい機能を開発し続けることができます。
リリースを完了する準備ができたら、releaseブランチをmasterとdevelopの両方にマージし（hotfixのように）、すべての変更は繰り越されます。
タグ付け
releaseブランチまたはhotfixブランチを作成するときは、タグでバージョン番号を適切にバンプします。 Vanilla gitでは、次のようになります。
$ git tag -a <tag-name> -m <tag-description>
次に、タグを（個別に）リモートリポジトリにプッシュする必要があります。
$ git Push --tags
通常、バージョンがmajor.minor.hotfixの形式を取るセマンティックバージョニングを使用するのが最善です。メジャーバンプには下位互換性がありませんが、マイナーバンプとホットフィックスバンプには下位互換性がありません（ベータ版でない限り、0.x.x）。
マージ
上記で見たように、git-flowは次のコマンドでブランチをマージすることを推奨します：
$ git merge --no-ff <branch-name>
--no-ffオプションを使用すると、リポジトリの現在のコミットに大量のブランチを残さずにすべてのブランチ履歴を維持できます（そのため、すべてのバージョンにブランチが必要になることはありません）。
また、プルすることをお勧めします
$ git pull --rebase
したがって、無用なマージコミットをたくさん追加する必要はありません。
.gitconfigでは、デフォルトでこれらの両方を実行するようにgitを設定できます。私はあなたにそれを調べさせます;）
バージョンの閲覧
コードベースの特定のバージョンを探している人は、名前でタグをチェックアウトできます。
# checkout in detached HEAD to browse
$ git checkout <tag-name>
# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>
または、誰かがgithubを閲覧している場合は、「ブランチ」ドロップダウンに「タグ」タブもあります。
Git-flow拡張機能の使用（推奨）
このモデルを使用する私のお気に入りの方法は、gitの git flow extension を使用することです。
（編集：Louisは AVH fork を推奨しています。これはgit describeでより適切に機能し、現在はよりアクティブになる可能性があります。Louisに感謝します。）
拡張機能は、すべての厄介な部分（merge --no-ffの使用やマージ後のブランチの削除など）を自動化するので、あなたはあなたの人生を続けることができます。
たとえば、拡張機能を使用すると、次のように機能ブランチを作成できます。
$ git flow feature start my-feature-name
そして、それをそのように仕上げます
$ git flow feature finish my-feature-name
修正プログラムとリリースのコマンドは似ていますが、次のようにブランチ名の代わりにバージョン番号を使用しています。
# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14
# Create the next release
$ git flow release start 2.5.0
次に、Gitフローがバージョンタグを作成し、構成ファイルまたはマニフェストファイル（gruntのようなタスクマネージャーで行うことができます）でバージョンをバンプするように親切に通知します。
それが役立つことを願っています:) Travis CIセットアップとすべてをどのように統合するかは正確にはわかりませんが、githooksがそこに到達すると思います。
すべてのバージョンにタグを使用する必要がありますか？
いいえ、タグを使用する必要はありません。すべてのリリースにタグを付けたい場合はそれで問題ありません。または、CIシステムがビルドされるたびにタグを付けたい場合も、それを行うことができます。タグは基本的にコミットにユーザーフレンドリーな名前を付けているだけなので、簡単にプルして後で表示できます。
バージョンごとにブランチを作成する必要がありますか？
承知しました！分岐はGitでは安価で無料です。そのため、私はあらゆる機会にそれを利用しています。また、ブランチをマージしたり、かなりすばやく削除したりすることもできます。多くのブランチが必要だと感じた場合は、後で選択的にマージすることにより、いつでもブランチを削減できます。十分な実績のあるスキームを使用したい場合は、多数のGit分岐スキームも利用できます。
バージョン番号はどのように指定しますか？
タグは通常、gitに関係するため、バージョン番号を指定する方法です。プロジェクトをバージョン管理する方法、またはそれを行うための最良の方法について話している場合、かなり意見に基づく質問であるため、いくつかの掘り下げを行う必要があります。いくつかのプロジェクトは永遠にベータ版のままですが、他のプロジェクトはスタイルが崩れるように整数バージョンを増やします（Chromeを見て）
すべてのバージョンでタグを使用する必要がありますか？
「バージョン」とは、リリースまたはリリース候補を構成する一連のファイルを意味する場合、すべてのバージョンにタグを付けることを強くお勧めします。将来バージョン1.2.7を参照する必要がある場合、コミットのハッシュを探しますか、それともバージョン番号を使用しますか？
また、git describeビルド情報をどこかに（私と同じように）記録し、タグを使用すると、より優れた出力を提供できます。
もしそうなら、継続的インテグレーションシステムビルドはどのように自動的にリリースできますか？
継続的インテグレーションシステムは、タグの使用方法に関係なく、リリースを構築できます。コミットのハッシュに基づいてリリースをビルドするように指示できます。タグはあなたの人生を楽にします。
バージョンごとにブランチを作成する必要がありますか？もしそうなら、それは完全なトンのブランチを作成しませんか？
分岐は「バージョンごと」のものとは思わない。私のバージョンがすべてmasterブランチのコミットであるプロジェクトがいくつかあります。どちらのプロジェクトも安定した段階ではなく、古いバージョンを長期間サポートする必要がないため、今のところこれ以上複雑なものは必要ありません。しかし、1.0、1.1、1.2をリリースしてから2.0をリリースしたとしても、セキュリティ修正などで1.0シリーズをサポートする必要があるとします。そうすれば、1.xシリーズのメンテナンスリリースを配置するブランチが確実にできます。 。
バージョン番号を指定するにはどうすればよいですか？バージョン番号を指定する構成ファイルがあっても大丈夫ですか、それともそれよりも賢い方法がありますか？この場合、重要なのはJavaプロジェクトです。
複数の場所で番号を更新する必要がある場合に発生する可能性のあるファットフィンガーエラーを防ぐため、構成ファイルのように、バージョン番号の単一のソースを使用することが最善の方法です。私は…うーん…恥ずかしい経験から話している。 1.3をリリースしても、ソフトウェアがバージョン1.2であるとまだ報告されていることがわかります。おっとっと！
別の答えとして、mxduboisはgitflowを推奨しています。 gitflowを使用する場合は、 AVHエディション を使用することをお勧めします。元のバージョンはもはや積極的に維持されていません。 1つの注目すべき違いは、AVHエディションがgit describeインテリジェントに機能します。元のバージョンは trips git describe 。
リストをスキャンするversionがフォーカスなので、...
バージョンを維持する1つの方法は、ブランチとマージ（またはリベース）を使用することです。
だからあなたは持っています：
master
次に、ブランチを作成します
v1
次に、さらに変更を加えます
master(diff1)
次に、ブランチを作成します
v3
次に、さらに変更を加えます
master(diff2)
今：
バージョン2を更新するには
git checkout v2
git merge master # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.
バージョン3を更新するには
git checkout v3
git merge master
上記は大規模なアップデート用です。
ある特定の変更を選択する必要がある可能性は高いですが、
git cherry-pick
http://git-scm.com/docs/git-cherry-pick でのチェリーピッキングの詳細