6

長くなりますが、ご容赦いただければ幸いです。

チームのソース コードをバージョン管理下に置くために git を使用しようとしています。自分に合ったさまざまなアプローチを見つけようとした後、最終的にgit format-patch機能を使用することにしました。FWIW、製品は Windows で実行されている ASP.NET Web アプリケーションであり、現在msysgitを使用しています。

背景:
すべての aspx ファイルを含むステージング サーバー (ミラー運用サーバー) があります。次に、ルート フォルダー内でinit-dbを使用して git リポジトリを作成し、git add .すべてのファイルを追跡しました。

ラップトップにローカル コピーを作成するために、ステージング サーバーから ".git" フォルダーを圧縮し、ローカル マシンに FTP 接続しました。名前を「staging.git」に変更git clone staging.git webappfolderし、開発を行うために実行しました。

feature1 と feature2 に対して 2 つのコミットを行った後、変更をステージング サーバーに適用します。git format-patch -2ファイル0001blah.patchとに出力するを実行しました0002blah.patch。

次に、これら 2 つのパッチ ファイルがステージング サーバーに送信さgit am 0001blah.patchれ、ステージング サーバー自体で を実行しました。agit logを実行すると、コミットが完了したことが示されます。しかし、私がするときgit status、それは示していますChanged but not updated: modified: file1.aspx。

それは正確にはどういう意味ですか？私もやってみましたgit apply 0001blah.patchが、私が得たのはerror" patch failed: file1.aspx: patch does not apply.

ワークフローに問題はありますか? 適切な方法やヘルプに関する洞察は非常に役立ちます。繰り返しになりますが、SSH サーバーをすぐにセットアップする予定はないため、現時点ではパッチ適用モデルが最も実行可能です。

4

2 に答える 2

5

私はちょうどこれを試しました：

rm -rf clone?

# clone 1 is the working copy
mkdir clone1
(
    cd clone1
    git init
    echo foo >> file1
    git add file1
    git commit -m "Initial state"
)

# clone 2 is the staging repo
git clone clone1 clone2

# create patches
(
    cd clone1
    git tag staging # tag to track what's in staging

    echo feature1 >> file1
    git add file1
    git commit -m "Feature 1"

    echo feature2 >> file1
    git add file1
    git commit -m "Feature 2"

    rm *.patch
    git format-patch staging
)

# apply patches
(
    cd clone2
    git am ../clone1/*.patch
    # Cygwin/msysgit line ending weirdness when patching. Aborting and
    # reapplying clears it up.
    git am --abort 
    git am ../clone1/*.patch
    git log
    git status
)

am を 2 回実行しないとパッチが明確に適用されないという小さな問題がありますが、file1 の正しい内容でクローン 2 にクリーンな作業ディレクトリが作成されます。したがって、ワークフロー自体に問題はないようです。

Git apply は作業ツリーのみを更新し、コミットは実行しません。

つまり、ステージングに git リポジトリは使用しません。私のワークフローは、おそらく開発リポジトリのリリース ブランチ/フォークを作成し (または作成せず)、その完全なクリーン コピーをデプロイするだけです。

ステージング環境への増分更新の場合git tag stagingは、リリース ブランチで "git diff staging..HEAD > update.patch" を使用して電子メールを送信し、標準の UNIX "patch -p1" を適用して動作するはずです。これは、ステージング サーバー上に変更履歴を物理的に保持する必要がない限りです。

于 2009-04-28T13:23:37.150 に答える
3

試してみましたか

git am -3

? git-am docから、

-3
--3way

When the patch does not apply cleanly, fall back on 3-way merge

注: Git Google Summer of Code 2009から、「git-apply に 3 ウェイ マージ フォールバックを教える」というプロジェクトがあります。

ファイルにgit-applyパッチを適用すると、ファイルがきれいにパッチされない場合があります。そのような場合、git-apply現在パッチを拒否します。
から呼び出された場合git-am、次の方法で 3 方向マージが試行されます。

  • パッチから「index ...」データを取得し、
  • 一時的なツリーを構築し、
  • それにパッチを適用してから、
  • 一時ツリーを現在のブランチにマージします。

さまざまな理由から、git-sequence の「適用」コマンドを使用したり、フォークを少なくして git-am の処理を​​高速化したりするなどの利点があるため、一時的なツリー ダンス全体を git-apply の内部で直接実行するとよいでしょう。

于 2009-04-28T13:11:04.010 に答える