ネットワークアクセスなしで複数のシステムでGitを使用する


84

バージョン管理を使用したいのですが、セキュリティ上の理由により、作業中のサーバーにはインターネットアクセスがありません。USBフラッシュドライブ上のファイルのみを移動できます。このセットアップでGitを引き続き使用できますか?Gitリポジトリに適用できる小さなパッチを作成できますか?


65
タイトルにはネットワークアクセスなし、質問にはインターネットアクセスなし、と書かれています。大きな違い。
tkausl

7
@TutuKaeenインターネットに接続されていないローカルネットワークを持つことができます。したがって、github.comの代わりに、たとえばgitサーバーをセットアップします。192.168.1.100と他のすべてが同じように動作します。
Agent_L

12
@TutuKaeen:重要な問題は、2つのマシン間で直接(または間接)ネットワーク通信が可能かどうかです。あなたの場合、両方のマシンはネットワーク化されていますが、ネットワークは分離されていますか?その場合、質問にその情報を編集してください。
sleske

15
@TutuKaeenあなたの質問は不明のままです。バージョン管理を使用したいと言いますが、コメントでは、本番環境への展開に役立つことを要求しています。これらの問題は常に重複するとは限りません。以下に良い答えがあると思いますが、将来的にはあなたの質問があなたの要件についてより包括的である場合に役立つでしょう:「バージョン管理を使用したい、私の開発マシンはインターネットにアクセスできません、ネットワークにはアクセスできますが、実稼働マシンにはアクセスできません。バージョン管理からコードを実稼働マシンに移動する方法を知りたいのです。」
-DavidS

4
serverどのネットワークにも接続されていないマシンを表す用語を使用するのは奇妙に思えます。インターネットにアクセスしなくても、ローカルネットワークでもかまいませんが、それでもネットワークのままです。
パトリックグレゴリオ

回答:


157

確かに、特定のプロトコルを必要とするGitについては何もありません。すぐに使用できる標準クライアントは、 HTTP(S)、SSH、カスタムGitプロトコル、そして重要なことにローカルプロトコルをサポートしています。これは、ローカル.gitディレクトリへのパスを取得します。ローカルディレクトリは、作業ディレクトリ(/path/to/project/.git)またはベアディレクトリ(/path/to/project.git)内にありますが、命名は単なる規則です。

これは、もちろん、フラッシュドライブをリモートとして追加できることを意味します。

git remote add origin /mnt/flashdrive/foo.git

または、Windowsの場合:

git remote add origin F:\foo.git

または、別の名前で追加のリモートとして追加することもできます(originインターネットサーバーをどこかに向けたい場合)。

git remote add flashdrive /mnt/flashdrive/foo.git

次に、他のリモコンと同じように、このリモコンにプッシュ/プルすることができます。

ドキュメントを読むと、file://少し異なる動作をするプロトコルもあります。追加の最適化を利用するため、ローカルパスを使用することをお勧めします。file://プロトコルを使用する場合、gitは標準のネットワークコンポーネント(ローカルディスクと通信するため)を使用するため、速度が低下します。


50
この例外的な答えに追加するには-フラッシュドライブの「裸の」リポジトリを使用して調査することも価値があります。「むき出しの」リポジトリには作業ツリーがないため、OPのユースケースのように聞こえる共有の「権限のポイント」として使用する場合、潜在的な問題のカテゴリを切り取ります。
鉄グレムリン

5
file://また、もう少し柔軟です。ローカルパスではできないいくつかの機能(浅いクローンなど)を使用できます。
オースティンヘメルガルン

1
@IronGremlinこの「権限の共有ポイント」の概念を拡張できますか?私はGitの専門家ではありませんが、それがどういう意味なのか興味があります。
軌道上の明るさのレース

2
@LightnessRacesinOrbit-これはかなり密集したトピックですが、基本的にはgitが配布されているため、誰もが独自の履歴を取得できます。AはBに履歴のバージョンを尋ねることができますが、Cが誰かに言わない限り、そのことを知りません。「信頼できる」履歴を保存する単一のリポジトリがあるということは、Dが履歴の情報センターとして機能することを意味します。したがって、Aは変更についてDに通知し、BとCはDに連絡して最新情報を入手することを知っています。適切な例として、OPのサーバーがCで、フラッシュドライブがDの場合、サーバーがA / Bインタラクションから除外されないようにします。
鉄グレムリン

