11

問題: 毎回ではありませんが、時々、Git はリポジトリのstaticディレクトリを削除します。何が原因かはわかりませんが、ブランチ間をマージするとき、またはブランチをチェックアウトするときに発生するようです. 確認せずにこれを行い、追跡されたファイルを食べます。

背景:

  • 私は、いくつかのブランチ、「リリース」、「開発」、複数の機能ラインを持つ (プライベート) プロジェクトを持っています。
  • 私たち 2 人 (私と @stevejalim) がレポに取り組んでいます。この問題は私たち二人に起こります。
  • 私は git コマンドに純粋にコマンド ラインを使用しています。Steve は、コマンド ラインと Git Tower を組み合わせて使用​​しています。
  • staticディレクトリを持つ Django プロジェクトです。過去のある時点でディレクトリをgit rm編集したり、ディレクトリに配置したりした可能性がありますが、最近ではありません。そして、私たちの開発ブランチの責任者にはファイルがなく、追跡されています。static.gitignorestatic.gitignorestatic
  • これは非常にまれにしか発生しないため、それが私たちが行っていることなのか、断続的な問題なのか、Git のバグなのか、ツリーの破損なのかはわかりません。
  • 別のブランチを にマージする場合にのみ発生する可能性がありdevelopます。ただし、ブランチは常にから分岐しdevelop、 に戻りますdevelop。しかし、よくわかりません。

  • git-flow を使用していますが、git-flow 以外のコマンドを使用した場合にも問題が発生します。

  • これが発生する可能性がある場合の例として:

    1) Steve には、クリーンな (コミットやステージに変更がない) 安定した開発ブランチがありました。彼は新しいリリースをカットしgit flow release start|finish、その過程で (おそらくマスターから開発への逆マージ)、/static/ ツリー全体が削除されました。

    2) スティーブは変更を破棄して削除を修復しました (ファイルの削除を本質的に元に戻すため)。しかしその後、スティーブはマスターから開発に戻るだけで、 /static/ ディレクトリが再びザッピングされました (これは Git Tower で発生しました)。

    3）機能ブランチからマージして暫定マージとして開発するだけで、それがトリガーされることがあります。ただし、新しいリリースをカットするときに最も頻繁に発生するようです

/static/ ディレクトリのザッピングを修復する方法に関連している可能性はありますか? 削除されたものを一括して元に戻す最良の方法は何ですか? ローカルの変更を破棄したり、HEAD をハード リセットしたりしても、問題は解決しないようです。リベースは私たちを助けるでしょうか?

更新git add .ブランチを変更せず、マージしないという単純な方法で、これを再び経験しました。それは診断にまったく役立ちますか？

Steve の .git/config の内容は次のとおりです。

[core]
   repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = git@github.com:foobarbazbam/bar.git
[branch "master"]
    remote = origin
    merge = refs/heads/master
[gitflow "branch"]
    master = master
    develop = develop
[gitflow "prefix"]
    feature = feature/
    release = release/
    hotfix = hotfix/
    support = support/
    versiontag = 
[difftool "tower"]
    cmd = \"/Applications/Tower.app/Contents/Resources/CompareScripts/kaleidoscope.sh\" \"$LOCAL\" \"$REMOTE\"

の内容は次の.gitignoreとおりです。

.DS_Store
*.pyc
*.log
*.log.*
*.bak
*~
settings_local.py
/build/
/static_collected/*
/static/uploads/*
/static/theme_files/*
/static/picture/*
pip-log.txt
*.tmproj
*.dot
*.db
*.sublime-project
*.sublime-workspace
/docs/_*
4

3 に答える 3

6

紳士淑女の皆さん、私は公に謝罪する必要があります。Git に責任はありませんでした。この質問は、同じ道を進む可能性のある他の人への教訓としてここに残しておきます。

django-storages バックエンド (Django が Amazon S3 に透過的にファイルを保存できるようにする「プラグイン」) を使用していました。これには と呼ばれるテストがありHashPathStorageTestます。このテストで削除されるティアダウンsettings.MEDIA_ROOTは、 に設定されていました./static。私の意見では、これは欠陥があります。作成していない業務一括削除ファイルはありません。

チェックインする前に、善良な市民のようにテストを実行していました。ほとんどの場合、コードのテストのみを実行しましたが、プロジェクト全体 (サードパーティのプラグインを含む) のテストを実行することもありました。これは問題の動作を生み出していました。test と git を一緒に実行したため、どのコマンドが削除を行っているかを突き止めるのは簡単ではありませんでした (そして、削除されたファイルは、実行したときにのみ表示されましたgit status)。

それで問題は解決しました。繰り返しになりますが、Git の名に中傷を投げかけて申し訳ありません。

于 2012-02-09T16:07:15.770 に答える
0

さて、これはちょうど起こった-それはとてもばかげているので、私はそれに別の答えを追加しています。SQLスクリプトのリポジトリがあり、新しい開発者が誤って.gitignoreを編集して* .sqlを含めました。言うまでもなく、変更はそのブランチで伝播されなくなりました。幸い、開発時間が大幅に失われる前にキャッチされました。ただし、これにより上記の問題が発生する可能性があることは考えられません。gitディレクティブファイルを確認しましたか？フォルダが無視された場合（そして.gitignoreもそこにある場合-つまり無視された場合）、ほとんど魔法のように消えて再表示される可能性があります。

于 2012-02-17T09:38:36.373 に答える
0

これは、A) フォルダーが削除されている B) マージ先のブランチよりも新しいと思われるブランチにマージすることを git が決定しているように見えます。アメリカの日付タイプのマシンとヨーロッパの日付タイプのマシンがあるのでしょうか? または、マシンの日時をリセットするテストが含まれていますか?

私は...するだろう

a) 開発に含まれるすべてのマシンのリージョンを確認します。b）開発の固定ポイントを選択し、ファイルをコピーして新しいリポジトリを作成し、そこから進みます。

于 2012-02-08T11:35:59.953 に答える