🖐🏾 👧 👨‍👩‍👧‍👦 Gitリポジトリを安全に管理するための6つのベストプラクティス 🏇🏿 😶 🎪

コードベースの管理を困難にするリポジトリやその他のアクティビティが雑然としないようにします。代わりに、ベストプラクティスを使用して、物事をより簡単にします。

リポジトリ内のソースを調べると、アプリケーションのセキュリティレベルを評価できます。しかし、誰もコードを見ていなければ、問題は大きくなるだけです。幸い、GitHubには独自のセキュリティ専門家がいて、最近いくつかのGitリポジトリでトロイの木馬を発見しました。何らかの理由で、彼はこれらのリポジトリの所有者に気づかれませんでした。自分のリポジトリを管理する方法を他の人に指示することはできませんが、彼らの過ちから学ぶことができます。この記事では、リポジトリーを操作するための便利な手法について説明します。

リポジトリを探索する

これはおそらく最も重要な推奨事項です。自分でリポジトリを作成したか、それを自分に渡したかに関係なく、リポジトリの内容を知ることは重要です。少なくとも、管理するコードベースの基本コンポーネントを知っている必要があります。数十回のマージ後にランダムなファイルが表示された場合、問題が発生するため、簡単に見つけることができます。次に、それをチェックアウトして理解し、その後、その運命を決定する必要があります。

バイナリを追加しないようにしてください

もともとGitは、C、Python、Javaコード、JSON、YAML、XML、Markdown、HTMLなどのテキストファイル用に設計されていました。

$ cat hello.txt
This is plain text.
It's readable by humans and machines alike.
Git knows how to version this.

$ git diff hello.txt
diff --git a/hello.txt b/hello.txt
index f227cc3..0d85b44 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,3 @@
 This is plain text.
+It's readable by humans and machines alike.
 Git knows how to version this.

Gitはバイナリが好きではありません。

$ git diff pixel.png
diff --git a/pixel.png b/pixel.png
index 563235a..7aab7bc 100644
Binary files a/pixel.png and b/pixel.png differ

$ cat pixel.png
 PNG
▒
IHDR7n $gAMA  
               abKGD݊ tIME 

                          -2R  
IDA c` ! 3%tEXtdate:create2020-06-11T11:45:04+12:00  r.%tEXtdate:modify2020-06-11T11:45:0

バイナリファイルのデータは、プレーンテキストと同じ方法で解析できないため、バイナリで何かが変更された場合、完全に上書きする必要があります。

さらに悪いことに、バイナリデータを自分でチェック（読み取りおよび解析）することはできません。

通常のPOSIXツールに加えて、git diffを使用してバイナリを見つけることができます。 --numstatオプションを指定してdiffを実行しようとすると、Gitはnullを返します。

$ git diff --numstat /dev/null pixel.png | tee
-     -   /dev/null => pixel.png
$ git diff --numstat /dev/null file.txt | tee
5788  0   /dev/null => list.txt

リポジトリにバイナリを追加することを検討している場合は、立ち止まって考えてください。ビルドプロセス中にバイナリが生成された場合、なぜそれをリポジトリに追加するのですか？これを行うのが理にかなっていると判断した場合は、必ずREADMEファイルまたは同様の場所に、バイナリを保持する理由とそれらを更新するためのプロトコルを記述してください。BLOBに変更を加えるたびに、ストレージスペースが2倍になるため、更新は慎重に行う必要があります。

サードパーティライブラリはサードパーティのままである必要があります

オープンソースの多くの利点の1つは、自分で記述していないコードを自由に使用および再配布できることですが、独自のリポジトリでサードパーティのライブラリをホストしないことには多くの正当な理由があります。まず最初に、ライブラリが信頼できることを確認するために、このすべてのコードとその更なる更新を個別にチェックする必要があります。次に、サードパーティのライブラリをGitリポジトリにコピーすると、メインプロジェクトからフォーカスが移ります。Gitサブモジュール

を使用して、外部依存関係を管理します。

盲目的にgit addを使用しないでください

プロジェクトが正常にコンパイルされた場合は、git addコマンドを使用したいという衝動に抵抗してください。（たとえば、「。」は現在のディレクトリです）。これは、プロジェクトを手動でコンパイルするのではなく、IDEを使用してプロジェクトを管理する場合に特に重要です。IDEがプロジェクトを管理しているときに、リポジトリに追加された内容を追跡することは非常に困難です。したがって、自分で作成して追加の準備をしたものだけを追加し、プロジェクトフォルダーに不思議な形で表示された新しいオブジェクトは追加しないことが重要です。

したがって、git addを実行する前に、リポジトリに何が追加されるかを確認してください。見慣れないオブジェクトが表示された場合は、それがどこから来たのか、make clean（または同等のコマンド）を実行した後もオブジェクトがプロジェクトディレクトリに残っている理由を調べてください。

Git無視を使用する

典型的なプロジェクトディレクトリには、多くの隠しファイル、メタデータ、および不要なアーティファクトが含まれています。これらのオブジェクトは無視する方がよいでしょう。存在するオブジェクトが多いほど、この「ゴミ」に邪魔され、重要または危険なものを見逃す可能性が高くなります。

gitignoreファイルを使用すると、不要なものを除外できます。Github.com/github/gitignoreは、あなたのプロジェクトにダウンロードしてホストすることができますいくつかのカスタムgitignoreテンプレートを提供しています。たとえば、Gitlab.comはそのようなテンプレートを数年前に提供しました。

適度なコードベースの変更

プルまたはプルリクエストを受け取ったとき、または電子メールでパッチを受け取ったときは、すべてが正常であることを確認する必要があります。あなたの仕事は、コードベースに入ってくる新しいコードを研究し、それが何をするかを理解することです。その実装に同意しない場合、またはさらに悪いことに、この実装を理解していない場合は、送信者にメッセージを書き込んで説明を求めてください。プロジェクト内の場所を主張する新しいコードを学ぶことには何の問題もありません。さらに、ユーザーの利益のためにそれを行います。この場合、ユーザーは、受け入れている変更とその理由を明確に理解します。

責任を取る

オープンソースソフトウェアを安全に保つことはコミュニティの仕事です。コードベースを探索し、混乱を防ぎ、複製したリポジトリ内の潜在的なセキュリティ脅威を無視します。Gitは強力ですが、それは単なるコンピュータプログラムであるため、最終的にはリポジトリを管理する責任はあなたにあります。

Gitリポジトリを安全に管理するための6つのベストプラクティス