6
@LightnessRacesinOrbitここで重要なのは、bareが信頼できることを意味する必要はなく、そのコンテキストで役立つことです。たとえば、作業ツリーがないため、ディスクスペース(または帯域幅)のフットプリントが小さいため、これも便利です。これは、現在よりもはるかに重要な地獄でしたが、まだ登場しています。
鉄グレムリン

46

上の単一のコンピュータ、何も特別なことは必要ありません。git init目的のディレクトリで実行し、通常どおりGitを操作します。

複数のコンピューター間でリポジトリーを同期するには、いくつかの方法があります。

方法1a(ネットワークがまったくない): USBスティックに「ベアリポジトリ」を作成し、他のリモートリポジトリの場合と同じようにプッシュしてプルすることができます。言い換えれば、ローカルパスを介したリポジトリ操作は、SSHまたはHTTPS URLを介した操作と何も変わりません。

  1. 「リモート」リポジトリを作成します。

    $ git init --bare /mnt/Stick/Repositories/Large_Project.git
    
  2. コンピューター1で、すべてをプッシュします。

    $ cd ~/Large_Project
    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git push usb master
    
  3. コンピューター2でも、いつもと同じです。

    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git pull usb
    

(URLまたはパスから直接プッシュ/フェッチ/プルすることもできます。)

方法1b(内部ネットワーク): SSHを使用できる内部サーバーがあり、Gitがインストールされている場合、上記と同じことができます。[user@]host:pathまたは、ssh://[user@]host/path構文を使用してSSHアドレスを指定するだけです。

  1. git init --bare <somepath.git>指定されたサーバーで(SSHを介して)実行することにより、「リモート」リポジトリーを作成します。

  2. コンピューター1では、前述の方法と同じです。

    $ git remote add origin myserver.example.com:Gits/Large_Project.git
    

    または、必要に応じて:

    $ git remote add origin ssh://myserver.example.com/Gits/Large_Project.git
    
  3. コンピューター2でも、方法1aと同じです。


方法2:コミットの特定のリストを単一のファイルにアーカイブする「転送バンドル」を作成できます。

残念ながら、バンドルコマンドは前回最後にバンドルされたものを自動的に覚えていないため、手動でタグ付けまたはメモを保持する必要があります。git-bundleマニュアルから例を取り上げます。

  1. コンピューター1で、ブランチ全体のバンドルを作成します。

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle master
    $ git tag -f last-bundled master
    
  2. コンピューター2で、バンドルからリポジトリのように引き出します。

    $ cd ~/Large_Project
    $ git pull /mnt/Stick/Project.bundle
    

後続のバンドルは全体をパックする必要はありません。代わりにmaster新しく追加されたコミットのみをパックできますlast-bundled..master

  1. コンピューター1で、新しく追加されたコミットのバンドルを作成します。

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle last-bundled..master
    $ git tag -f last-bundled master
    
  2. 同上。


実際に、それはあなたがそれを何かが悪い行くたびに再作成することができますので、すべてのリポジトリは、全体の歴史を持っているとしても、Gitの何で「主」である、私の目的のために悪いことではないでしょう
チュチュKaeen

manual tagging or note-keeping is needed、レポは非常に大きい場合を除き1つのオプションですgit bundle create my.bundle --all、それはすべてのものを含める必要があります
birdspider

受け入れられた答えとこれが同じことを言っていても、それはより例示的であるため、私はこの答えがより好きです。
Rystraum

「裸」オプションの意味は何ですか?
軌道上の明るさのレース

1
「作業ツリー」(編集可能なファイル)なしで、データベース(通常は隠しフォルダーにあるもの)だけであるリポジトリーを作成します.git/。リポジトリの推奨形式ですgit push
悲しみ

20

git bundle create

方法の1つは、外部ストレージを使用してリポジトリ間でデータを交換することで、git bundleです。この方法では、転送ごとに1つのファイルのみがあり、中間のGitリポジトリはありません。

各「git push」はファイルの作成に変わり、「git fetch」はそのファイルから物を取得します。

デモセッション

最初のリポジトリを作成し、最初の「プッシュ」を行う

gitbundletest$ mkdir repo1

gitbundletest$ cd repo1

repo1$ git init
Initialized empty Git repository in /tmp/gitbundletest/repo1/.git/
repo1$ echo 1 > 1 && git add 1 && git commit -m 1
[master (root-commit) c8b9ff9] 1
 1 file changed, 1 insertion(+)
 create mode 100644 1

repo1$ git bundle create /tmp/1.bundle master HEAD
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 384 bytes | 384.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

2番目のリポジトリ(2番目のコンピューター)に「クローン」:

