Gitを使用したダーティインデックスまたは追跡されていないファイルの確認

私のgitリポジトリにコミットされていない変更があるかどうかを確認するにはどうすればよいですか？

1. インデックスに追加されたがコミットされていない変更
2. 追跡されていないファイル

スクリプトから？

git-status gitバージョン1.6.4.2では常にゼロを返すようです。

素晴らしいタイミング！数日前に、ブログの投稿を書いて、gitステータス情報をプロンプトに追加する方法を見つけました。

これが私がすることです：

1. ダーティステータスの場合：

   # Returns "*" if the current git branch is dirty.
   function evil_git_dirty {
     [[ $(git diff --shortstat 2> /dev/null | tail -n1) != "" ]] && echo "*"
   }

2. 追跡されていないファイルの場合（解析可能な出力を提供する--porcelainフラグに注意してgit statusください）：

   # Returns the number of untracked files
   
   function evil_git_num_untracked_files {
     expr `git status --porcelain 2>/dev/null| grep "^??" | wc -l` 
   }

が、git diff --shortstatより便利で、あなたも使用することができますgit status --porcelain汚れたファイルを取得するために：

# Get number of files added to the index (but uncommitted)
expr $(git status --porcelain 2>/dev/null| grep "^M" | wc -l)

# Get number of files that are uncommitted and not added
expr $(git status --porcelain 2>/dev/null| grep "^ M" | wc -l)

# Get number of total uncommited files
expr $(git status --porcelain 2>/dev/null| egrep "^(M| M)" | wc -l)

注：2>/dev/nullフィルターはエラーメッセージを除外するため、git以外のディレクトリでこれらのコマンドを使用できます。（彼らは単に戻るでしょう0ファイル数をためにれます。）

編集する：

ここに投稿があります：

ターミナルプロンプトへのGitステータス情報の追加

改良されたGit対応のシェルプロンプト

Gitを確実に「スクリプト化」するための鍵は、「配管」コマンドを使用することです。

開発者は、配管コマンドを変更するときに注意を払い、非常に安定したインターフェースを提供するようにします（つまり、リポジトリーの状態、標準入力、コマンドラインオプション、引数などの特定の組み合わせは、コマンド/のすべてのバージョンのGitで同じ出力を生成します。オプションが存在します）。配管コマンドの新しい出力バリエーションは、新しいオプションを介して導入できますが、古いバージョンに対して既に作成されているプログラムに問題を引き起こすことはありません（新しいオプションが存在しないため（または少なくとも存在していなかったため））。使用されていません）スクリプトが作成されたとき）。

残念ながら、「日常的な」Gitコマンドは「磁器」コマンドなので、ほとんどのGitユーザーは配管コマンドに慣れていない可能性があります。磁器と配管コマンドの区別は、メインのgitマンページで行われます（高レベルコマンド（磁器）および低レベルコマンド（配管）というタイトルのサブセクションを参照）。

コミットされていない変更について調べるには、git diff-index（インデックス（およびおそらく作業ツリーの追跡されたビット）を他のツリー（たとえばHEAD）git diff-filesと比較）、おそらく（作業ツリーをインデックスと比較）、そしておそらくgit ls-files（リストファイル;追跡されていないリストなど）が必要になります。 、無視されないファイル）。

（以下のコマンドでは、という名前のファイルがある場合にコマンドが失敗するため、のHEAD --代わりにが使用されることに注意してください。）HEADHEAD

リポジトリに段階的な変更（まだコミットされていない）があるかどうかを確認するには、次のコマンドを使用します。

git diff-index --quiet --cached HEAD --

• 0それが存在する場合、違い1はありませんでした（違いがあったことを意味します）。

作業ツリーにステージング可能な変更があるかどうかを確認するには：

git diff-files --quiet

• 終了コードはgit diff-index（0==違いなし1===違い）と同じです。

作業ツリー内のインデックスと追跡されたファイルの組み合わせに次の変更があるかどうかを確認するにはHEAD：

git diff-index --quiet HEAD --

• これは、前の2つの組み合わせのようなものです。主な違いの1つは、作業ツリーで「元に戻した」（にあるコンテンツに戻った）段階的な変更がある場合でも、「違いはない」と報告することですHEAD。この同じ状況で、2つの別々のコマンドはどちらも「相違点が存在する」というレポートを返します。

