2017-07-15 3 views
11

私の製品はIntelliJ用のプラグインです。私は基本的なIntelliJプラットフォームのいくつかのバージョンをサポートしており、バージョン間でAPIが頻繁に変更されるため、それぞれのプラグインのビルドをリリースしています。それだけで私はそれに取り組んでいるので、私はマスターで開発し、その後、それぞれの他のバージョンのブランチを維持します。だから私のレポは、次のようになります。gitのブランチでタグ間のマージを見つける

1.6.0 1.6.1-eap1 
.... a---b---c--- master 
     \  \ 
     d-------e--- idea-2017.1 
     \  \ 
     f-------g--- idea-2016.3 
      \  \ 
      ...  ... etc etc 

aは安定版リリースで、1.6.0でタグ付けされています。 cはEAP(ベータ版)で、1.6.1-eap1というタグが付けられています。このスキームは、これらの2つのケースでうまく機能します。

リリースチャネルには入っていないdevビルドを作成したいと思うこともありますが、ユーザーは手動でダウンロードして好きな場合にテストすることができます。私はdevのユーザーがIntelliJのバージョンを使用している可能性があるので、各プラットフォーム用のdevビルドを作成したいと思います。私が考えることができる最良の方法は、例えば、1.6.0タグ(コミットa)からコミットd,fなどのブランチを作成し、devブランチをマージして作成することですdevはからビルドします。

これらのブランチを作成して維持するためのスクリプトを書いているとすれば、1.6.0タグからdfなどのコミットがどのように見つけられますか?

+0

デベロッパーブランチのベースとして各IntelliJバージョンに最新のバージョンを使用したくないですか?私。 a、d、fの代わりにc、e、gを使います。私はそれらには各バージョンの最新の修正が含まれていると思うし、新しい開発をテストするためのより良い拠点だったと思います。 – lucash

+0

これは可能ですが、問題は同じです - '1.6.1-eap1'というタグがある場合、' e'、 'g'などのコミットを見つけるにはどうすればいいのですか?すべてのタグ付きリビジョンのブランチで、各バージョンブランチにマージコミットがマージされていることが保証されています。 – Colin

答えて

1

ソリューションは、コマンドを使用することです「idea-2017ではなかったし、masterではありませんでしたidea-2017最古のidea-2016.3からa ANG g最古のコミットの間で見つけます」 、あなたに同じ歴史の中で:

cf32d9f idea-2017 e 
88f264c idea-2016.3 g 
5bc9fa1 idea-2017 d 
3f460fe idea-2016.3 f 
224cac8 master c 
67620cd master b 

その後、最新のラインがidea-2016.3とでマークされた最新のものが付いて見つけます、あなたのコミットになります。

次のf'で修正された、たとえばfなどのバージョンの違いによりブロッカーに問題があった場合、出力が望ましくないことがあります。だから私はまだ明示的にタグを付けることを考えています。

+0

ありがとう、私はこれが私の初期のバージョンよりも好きです。私は最後のコミットを得るためにawkを使っています: 'awk '$ 2 ==" idea-2017.1 "{コミット= 1} END {プリント$コミット} – Colin

0

おそらく最も簡単な方法は、シェルスクリプトでサポートされているバージョン/ブランチ名のリストを維持することでしょうか?

私はあなたが別の変更を加える場合は、これがあると思っていた理由:

1.6.0  eap1 eap2 
.... a---b---c---h--- master 
     \  \ \ 
     d-------e---i--- idea-2017.1 
     \  \ \ 
     f-------g---j--- idea-2016.3 
      \  \ \ 
      ...  ... etc etc 

あなたはその変化(hが)すなわちheにマージされ、あなたの図に示す枝の頭部にマージしたいですおよびg。ブランチ2017.1は、マージする正しいコミットであるeを指していました。

あなたは共通の祖先や何かを見つけるために歩いて何かをすることができますが、それは不必要に複雑で、本当にあなたを買わないと思います。

さらに、ブランチのリストを残しておけば、古いバージョンのサポートを比較的簡単に停止できます。

+0

私の支店の保守スクリプトではすでにブランチ名がハードコードされています。私が新しいバージョンをサポートしている場合は、それらを更新します。ここまでは順調ですね。問題は、新しい機能のためにこれらの開発ビルドを常に作成したくないということです。ユーザーが再現できない問題が頻繁に発生するケースがよくあります。スタックトレースや、私が送ったものは何でも、私は修正を行いますが、実際にテストすることはできません。その場合、私は彼らがテストすることができる修正プログラムでビルドを作成したいと思います、私は彼らが実行しているバージョンからそれをベースにする必要があります。 – Colin

3

は、ここに私がやってしまったものです:

#!/bin/sh 

set -e # Automatically abort if any simple command fails 

die() { 
    echo >&2 "[email protected]" 
    exit 1 
} 

[ "$#" -eq 2 ] || die "Usage: $0 <branch name> <tag>" 

tag_commit=$(git rev-list --abbrev-commit -n 1 $2) 
[ "${tag_commit}" = "" ] && die "No commit found for $2" 

child_commit() { 
    git log --graph --pretty=format:"%h %p" --decorate -20 --first-parent $1 | grep $2 | cut -c 3-10 
} 

branch_2017_1=$(child_commit idea-2017.1 $tag_commit) 
[ "${branch_2017_1}" = "" ] && die "No commit found for idea-2017.1" 

branch_2016_3=$(child_commit idea-2016.3 $branch_2017_1) 
[ "${branch_2016_3}" = "" ] && die "No commit found for idea-2016.3" 

branch_2016_2=$(child_commit idea-2016.2 $branch_2016_3) 
[ "${branch_2016_2}" = "" ] && die "No commit found for idea-2016.2" 

branch_2016_1=$(child_commit idea-2016.1 $branch_2016_2) 
[ "${branch_2016_1}" = "" ] && die "No commit found for idea-2016.1" 

git branch "$1" $tag_commit 
git branch "$1-2017.1" $branch_2017_1 
git branch "$1-2016.3" $branch_2016_3 
git branch "$1-2016.2" $branch_2016_2 
git branch "$1-2016.1" $branch_2016_1 

は、今私はちょうど私のマージを更新し、分岐シリーズ名を受け入れる任意に作成スクリプトをリリースするだろう、と私は良いと思います。

秘密のソースはchild_commit関数にあり、これはhereからクリンブルされています。

git log --oneline --source --ancestry-path master idea-2017 idea-2016.3 --not 1.6.0 

出力は次のとおりです。問題については

関連する問題