3

こんにちは私はこれはかなり単純な質問であるべきだと思っていますが、私はgitの管理にあまり精通していません。

非常に人気のあるhttp://nvie.com/posts/a-successful-git-branching-model/を使用して、gitブランチの一般的なモデルを提供しています。ただし、リリースブランチをマスターにマージしてから開発ブランチに戻すことに関しては、少し混乱しています。

設定ファイルなどのGitのベストプラクティスも気に入っていますが、それは実際には最善の方法ではないように感じます。

私は次のことを考えています：

  1. 開発ブランチから新しいリリース1.0ブランチを作成します
  2. 変更を加える（環境をPRODUCTIONに設定）（BAD IDEA）
  3. リリース1.0ブランチへの変更をコミットします
  4. リリース1.0からの変更をマスターブランチにマージします
  5. 新しいバージョンに1.0のタグを付けます
  6. （これは私にとって曖昧になるところです）
  7. 変更を加える（環境をDEVELOPMENTに設定）（BAD IDEA）
  8. リリース1.0ブランチへの変更をコミットします
  9. リリース1.0ブランチを開発ブランチにマージします

シェルスクリプトを使用して変更を自動化し、場合によっては開発->リリース->マスターの作成全体を自動化します。このスクリプトを「＃：update.shproduction1.0」と呼びます。

if !([ "$1" == "production" ] || [ "$1" == "development" ]); then
    echo "Must specify production or development as the second argument"
    exit;
fi

if [ ! -n "$2" ]; then
    echo "Must specify a version (e.g., 1.2, 1.2.1)."
    exit;
fi

if ([ "$1" == "production" ]); then
    var_env="production";
    git checkout -b release-$2 develop
fi

if ([ "$1" == "development" ]); then
    var_env="development";
fi

echo "Starting change to $1..."

SRC="define('ENVIRONMENT', '.*');"
DST="define('ENVIRONMENT', '${var_env}');"
sed -i -e "s/[\s]*$SRC/$DST/g" index.php
echo "Updated environment constant."

echo "Do you wish to continue and commit these changes? (y|n)"

read WISH

if([ "$WISH" == "y" ]); then
    git checkout master
    git merge --no-ff release-$2
    git tag -a $2
else
    echo "Okay. I give up."
fi

このようにするのは理にかなっていますか？

基本的に、マスターリリースごとに少なくとも2つのコミットがあります。1つは本番変数を設定し、それらの変数をマスターブランチにマージし、もう1つは変数を開発設定に戻し、開発ブランチにマージすることをコミットします。

4

1 に答える 1

2

ただし、リリースブランチをマスターにマージしてから開発ブランチに戻すことに関しては少し混乱しています。

これが行われる理由は、おそらく、リリースが完全ではないためです。そのリリースに特に関連するバグ修正をreleaseブランチにコミットし、新機能の開発がdevelopブランチに入ります。release次に、ブランチをにマージして、developこれらの変更をメインの開発ストリームに取り込みます。

構成設定を変更するためだけに2番目のコミットを行い、それを元に戻すことで提案していることは、頭痛の種を求めているだけであり、実行する価値がない可能性があります。マシン固有の構成ファイルを処理する方法についての同様の質問がここで尋ねられました：

おそらく他にも多くの同様の質問があります。上記のもののコンセンサスは、正しいバージョンの設定ファイルをリポジトリに入れることは悪い考えであるように思われます。また、デプロイメントスクリプトのある種のテンプレート/置換/ファイルgnomesステップがその方法です。人的要素を取り除き、特定の環境にデプロイするたびにステップが発生することを事実上保証します。

VonCの回答は、これについてかなり良い見通しを示しています。具体的には、履歴を維持するプロセスとソフトウェアを展開するプロセスを分離しています。

于 2012-10-10T03:07:47.487 に答える