バージョン管理にgithub、ブランチ、自動リリースを使用する方法は？[閉まっている]

今まで、Git / Githubの基本的な概念のほとんどを理解していましたが、全体像を理解するのはまだ困難です。

これらは私がこれまでに何とか作業を始めたものです。

• コミットをプッシュする
• ブランチで作業する
• Githubを継続的な統合システムであるTravis CIと統合する
• Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースをGithubのリリースとしてZIPとしてリリースします。

しかし、私はこれまでにプロジェクトのアルファ版またはベータ版にしか取り組んでいなかったため、実際にバージョン付きリリースを見たことはありません。

したがって、バージョン管理、個別のバージョンの維持、バージョンの修正プログラムなどについて詳しく知りたいと思います。

次のことが起こるようにするにはどうすればよいですか：

• 私のプロジェクトの異なるバージョン、たとえばバージョン1.1.0と2.0.0を持っている
• バージョンの修正プログラムをプッシュしたり、バージョンを1.1.1や2.0.1に変更したりすることができます。
• 継続的統合システムがコミット時にそのバージョンを自動的にビルドし、成功した場合は、その特定のバージョンのリリースを公開します。

私は次のオプションの間で疑っています：

• バージョンごとにタグを使用する必要がありますか？もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか？
• バージョンごとにブランチを作成する必要がありますか？もしそうなら、それはたくさんのブランチを作成しませんか（1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます）
• バージョン番号はどのように指定しますか？バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか？この場合、それが重要であれば、Javaプロジェクトになります。

git-flowを見てください。優れた（そして人気のある）分岐モデルです。

Gitフローの概要

分岐

永遠の周りに滞在する主なトランクがあるdevelopとmaster。master最新のリリースとdevelop最新の「安定した」開発コピーを保持します。

貢献者はfeatureブランチを作成します（feature/慣例により接頭辞が付けられます）develop ：

$ git checkout -b feature/my-feature develop

およびhotfixブランチ（hotfix/慣例で接頭辞付き）からmaster：

# 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、タグでバージョン番号を適切に上げます。バニラ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

したがって、多くの無駄なマージコミットを追加しないでください。

gitでは、これらの両方をデフォルトで行うようにgitを設定できます.gitconfig。私はあなたにそれを見せさせます;）

閲覧バージョン

コードベースの特定のバージョンを探している人は、名前でタグをチェックアウトできます。

# 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拡張機能を使用することです。

（編集：ルイはAVHフォークを推奨git describeしています。これは、現在より良く機能し、よりアクティブになります。ありがとう。

拡張機能は、すべての厄介な部分を自動化して（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に関係するため、通常はバージョン番号を指定する方法です。プロジェクトをバージョニングする方法、またはそれを行うための最良の方法について話している場合、それはかなり意見に基づいた質問であるため、いくつかの掘削を行う必要があります。一部のプロジェクトは永久にベータ版のままであり、他のプロジェクトはスタイルがなくなるように整数バージョンを増やします（クロムを見てください）

バージョンごとにタグを使用する必要がありますか？

「バージョン」とは、リリースまたはリリース候補を構成する一連のファイルを意味する場合、すべてのバージョンにタグを付けることを強くお勧めします。将来バージョン1.2.7を参照する必要がある場合、コミットのハッシュを探しますか、それとも単にバージョン番号を使用しますか？

また、git describeビルド情報をどこかに記録するために（私が行うように）使用する場合、タグを使用することで、より良い出力を提供できます。

もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか？

継続的統合システムは、タグの使用方法に関係なくリリースを構築できます。コミットのハッシュに基づいてリリースをビルドするように指示できます。タグはあなたの人生を楽にします。

バージョンごとにブランチを作成する必要がありますか？もしそうなら、それはたくさんのブランチを作成しませんか（1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます）

分岐は「バージョンごと」のものとは思わない。私のバージョンがすべてmasterブランチでコミットされているプロジェクトがいくつかあります。どちらのプロジェクトも安定した段階ではなく、古いバージョンを長期間サポートする必要がないため、今のところこれ以上複雑なものは必要ありません。しかし、1.0、1.1、1.2をリリースし、2.0をリリースし、セキュリティ修正などで1.0シリーズをサポートする必要があるとします。 。

バージョン番号はどのように指定しますか？バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか？この場合、それが重要であれば、Javaプロジェクトになります。

構成ファイルなど、バージョン番号の単一のソースを持つことは、複数の場所で番号を更新する必要がある場合に発生する可能性がある太った指のエラーを防ぐための最良の方法です。私は...うーん...恥ずかしい経験から話しています。1.3をリリースしたのは、バージョン1.2であることをソフトウェアがまだ報告していることを確認するためだけです。おっとっと！

別の答えとして、mxduboisはgitflowを推奨しました。gitflowを使用することに決めた場合は、AVHエディションの使用をお勧めします。元のバージョンはアクティブに維持されなくなりました。重要な違いの1つは、AVHエディションがリリースマージを実行することで、git describeインテリジェントに機能することです。元のバージョンは、トリップgit describeする方法でマージを実行します。

あなたのリストをスキャンすると、バージョンがあなたの焦点だと思うので...

バージョンを維持する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をご覧ください