追跡されていないファイルについても言及しました。「追跡されず、無視されない」という意味か、単なる「追跡されない」（無視されたファイルを含む）という意味かもしれません。どちらにしても、それgit ls-filesは仕事のためのツールです：

「追跡されていない」場合（無視されたファイルが存在する場合は無視されます）：

git ls-files --others

「追跡されず、無視されない」場合：

git ls-files --exclude-standard --others

私の最初の考えは、これらのコマンドに出力があるかどうかを確認することです：

test -z "$(git ls-files --others)"

• それはで終了した場合0、その後何の人跡未踏のファイルが存在しません。それはで終了した場合1、その後人跡未踏のファイルがあります。

これにより、異常終了がからgit ls-files「追跡されていないファイルがない」というレポートに変換される可能性があります（どちらも上記のコマンドでゼロ以外の終了が発生します）。もう少し堅牢なバージョンは次のようになります。

u="$(git ls-files --others)" && test -z "$u"

• 考え方は前のコマンドと同じですが、予期しないエラーがgit ls-filesから伝播することを許可しています。この場合、ゼロ以外の出口は、「追跡されていないファイルがある」ことを意味するか、エラーが発生したことを意味します。「エラー」結果と「追跡されていないファイルなし」の結果を組み合わせる場合は、を使用しますtest -n "$u"（exit 0は「追跡されていないファイル」を意味し、ゼロ以外はエラーまたは「追跡されていないファイル」を意味します）。

別のアイデアは、を使用--error-unmatchして、追跡されていないファイルがない場合にゼロ以外の終了を発生させることです。これには、「追跡されていないファイルがない」（exit 1）と「エラーが発生しました」（exitが0以外であるが、おそらく128）とが混同するリスクもあります。しかし、0対1ゼロ以外の終了コードをチェックすることはおそらくかなり堅牢です：

git ls-files --others --error-unmatch . >/dev/null 2>&1; ec=$?
if test "$ec" = 0; then
    echo some untracked files
elif test "$ec" = 1; then
    echo no untracked files
else
    echo error from ls-files
fi

追跡されておらず無視されていないファイルのみを考慮したい場合は、上記のgit ls-files例のいずれかを--exclude-standard使用できます。

git 1.7.0以降を使用していると仮定します...

このページのすべての回答といくつかの実験を読んだ後、正確さと簡潔さの適切な組み合わせに到達する方法は次のとおりだと思います。

test -n "$(git status --porcelain)"

gitは追跡、無視、追跡されないが無視されないなどの間で多くのニュアンスを許容しますが、典型的な使用例はビルドスクリプトを自動化することであり、チェックアウトがクリーンでない場合はすべてを停止したいと考えています。

その場合、プログラマーが何をするかをシミュレートすることは理にかなっています：タイプgit statusして出力を見てください。しかし、表示される特定の単語に依存したくないので--porcelain、1.7.0で導入されたモードを使用します。有効にすると、クリーンなディレクトリは出力されません。

次に、を使用test -nして、出力があったかどうかを確認します。

このコマンドは、作業ディレクトリがクリーンである場合は1を返し、コミットする変更がある場合は0を返します。反対-nにする-z場合は、をに変更できます。これは、これをスクリプト内のコマンドにチェーンするのに役立ちます。例えば：

test -z "$(git status --porcelain)" || red-alert "UNCLEAN UNCLEAN"

これは事実上、「変更する必要がないか、アラームを発することはありません」と述べています。このワンライナーは、記述しているスクリプトによっては、ifステートメントよりも望ましい場合があります。

VonCの回答からの実装：

if [[ -n $(git status --porcelain) ]]; then echo "repo is dirty"; fi

これらの回答のいくつかを確認しました...（そして* nixとウィンドウでさまざまな問題がありましたが、これは私が持っていた要件でした）...次はうまく機能することがわかりました...

git diff --no-ext-diff --quiet --exit-code

* nixの終了コードを確認するには

echo $?   
#returns 1 if the repo has changes (0 if clean)

window $で終了コードを確認するには

echo %errorlevel% 
#returns 1 if the repos has changes (0 if clean) 

https://github.com/sindresorhus/pure/issues/115から提供 共有のための投稿について@paulirishに感謝

なぜ次のgit statusようなスクリプトでカプセル化しないでください。

• そのコマンドの出力を分析します
• 必要なものに基づいて適切なエラーコードを返します

そうすれば、スクリプトでその「拡張」ステータスを使用できます。

