5

git をデプロイ方法として使用することを真剣に考えています。現在、私は一人で仕事をしているので、私の場合は競合は問題になりません。ローカルホスト、bitbucket アカウント、およびライブ サーバー リポジトリを接続するワークフローをレプリケートするための手順に従ったとしましょう。何かが壊れた場合に、安全に安定したバージョンに戻せるようにする方法を常に考えています。

私が考えることができる唯一のことは、将来のバージョンごとにブランチを作成してからチェックアウトすることです。問題がある場合や問題がある場合は、マスターにチェックアウトします。問題がなければ、数日後にブランチを master にマージし、新しいブランチを作成します。

これは論理的ですか？この件に関する多くの記事を検索しましたが、それらのほとんどは本当に理解できません。それらは中規模のチーム向けであり、ワークフローが異なるためです。また、いくつかのサイトに同じ質問をしましたが、答えが得られませんでした。ほとんどの場合、それはばかげたものである可能性が高く、本当にわかりません. しかし、ここにいます。私の場合、バージョン管理はどのように機能しますか?

4

2 に答える 2

4

まず、特定のブランチのデプロイに問題はないと思います。

プロフェッショナリズム（および予算）に似た環境では、新しいコードが本番環境に到達する前にデプロイされるステージング環境（この場合はライブサーバーリポジトリ）があります。通常、本番環境のバージョンは常に安定している必要があります（ヒント：そうでない場合は、本番環境に移行する前にそれを見つけておく必要があります。ここでは、適切なテスト方法も役立ちます）。

さて、とにかく本番用にマスターを「ホットフィックス」する必要があり、通常の復帰が不十分であると仮定しましょう。これを行う1つの方法は次のとおりです。

  1. --hardを目的のコミットにリセット
  2. マスターのヘッドに（ソフト）リセットします（これで、作業コピーは引き続き目的のコミットからのものになります）
  3. 現在の作業コピー（つまりgit add .）をステージングしてコミットします。

PS：私はこれを頻繁に行わないことに注意してください。特にマスターでは、そうしないことを願っています。

警告のもう1つの注意：これはデータベースのバックアップを処理しません。それらのために他の緊急時対応計画が必要になります

于 2012-10-31T10:06:45.440 に答える
3

この記事をお読みください: 成功した Git ブランチ モデル

当社ではこのアプローチを採用しており、非常に役立っています。基本的にはすでにおっしゃっていることですが、ビルドをリリースするための「マスター」ブランチと、すべての機能ブランチをマージする「開発」ブランチがあり、新しいリリースを公開する準備ができたら、開発ブランチをマスターにマージし、新しいタグを作成するだけです。私が言ったように、安定した分岐モデルを作成するのに役立ったので、記事を読んでください。

于 2012-10-31T09:58:32.283 に答える