Linuxの「Git」のような更新管理を実現するにはどうすればよいですか？
Linuxシステムの更新を、「リビジョン」内で前後に移動できるようにすることで、 Git と同様の方法で管理したいと思います。どうすればそれができますか？
NixOS を参照する必要があります。これは、 Nixパッケージマネージャー を使用します。
NixOSは、システム構成管理の最先端技術を向上させることを目的としたGNU/Linuxディストリビューションです。既存のディストリビューションでは、アップグレードなどのアクションは危険です。パッケージをアップグレードすると他のパッケージが破損する可能性があり、システム全体のアップグレードは最初から再インストールするよりもはるかに信頼性が低く、構成変更の結果を安全にテストすることはできません。システムへの変更などを簡単に元に戻すことはできません。
これはあなたの質問にはやり過ぎかもしれませんが、システムレベル/大規模な変更を元に戻すことができる最も簡単な方法はスナップショットです：
https://en.wikipedia.org/wiki/Snapshot_%28computer_storage%29
リグの詳細については触れていませんが、gitに精通しているので、もっと複雑なファイルシステムの使用に興味があるかもしれないと想像するのはそれほど難しいことではありません。次世代のファイルシステムを使用する場合（クリックベイトの名前は無視してください）、端末にコマンドを入力するだけで、システム全体を完全に「巻き戻す」ことができます。加えられたすべての変更は、ごくわずかな遅延/労力で元に戻されます。 ZFSが最善の策であり、この驚くべきArsの記事を参照して、それがあなたにとって価値のあるものであるかどうかを確認できます（他にも多くの優れた機能があります）。
「更新」の意味によっては、 etckeeper のような構成管理ツールに興味があるかもしれません。これにより、システム構成への変更を自動的に記録し、以前の構成に戻すことができます。
Gitが使い慣れたツールであり、「更新」とは「システムパッケージの更新」や「サーバーに保存されているすべてのファイルの更新」ではなく、「システム構成の更新」を意味する場合、これがあなたが探しているものかもしれません。ために。
Puppet、Ansible、Etckeeperなどのツールを使用しているかどうかに関係なく、データを失うことなくクリーンに「ロールバック」できるとは限りません（たとえば、別の回答で説明されているように、スナップショットを作成する必要があります）。適切なアプローチは状況によって異なります（たとえば、スナップショットは、ロールバック時に顧客の注文を失う可能性がある本番システムには適していません）。
私は過去に OpenVMS を使用しましたが、デフォルトでは バージョン管理ファイルシステム が付属しています。
Puppetのようなツールが十分に機能しない場合は、バージョン管理ファイルシステムが探しているものかもしれません。
本当にgitのようにシステム全体（カーネルバージョンを含む）を管理したい場合は、 NixOS を探しています。
あまり関与しないバージョンでは、ほとんどすべてのUNIXからNixOSのパッケージマネージャーであるnixを使用できます。 Nixは単純なユーザーとしてインストールできますが、rootとしてインストールする方が簡単です。 nixをインストールすると、それを使用して非特権ユーザーとしてパッケージをインストールでき、既存のパッケージマネージャーと競合することなく正常に実行されます。また、システムからnixを完全に削除することも非常に簡単なので、試さない理由はありません。 ;-)
質問に直接対処するために、Nixは、インストールされたシステム全体を環境として定義します。これは、git commitのように、インストールされたすべてのパッケージの非常に特定のバージョンへの一連のポインターへのポインターです。
Nixがパッケージをアップグレードすると、新しい環境が作成されます。この環境は、パッケージへの新しいポインターのセットを指します（ほとんどの場合、更新されていないパッケージの既存のポインターを指します。これも、新しいgit commitと非常によく似ています。以前の変更されていないファイルと変更されたファイルのいくつかの新しいバージョンを指します）。
もちろん、以前のバージョンの環境に切り替えるのは簡単で、フォークする（つまり、最後より古い環境に基づいて新しい環境を作成する）と私は信じています。特定のシェルの環境をロードできるため（実際には、シェルで使用できる環境変数のセットであるため、名前が付けられています）、同じマシン上のプロジェクトごとに異なる環境を簡単に作成することもできます。無関係なプロジェクトには別のバージョンのライブラリが必要なので、依存関係の問題はもうありません。
NixOSはそれを次のレベルに引き上げ、カーネルを含むコンピューター全体を同様の方法で管理し、マシン全体の非常に低リスクのアップグレードを可能にします。
私はそれらすべてを読み終えていませんが、Nixの紹介として 致命的なNixピル をお勧めします。
実験的なタイプの場合は、ファイルシステム全体をローカルのgitリポジトリにチェックインしてみてください。これは...面白いと思います。
- ルートディレクトリ内の
git init/ - 内容が頻繁に変更される、またはチェックインされるべきではないディレクトリを無視するルートの.gitignoreを作成します：
- / dev
- / run
- / tmp
- / proc
- / lost + found
- .。
- 除外したい特定のファイルタイプを.gitignoreに追加します：
- * .tmp
- *。ログ
- .。
git add -A .で初期コンテンツを追加します- スナップショットを
git commit -m "Initial Snapshot"でコミットします - コンピューターを使用する
- スナップショットを定期的に追加する
git commit -Am "Snapshot X"または同様のもの
いくつかの利点は次のとおりです。
gitkやgit diffなどの改訂履歴用の使い慣れたツール- Gitを備えたlivecdまたはその他のオペレーティングシステムは、バックアップを復元できます
- システム全体をgithubにプッシュして他のマシンに復元したり、他の人と共有したりできます...？
- 分岐は高速で直感的です
- ルート内の/、gitディレクトリは、ソースコードと同様に、システムを悪用し、より冒険的になる自信を刺激します。
- 後続の各スナップショットは、他のいくつかのバックアップソリューションと比較して比較的小さくなります
- / etcの構成変更を確認および追跡するのに最適です
- これを開拓し、linit-linux ingitと呼ぶことができます。
- 汚名
いくつかの奇妙なことが含まれる可能性があります：
- 大幅な変更、またはシステムの実行中に使用されているファイルへの変更を伴うブランチまたはリビジョンを復元/チェックアウトできる可能性は低いです-おそらく、この目的のためにgitを備えた最小限のブートUSBがあります
- かなり大きな初期コミット
- 後続の.gitディレクトリでチェックイン-？
gitは、ルートgitコンテナにネストされたソースコードディレクトリにいるときに、期待どおりに機能することを願っています。- / etc/passwdと/ etc/shadowをリポジトリに含めて、ユーザーを維持および追跡し、他のマシンに復元する必要がありますが、ビューアクセス（おそらくgithub上）を持つ誰もがコンテンツ、権限、ユーザーのパスワードハッシュ。