0xFEのは、彼の中で言及優秀な答えは、git status --porcelain任意のスクリプトベースのソリューションに尽力しています

--porcelain

スクリプトの出力を、安定した解析しやすい形式で提供します。
現在、これはと同じですが--short output、将来変更されないことが保証されているため、スクリプトに対して安全です。

1つのDIYの可能性、0xfeの提案に従うように更新

#!/bin/sh
exit $(git status --porcelain | wc -l) 

Chris Johnsenが指摘したように、これはGit 1.7.0以降でのみ機能します。

実行の最後に変更された追跡ファイルまたは無視されない追跡されていないファイルがある場合、ビルドを失敗させる簡単な方法が必要になることがよくありました。

これは、ビルドが残り物を生成するケースを回避するために非常に重要です。

これまでのところ、私が使用した最良のコマンドは次のようになります。

 test -z "$(git status --porcelain | tee /dev/fd/2)" || \
     {{ echo "ERROR: git unclean at the end, failing build." && return 1 }}

それは少し複雑に見えるかもしれませんが、これが望ましい動作を維持するショートされたバリアントを誰かが見つけたら幸いです：

• すべてが正しい場合、出力はなく、終了コードは成功
• 失敗した場合は終了コード1
• 失敗した理由を説明するstderrのエラーメッセージ
• 失敗の原因となったファイルのリストを表示し、再びstderrを実行します。

@ eduard-wirchの回答は完全なものでしたが、両方を同時に確認したかったので、これが私の最後のバリアントです。

        set -eu

        u="$(git ls-files --others)"
        if ! git diff-index --name-only --quiet HEAD -- || [ -z "${u:-}" ]; then
            dirty="-dirty"
        fi

set -eまたは同等のものを使用して実行しない場合は、代わりにu="$(git ls-files --others)" || exit 1（またはこれが使用された関数で機能する場合は戻る）を実行できます。

したがって、untracked_filesは、コマンドが正しく成功した場合にのみ設定されます。

その後、両方のプロパティをチェックし、変数（または何でも）を設定できます。

これは、追跡されていないファイルがリポジトリに存在するかどうかを調べるための、よりシェルにやさしいバリエーションです。

# Works in bash and zsh
if [[ "$(git status --porcelain 2>/dev/null)" = *\?\?* ]]; then
  echo untracked files
fi

これは2番目のプロセスをフォークせずgrep、gitリポジトリにいるかどうかを確認する必要もありません。これはシェルプロンプトなどに便利です。

あなたもすることができます

git describe --dirty

。ダーティな作業ツリーを検出すると、末尾に「-dirty」という単語が追加されます。によるとgit-describe(1)：

   --dirty[=<mark>]
       Describe the working tree. It means describe HEAD and appends <mark> (-dirty by default) if
       the working tree is dirty.

。警告：追跡されていないファイルは「ダーティ」とは見なされません。これは、マンページに記載されているように、作業ツリーのみが考慮されるためです。

このスレッドからの回答のより良い組み合わせがあるかもしれません..しかし、これは私にとってはうまくいきます...あなた.gitconfigの[alias]セクションのために...

          # git untracked && echo "There are untracked files!"
untracked = ! git status --porcelain 2>/dev/null | grep -q "^??"
          # git unclean && echo "There are uncommited changes!"
  unclean = ! ! git diff --quiet --ignore-submodules HEAD > /dev/null 2>&1
          # git dirty && echo "There are uncommitted changes OR untracked files!"
    dirty = ! git untracked || git unclean

ダーティな状態を検出するために使用する最も簡単な自動テスト= 追跡されていないファイルを含むすべての変更：

git add --all
git diff-index --exit-code HEAD

注意：

• なし add --all diff-indexは追跡されていないファイルに気づきません。
• 通常、git resetエラーコードをテストした後に実行して、すべてを元に戻します。

これが最良で最もクリーンな方法です。選択された回答が何らかの理由で機能しませんでした。ステージングされた、コミットされていない新しいファイルである変更が反映されませんでした。

function git_dirty {
    text=$(git status)
    changed_text="Changes to be committed"
    untracked_files="Untracked files"

    dirty=false

    if [[ ${text} = *"$changed_text"* ]];then
        dirty=true
    fi

    if [[ ${text} = *"$untracked_files"* ]];then
        dirty=true
    fi

    echo $dirty
}