gitbundletest$ git clone /tmp/1.bundle repo2
Cloning into 'repo2'...
Receiving objects: 100% (3/3), done.

gitbundletest$ cd repo2/

repo2$ cat 1
1

いくつかの変更を行い、それらを別のバンドルファイルに「プッシュ」します。

repo2$ echo 2 > 1 && git add 1 && git commit -m 2
[master 250d387] 2
 1 file changed, 1 insertion(+), 1 deletion(-)

repo2$ git bundle create /tmp/2.bundle origin/master..master origin/HEAD..HEAD
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 415 bytes | 415.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

最初のリポジトリへの「プル」変更:

repo2$ cd ../repo1

repo1$ git pull /tmp/2.bundle 
Receiving objects: 100% (3/3), done.
From /tmp/2.bundle
 * branch            HEAD       -> FETCH_HEAD
Updating c8b9ff9..250d387
Fast-forward
 1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

repo1$ cat 1
2

最初のバンドルとは異なり、2番目のバンドルには部分的なGit履歴のみが含まれており、直接クローンできません。

repo1$ cd ..

gitbundletest$ git clone /tmp/2.bundle repo3
Cloning into 'repo3'...
error: Repository lacks these prerequisite commits:
error: c8b9ff94942039469fa1937f6d38d85e0e39893a 
fatal: bad object 250d38747656401e15eca289a27024c61e63ed68
fatal: remote did not send all necessary objects

バンドルを使用すると、各バンドルに含めるコミットの範囲を手動で指定する必要があるという欠点があります。とは異なりgit pushgit bundle以前のバンドルにあったものを追跡しません。手動で調整する必要があります。そうしないと、refs/remotes/origin/masterバンドルが本来よりも大きくなります。


--allすべてを取得するためにフラグに言及することを忘れないでください。レポジトリが十分に小さい場合は、毎回すべてを単純に転送するため、これが最も簡単なプロセスです!メモリスティックを緩めないでください-おそらく最大のセキュリティ問題!
フィリップオークリー

7

最初にGitをインストールする必要があります。次に、新しいリポジトリを作成するには、コピーしたフォルダー内で実行します。

git init

次に、バージョン管理に必要なファイルをgit add追加-aして(すべてのファイルに追加)、変更のコミットを開始できます(git commit)。

ローカル履歴(git log)で作業できるため、リモートにプッシュする必要はありません。

詳細については、次を確認してください。


インターネットなしでプッシュ/プル

git pushコマンドを使用して、SSHを介してプッシュすることができます(ローカル接続、イントラネットを使用):

git remote add server ssh://[user@]host.xz[:port]/path/to/dev/repo.git/
git push server

またはフォルダにプッシュ:

git push /mnt/usb/my_repo

これは、リポジトリの2つのコピーがあることを前提としています。

引っ張りと同じ、例えば

git pull /mnt/usb/my_repo

パッチ適用

パッチを適用するには、patchコマンドまたはを使用できますgit apply

参照:gitリポジトリからパッチまたはdiffファイルを作成し、別の異なるgitリポジトリに適用します


5

Gitはローカルでも使用できます。その後、コミットはローカルにのみ保存され、バージョン管理は引き続き可能です(また、diff / mergeなども可能です)が、他のコンピューターからリポジトリにアクセスすることはできません。

git initローカルフォルダで実行することにより、ローカルGitリポジトリを開始できます。ここで説明されているように


3
私が知っているが、私は別のコンピュータ上で動作していないインターネットアクセスサーバー上のファイルにそれを適用したいこと
チュチュKaeen

2
@TutuKaeenフラッシュドライブにリポジトリを配置し、それを別のコンピューターのハードドライブに複製/同期するだけで、何も問題はありません。ただし、「インターネットアクセスのないサーバー」は奇妙に聞こえますが、サーバーの目的はサービスを提供することです。ほとんどの場合、サービスはネットワークに関連しています(ただし、常にではありません)。
AnonymousLurker

2
@dhae-Gitをローカルで使用する方法について詳しく説明してください。それができることを示すだけでは、答えの助けにはなりません。
ラムハウンド

2
@anonymousLurkerは、非常に重要な機関のクローズドネットワークにデータを提供しています。データは非常にデリケートで、従業員専用であるため、広範なインターネットには何の役にも立ちません。
チュチュケーン

1
@TutuKaeen:それは持っている場合は任意のネットワークアクセスを、あなたは常にSSH経由で、独自のGitサーバーを実行することができます。Gitには、GitHubだけではありません。
悲しみ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.