導入
私は 2012 年から Git とバージョン管理ツールを使用しており、長年にわたって、それらがどのようにデプロイメントを大幅にスピードアップできるかを見てきました。リリース時間を約 40% 短縮するプロジェクトを管理してきました。初期の頃、私は Git はコードをプッシュしてブランチを管理するためだけのものだと考えていました。しかし、それだけではないことがすぐにわかりました。 Git リポジトリを深く掘り下げることで、特定のコミットにリンクしてバグを追跡したり、変更を監査してすべてが計画どおりに行われていることを確認したり、バージョンを明確に整理して維持することで機械学習プロジェクトなどの複雑なワークフローをサポートしたりすることができました。
コードの背後にあるストーリーを本当に理解したい開発者、データ サイエンティスト、システム アーキテクト、または技術リーダーであれば、このガイドが最適です。基本的な「追加、コミット、プッシュ」コマンドを超えて、Git リポジトリから貴重な洞察を引き出す実践的な方法を探っていきます。実際の分析に Git の組み込み機能を使用し、直面する一般的な課題に取り組み、余分な手間をかけずにこれらのテクニックを日常のワークフローに組み込む方法を説明します。
このガイドを読み終える頃には、プロのように Git リポジトリを分析する方法がわかり、コードの品質を向上させ、デバッグを高速化し、より自信を持って複雑なプロジェクトを処理できるようになります。これらは単なる理論ではありません。彼らは、実稼働環境で 10 年以上働いてきた経験から得たものであり、そこではこれらのスキルが大きな違いを生み出しました。
Git のバージョン管理とコード分析の基本を理解する
Git バージョン管理の詳細
Git は、Linux を始めた人物である Linus Torvalds によって 2005 年に作成されました。これは、開発者がコードに加えられたすべての変更を追跡するのに役立つシステムです。ファイルを何度も保存するのではなく、Git はプロジェクトのスナップショット (コミットと呼ばれる) を取得するので、いつでも再訪できます。優れているのは、多くの人がブランチを通じて同時に異なる部分に作業し、その作業をマージで結合できることです。内部的には、Git はこれらすべてのコミットを特別な構造に保存し、永続的にグラフのようにリンクします。これは、プロジェクトの履歴が安全で追跡しやすいことを意味します。
Git は実際に 3 つの主要なオブジェクトを追跡します。BLOB はファイル コンテンツのスナップショットです。ツリー。BLOB をディレクトリに編成します。そしてコミット。これらのツリーとその親コミットを指します。この設定により、バージョンを効果的に管理し、プロジェクトの履歴をより深く掘り下げることが可能になります。
Git で分析するとはどういう意味ですか?
ほとんどの人は、Git を変更を保存し、他のユーザーと共同作業するための単なる手段として考えています。しかし、Git を使用して分析することは、そのコマンドを使用して時間の経過とともにコードがどのように変化したかを実際に理解することにより、さらに前進することです。これは、特定のビットがいつ変更されたのか、なぜ変更されたのかを調べたり、gitblame などのツールを使用して特定の行を最後に編集したのが誰なのかを確認したり、ログを調べて傾向を見つけたり、差分を使用してコードの異なるバージョンを比較したりすることを意味します。
バグを追跡し、コードのどの部分を誰が所有しているかを監査し、コンプライアンス レポートをまとめる際には、分析的なアプローチをとることが重要です。単にバグを見つけるのではなく、バグを引き起こした特定のコミットを詳しく調べ、同時に他に何が変更されたかを確認し、それらの変更が関連ファイルにどのように波及するかを理解します。
コード分析のための重要な Git 概念
まず、次のことに慣れてください。
- コミット:コードの変更を表す個別のスナップショット。
- 支店:開発の並行ライン。機能や実験を分離するのに役立ちます。
- タグ:歴史上の特定の時点のマーカー。多くの場合、リリースされます。
- マージ:ブランチを統合し、多くの場合、競合を解決します。
- 相違点:何が変更されたかを示すファイルまたはコミットの比較。
- 非難：著者を行ごとに追跡します。
これらのツールを使用すると、リポジトリの履歴を簡単に調べて、探しているものを正確に見つけることができます。
ファイルの各行を最後に変更したのは誰かを調べたいとします。その方法は次のとおりです。
gitblame src/main.py
これにより、コードのどの行が変更されたのか、誰がいつ変更を加えたのかが正確に表示されます。これは、プロジェクト内の特定の動作やバグの原因を追跡するのに便利な方法です。
2026 年になっても Git バージョン管理が重要である理由
チームワークとコードレビューをよりスムーズに
最大 50 人の開発者からなるチームを管理している私は、コード レビューのスピードアップに関しては、git log、gitblame などのツールや詳細なダッシュボードがゲームチェンジャーであることに気づきました。開発者が頭を悩ませたり、誰が特定の変更を加えたかを追跡したりする代わりに、これらのツールは推測を排除します。 2025 年の GitHub DevOps レポートによると、高度な Git 分析を使用するチームはレビュー時間の約 30% を削減し、エンジニアが真の創造的で影響力の高い作業に集中できる余裕を与えています。
規制分野における監査とコンプライアンス
これは、トレーサビリティを無視できない金融、医療、政府などの分野で最も重要であることは間違いありません。私はかつて財務クライアントと協力して厳しい監査ルールを管理していましたが、Git 履歴をタグにリンクすることで、監査の準備時間を半分に短縮することができました。すべてのコミットは JIRA チケットに直接関連付けられており、明確なレビューがあったため、苦労せずにコーディング標準および規制への準拠を証明することがはるかに簡単になりました。
インシデント対応における根本原因の追跡
運用上の問題が発生した場合は、その原因を迅速に見つける必要があります。私は、問題の原因となっている正確なコミットを特定するために、数え切れないほど git bisect を利用しました。一度は、扱いにくいマイクロサービスのセットアップにおいて、デバッグ時間を 2 日からわずか 2 時間に短縮するのに役立ちました。責任とログを迅速に選別することで、ダウンタイムが減り、より早く物事を軌道に戻すことができます。
データ サイエンスと ML モデルのバージョンの管理
最近では、コードの管理だけでなく、データのバージョンの追跡にも Git を利用するデータ サイエンス プロジェクトが増えています。ブランチとコミット間の違いを詳しく調べることで、チームはモデルの変更を追跡し、機能がどのように設計されたかを把握し、パラメーターの微調整を見つけることができます。 DVC などのツールは、データセットをよりスムーズに処理するために Git 上に構築されていますが、Git が単独でどのように動作するかをしっかりと理解することは依然として不可欠です。
Stack Overflow の 2024 年のデータによると、機械学習チームの 3 分の 1 以上が Git 分析をワークフローに直接組み込んでいます。これにより、実験を常に把握し、モデルの進化を追跡することができ、恐ろしい「ブラックボックス」シナリオを回避し、結果を後で確実に繰り返すことができます。
Git 分析が実際にどのように機能するか (詳細)
Git のコアの詳細: コミット、ツリー、BLOB
Git は、いくつかの重要な構成要素から構築されたシステムであり、各構成要素は一意のハッシュ (古いバージョンでは SHA-1、Git 2.35 以降を使用している場合は SHA-256) によって識別されます。 BLOB はファイルのコンテンツを保持し、ツリーはディレクトリのコンテンツをマップし、コミットはこれらのツリーを作成者、メッセージ、以前のコミットへのリンクなどの情報と結び付けます。これらのオブジェクトは一度作成されると変更されないため、Git はプロジェクト履歴のあらゆる瞬間を正確に再現できます。
Git が履歴を追跡しアクセスする方法を理解する
Git は履歴を有向グラフのように扱い、各コミットがその先行するコミットにリンクされます。 git log を実行すると、このネットワークを経由して変更の痕跡が表示されます。 Git はバックグラウンドでパックファイルを使用してこれらのスナップショットを効率的に保存します。パックファイルはデータを圧縮して、データが蓄積しすぎないようにします。ただし、ここに落とし穴があります。大規模なリポジトリを操作している場合 (数百万のコミットを考えてください)、それらのパックファイルとリポジトリ全体のサイズにより、git log コマンドの速度が遅くなる可能性があります。すべてをコンパクトに保つことと、履歴に素早くアクセスすることとの間でバランスをとる必要があります。
履歴を詳しく調べるための主要な Git コマンド (log、diff、blame、bisect)
git ログ過去のコミットをリストし、作成者、日付、またはメッセージのキーワードでフィルタリングできます。git diffコミット、ブランチ、または作業ファイル間の変更を比較します。責めるファイルに行ごとにコミット情報の注釈を付けます。git bisectコミット履歴をバイナリ検索して、バグを引き起こしているものを見つけられるようにします。
git bisect の動作を簡単に見てみましょう。 git bisect start でプロセスを開始します。次に、 git bisect bad を使用して現在のコミットを不良としてマークし、 git bisect Good の後にタグまたはコミット ID (v1.2.3 など) を付けて既知の良好なコミットを指定します。その後、Git はこれらのポイントの中間にあるコミットをチェックアウトします。このコミットをテストして、それが良いか悪いかを Git に伝えます。問題のあるコミットが見つかるまで絞り込み続けます。これは二分探索に似ていますが、バグを検出するため、手作業での探索作業を大幅に節約できます。
Git フックとカスタム スクリプトでコード分析を強化する方法
Git フックは、コードのコミットやプッシュなど、特定のアクションが発生したときに自動的に実行される小さなスクリプトです。これらは、コミットメッセージにルールを適用したり、簡単なコードチェックを実行したり、何かがマージされる前に有用な統計を収集したりするなど、物事をクリーンに保つのに非常に便利です。プリプッシュ フックは、コミット サイズを完了前にチェックするのに最適で、ポストコミット フックは、時間の経過とともにどれだけコードが変更されるかを追跡するのに役立ちます。これは、技術的負債が忍び寄る可能性がある時期を特定する賢い方法です。
始め方: 簡単なステップバイステップガイド
コンピュータに Git をインストールしてセットアップする方法
Git を初めてセットアップする場合、または初めてセットアップする場合は、バージョン 2.40.x を入手することをお勧めします。最も安定したリリースであり、問題なくスムーズに動作します。
Ubuntu/Debian の場合:
ターミナルを開いて「sudo apt-get install git」と入力するだけです。素早くてとても簡単です。
MacOS を使用している場合、最も簡単な方法は Homebrew を使用することです。
ブリューインストールgit
バージョンを確認します:
git --version
画面に次のような内容が表示されるはずです。
git バージョン 2.40.1
分析のためにリポジトリのクローンを作成してアクセスする方法
まず、プロジェクト リポジトリのコピーをローカル マシンに直接取得します。
ターミナルで次のコマンドを実行するだけです: git clone https://github.com/your-org/project.git
CDプロジェクト
エイリアスを使用して頻繁に実行する分析コマンドを高速化する
エイリアスを使用すると、入力時間を節約できるだけでなく、チームの全員がコマンドについて同じ認識を保つことができます。
これを ~/.gitconfig ファイルにポップするだけです。
[別名] lg = log --oneline --graph --decorate --all b = 責める s = ステータス 概要 = !git log --stat -1
次のコマンドを使用して構成をリロードします。
git config --global alias.lg "log --oneline --graph --decorate --all" を使用して便利なショートカットを設定すると、コミット履歴を簡単に表示できるようになります。
現在、「git lg」と入力すると、コミットのカラフルで詳細なグラフが表示されます。これにより、際限なくログをスクロールすることなく、何が起こっているかを簡単に確認できます。
Git を Jupyter や VSCode などのツールと併用する
データ サイエンス パイプラインに取り組むとき、VSCode の GitLens 拡張機能が非常に便利であることがわかります。これにより、誰がいつ何を変更したかをコード エディター内で確認できます。また、Jupyter Notebook の場合、nbdime などのツールを使用すると、バージョン間の差分を表示することで変更を追跡しやすくなり、Git ワークフローにうまく適合します。
私の機械学習プロジェクトでは、これらのツールといくつかのカスタム Git ショートカットを組み合わせることで、実験の追跡とトラブルシューティングがはるかに簡単になりました。コード履歴を調べる時間を何時間も節約できました。
スムーズな制作のためのヒントとベストプラクティス
コミットメッセージを明確で役立つものにしましょう
私は、コミットメッセージが曖昧すぎたり、関連する問題へのリンクが抜けていたために、大きなプロジェクトが混乱に陥るのを見てきました。一貫したコミット スタイル、または単純なテンプレートを使用すると、大きな違いが生まれます。明確なメッセージは、 git log --grep などのコマンドを使用して変更を追跡するのに役立ち、実際に何が変更されたかを把握しようとするときのコード レビューの苦痛を軽減します。
レビューを簡素化する分岐戦略を選択する
GitFlow は、リリース サイクルと緊急の修正を両立させるチームによって依然として地位を保っています。機能ブランチに取り組むことで物事が整理整頓され、圧倒されることなく新機能や変更点に焦点を当てることができます。私が取り組んだプロジェクトでは、GitFlow を使用することでコミット履歴がより明確になり、マージの問題が軽減されました。その両方のおかげで、ログを掘り下げて誰が何を変更したかを追跡することがはるかに簡単になりました。
リポジトリをクリーンアップするルーチンを設定する
特に大きなバイナリや大量のブランチを扱っている場合、リポジトリはすぐに大きくなる可能性があります。 git gc を実行し、古いブランチを時々削除すると、リポジトリのサイズを大幅に削減できます。15 ～ 20% 小さくなると考えてください。つまり、コマンドが高速になり、ディスクへの負担が軽減され、常に勝利したように感じられます。
git gc --aggressive --prune=now
Git フックを使用してチェックを自動化する
commit-msg のようなフックを設定して、コミット メッセージが正しい形式に従っていること、または必要なタグが含まれていることを確認できます。さらに、大規模なコミットを阻止したり、欠落したテストが侵入するのを防ぐプリプッシュ フックもあります。これらのチェックを自動化すると、人的ミスが削減され、Git 履歴がクリーンな状態に保たれるため、追跡と分析が容易になります。
よくある間違いとそれを避ける方法を学んだ方法
一度に多くのことを直そうとする
私はかつて、500 以上のファイルにわたる変更を一度にコミットするリポジトリを引き継いだことがあります。 git bisect でバグを見つけようとするのは、流砂の中を歩いているような気分でした。すべてのステップで大規模なテストを実行する必要がありました。現在、私は常に自分の作業を小さく集中的なコミットに分割し、後で問題を追跡しやすくしています。信じてください、それは頭痛を軽減します。
マージ競合を無視する場合の問題と、それによってコミット履歴が台無しになる仕組み
適切な競合解決を省略すると、私が「マージ コミット スパゲッティ」と呼んでいるものにつながります。これは、Git 履歴が複雑に絡み合い、ログの検査や行の非難が本当に頭の痛い問題になります。複数の修正が互いに衝突する場合は、マージの実践をしっかりと行い、それらのレビューを取り入れることが重要です。信じてください、クリーンな履歴が将来の混乱からあなたを救います。
大規模なチームで git のせいにするのは間違っています: それが思っているよりも複雑である理由
Gitblame は行に触れた最後のコミットを指しますが、それは単なる小さな書式修正または無関係である可能性があります。歴史を本当に理解するには、git log -L と並行して、blame を確認する必要があります。これにより、特定の行への変更を経時的に追跡できます。
トレーニングが限られているため、Git の分析ツールを利用できない
チームを指導した私の経験から言えば、ほとんどの人は実際に練習するまで、Git の分析機能がどれほど強力であるかわかりません。時間をかけてこれらのコマンドをチームに説明し、いつ使用するかについては大きな成果が得られます。それをスキップすると、いくつかの貴重な洞察を見落とす可能性があります。
実際の例と成功事例
ケーススタディ 1: Git Bisect を使用して重大な本番環境のバグを追跡する
SaaS 企業では、API レイテンシが突然 40% 増加していることに気づきました。これは大きな危険信号でした。 git bisect を使用して、データベース クエリの遅さを引き起こす 3 週間前に行われたコミットまで問題を追跡しました。これが修正されると、平均 API 応答時間は 200 ミリ秒短縮され、エラー率は 15% 低下しました。それは私たちを多くの頭痛の種から解放してくれた直接的な勝利でした。
リモート チームで Git Blame を使用してコードの所有権を追跡した方法
25 人のエンジニアからなるリモート チームと協力した結果、gitblame と自動化されたコード レビュー ダッシュボードを組み合わせることが状況を一変させることがわかりました。これにより、コードのどの部分に誰が責任を負っているのかを特定できるため、コードを実際によく知っているレビュー担当者を割り当てることができました。結果？コードレビューは 25% 高速化され、速度を低下させるボトルネックが減りました。
データ サイエンス プロジェクトにおけるバージョン管理と監査モデルの管理
機械学習プロジェクトを主導しながら、Git と DVC を統合してデータセットとモデルのバージョン管理を管理しました。コミット履歴を詳しく調べることで、すべてのモデルの微調整が特定のデータ バージョンと特徴量エンジニアリングの変更にまで遡ることができるようになりました。これにより、監査が容易になっただけでなく、再現性が 40% 向上しました。これはチームにとって大きな勝利でした。
ワークフローに不可欠なツールとライブラリ
便利な分析機能を備えた Git GUI ツール (GitKraken、SourceTree)
コマンドラインに詳しくない場合は、GitKraken のようなツール (現在 Git 2.40 以降をサポート) を使用すると、コミット履歴を簡単に調べることができます。明確な視覚的なコミット グラフ、便利な責任ビュー、さらには問題トラッカーも表示されるため、コマンドに迷うことなくコードの背後にあるストーリーを確認できます。
コマンドライン ツール (tig、git-extras) を使用して Git ワークフローを強化する
tig はターミナル内で動作する気の利いたテキストベースのインターフェースです。ログをスクロールしたり、差分を確認したり、最後に行を変更した人を追跡したりするのに最適です。これは、単純な git コマンドよりもはるかにインタラクティブに感じられ、詳細を見逃すことなくコマンド ラインを快適に使用したい場合に救世主となります。
git-extras は、各作成者ごとにコミット統計を分類する git summary など、ワークフローをスムーズにする便利なコマンドを提供します。
gitの概要
リポジトリに誰が貢献したかのスナップショットが表示されるので、チームのアクティビティを一目で把握することが簡単になります。
CI/CD および品質ツールとの接続 (SonarQube、Jenkins)
ほとんどの CI パイプラインは Git 分析と連携して、コードの品質を監視し、リグレッションを早期に発見します。 SonarQube を例に挙げると、Git データを詳しく調査することで、特定のコードの臭いやバグを導入したのが誰であるかを追跡し、どの問題を最初に修正する必要があるかを判断しやすくなります。
共同分析ツール (GitHub Insights、GitLab Analytics)
最近では、GitHub や GitLab などのプラットフォームが、コミットの頻度、プル リクエストのレビューの早さ、コードの変更量などに関する便利な統計を提供します。これらの数値をローカルの Git チェックと組み合わせると、チームをより効果的に管理するための明確な全体像が得られます。
Git バージョン管理: 競合他社との違い
Git 対 SVN および CVS: 分析上の強みについての考察
Git は、DAG 構造とローカルで履歴全体にアクセスできる機能で際立っており、これにより特定の行やコミットをより簡単に調べることができます。一方、SVN と CVS は一元化されたシステムに依存しており、変更が正確に発生した場所を追跡するという点では同じ深度を提供しません。そのため、詳細な調査は少し面倒になる可能性があります。
Git と Mercurial の比較: それらの起源と違いを見てみる
Mercurial には同様の機能が組み込まれていますが、より単純なコマンド ラインで物事をよりシンプルにしています。一方、Git には、コード履歴を深く掘り下げるためのより大きなツール セットが付属していますが、最初はその複雑さに圧倒されるように感じるかもしれません。多くの場合、どれを選択するかは、チームがすでに知っていて好むものによって決まります。
ネイティブ Git ツール vs. 特殊なコード分析プラットフォーム
CodeScene や SourceGraph などのツールは、高度なメトリクス、AI 主導の洞察、および複数のリポジトリ全体を調べる機能を備えた強力な火力をもたらします。これらは大規模なコードベースを管理する場合には最適ですが、コストの上昇、ベンダーのロックイン、データ読み込み時の遅延など、特有の悩みも伴います。逆に言えば、Git の組み込みツールは無料で、その場で答えが必要なときにすぐに使用でき、視覚的または派手ではありませんが、はるかに高い柔軟性を提供します。
私の経験から言えば、管理可能な量のコードを扱う小規模から中規模のチームの一員である場合は、Git のネイティブ分析といくつかのコマンドライン ツールを組み合わせたものを使用することで、通常はうまくいきます。しかし、大企業の場合、より広範な組織全体の視野が必要な場合、専用プラットフォームは本当に付加価値をもたらすことができます。
よくある質問
Git を使用してバグを導入した人物を追跡する: どうすればよいですか?
やっかいなバグを探しているとき、git bisect は問題の原因となった正確なコミットを特定するための真の救世主となる可能性があります。焦点を当てたら、影響を受けるファイルまたは特定の行に対して gitblame を実行して、誰が変更を加えたかを確認します。これを git ログと組み合わせて全体像を把握し、関連する問題のチケットを追跡します。これは探偵作業のようなものですが、対象となるのはコードです。
コードの健全性を監視するために自動化された Git レポートを設定できますか?
絶対に！スクリプトや継続的統合ジョブをスケジュールして、git log や git diff などの git コマンドを実行したり、git-extras などのツールを利用したりすることもできます。これらは、何が変更されたか、何件のコミットが行われたか、誰が何に取り組んでいたかについての毎日のスナップショットをまとめることができます。さらに、これらを Slack や電子メールに接続すると、指を動かすことなくすぐに情報を得ることができます。
大きなリポジトリで gitblame が不十分な場合
gitblame は、各行に最後に誰が触れたかを示すのには優れていますが、変更の背後にあるストーリーはわかりません。場合によっては、コミットの目的がリファクタリング、再フォーマット、または空白の修正だけである場合、非難の結果が間違った道に進む可能性があります。これを回避するには、 --ignore-rev オプションを使用してノイズの多いコミットをスキップするか、 gitblame と git log -L を組み合わせます。これにより、行履歴をより正確に追跡できます。
分析を改善するために Git でバイナリ ファイルを管理する
Git の組み込み分析ツールは、差分や非難情報が実際には適用されないため、バイナリ ファイルをあまりうまく処理できません。バイナリを操作する場合は Git LFS を使用し、バイナリ アーティファクトのバージョン管理と分析を管理するために特別に設計された別のツールを利用することをお勧めします。
マージ競合のパターンを追跡できますか?
Git の標準コマンドから直接のものではありません。しかし、マージ コミットのログを詳しく調査し、それを CI/CD パイプラインからのデータと組み合わせると、競合が繰り返し発生する領域を特定し始めることができます。コード内の競合マーカーをスキャンするカスタム スクリプトを作成すると、これらの問題点を強調するのに役立ちます。
まとめと次のステップ
Git バージョン管理を使用してコード履歴を分析することは、プロジェクトがどのように進化したかを実際に理解するための便利で労力の少ない方法です。デバッグを高速化し、チームのコラボレーションをよりスムーズにし、コンプライアンスを支援し、さらにはデータ サイエンスを扱う場合には付加価値を与えることができます。 Git の組み込みコマンドをいくつかの実用的な習慣やツールと組み合わせると、ほとんどのプロジェクトでうまく機能する強固なセットアップが得られます。
とはいえ、これは万能の解決策ではありません。巨大なリポジトリや複雑な分析タスクには、より高度なプラットフォームやカスタム ツールが必要になる場合があります。私のアドバイスは？小さなことから始めましょう。通常のワークフローの一部として git log、gitblame、git bisect を快適に使用できるようにしましょう。自信がついたら、チームが成長し、ニーズがより複雑になるにつれて、フック、エイリアス、統合などを徐々に追加できます。
ここで説明したコマンドとワークフローを試してみることを強くお勧めします。テスト設定で試してみたり、エディターやデータ ツールにリンクしたりすると、フィードバック サイクルがより速く、よりスムーズになることがわかります。
Git ワークフローとそれがデータ サイエンスにどのように適合するかに関するさらに便利なヒントが必要な場合は、ニュースレターにサインアップしてください。さらに、ソーシャル メディアで私をフォローして、定期的な最新情報やより深い情報を入手してください。このことを学ぶ最善の方法は、袖をまくり上げて試してみることです。思ったよりも早くコツを掴むことができます。
これに興味がありますか？このガイドを参照してください: Mastering Git Branching Strategies for Large Teams — そこに役立つヒントが見つかるかもしれません。
データ パイプラインで Git をスムーズに動作させたい場合は、「機械学習プロジェクトのための実践的なデータ バージョニング テクニック」を参照してください。これは、頭を悩ませることなくすべてを同期させる方法を明確にする便利なガイドです。
このトピックに興味がある場合は、こちらも役立つかもしれません: http://127.0.0.1:8000/blog/mastering-network-security-essential-tips-for-beginners