Utilisation de Git sur plusieurs systèmes sans accès réseau

84

Je souhaite utiliser le contrôle de version, mais pour des raisons de sécurité, le serveur sur lequel je travaille n'a pas d'accès Internet: je ne peux déplacer des fichiers que sur une clé USB. Puis-je toujours utiliser Git avec cette configuration? Puis-je créer de petits correctifs que je peux appliquer sur un référentiel Git?

Tutu Kaeen
la source
65
Votre titre ne dit pas d'accès au réseau, votre question ne dit pas d'accès à Internet; une différence énorme.
tkausl
7
@TutuKaeen Vous pouvez avoir un réseau local qui n'est pas connecté à Internet. Ainsi, au lieu de github.com, vous configurez le serveur git par exemple. 192.168.1.100 et tout le reste fonctionne de la même manière.
Agent_L
12
@TutuKaeen: La question critique est de savoir si une communication réseau directe (ou indirecte) est possible entre les deux machines. Donc, dans votre cas, les deux machines sont en réseau, mais les réseaux sont séparés? Dans ce cas, modifiez cette information dans votre question.
Sleske
15
@TutuKaeen Votre question n'est pas claire. Vous dites que vous souhaitez utiliser le contrôle de version, mais dans vos commentaires, vous avez besoin que cela vous aide à déployer en production. Ces problèmes ne se chevauchent pas toujours. Je pense que vous avez de bonnes réponses ci-dessous maintenant, mais à l'avenir, il serait utile que votre question soit plus complète en ce qui concerne vos besoins, qui semblent être: "Je veux utiliser le contrôle de version, ma machine de développement n'a pas accès à Internet, il a un accès réseau, mais pas à la machine de production, et je veux savoir comment extraire le code du contrôle de version sur la machine de production. "
DavidS
4
Il semble étrange d'utiliser le terme serverpour désigner une machine qui n'est connectée à aucun réseau. Ce pourrait être juste un réseau local même sans accès à Internet mais c'est quand même un réseau.
Patrick Gregorio

Réponses:

157

Bien sûr, rien dans Git n’exige de protocole particulier. Le client standard prend immédiatement en charge HTTP (S), SSH, le protocole Git personnalisé et, ce qui est important, le protocole local . Cela prend juste un chemin vers un .gitrépertoire local , qui peut être dans un répertoire de travail ( /path/to/project/.git) ou simplement un répertoire nu ( /path/to/project.git), bien que le nommage ne soit qu'une convention.

Cela signifie que vous pouvez bien sûr ajouter un lecteur flash comme télécommande:

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

ou sous Windows:

git remote add origin F:\foo.git

Ou même l'ajouter comme une télécommande supplémentaire avec un nom différent (si vous préférez originpointer vers un serveur Internet quelque part):

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

Ensuite, vous pouvez simplement pousser / tirer vers / depuis cette télécommande comme une autre.

Si vous lisez la documentation , vous remarquerez qu'il existe également un file://protocole qui se comporte légèrement différemment. Il est recommandé d’utiliser un chemin local car cela utilisera des optimisations supplémentaires - si vous utilisez le file://protocole, alors git utilisera des composants réseau standard (pour parler au disque local), ce qui est plus lent.

Bob
la source
50
Pour ajouter à cette réponse exceptionnelle - Il peut également être intéressant d’envisager l’utilisation d’un référentiel «nu» sur le lecteur flash. Les référentiels 'nus' n'ont pas d'arborescence de travail et ont donc tendance à éliminer une catégorie de problèmes potentiels lorsqu'ils sont utilisés comme un «point d'autorité» partagé, ce qui ressemble à un cas d'utilisation du PO.
Iron Gremlin
5
Le file://est aussi un peu plus flexible. Il vous permet d’utiliser certaines fonctionnalités (telles que des clones superficiels) que vous ne pouvez pas utiliser avec un chemin local.
Austin Hemmelgarn
1
@IronGremlin Pourriez-vous développer cette notion de "point d'autorité partagé"? Je ne suis pas un expert Git et je suis curieux de savoir ce que vous entendez par là.
Courses de légèreté en orbite
2
@LightnessRacesinOrbit - C'est un sujet assez dense, mais, fondamentalement, git est distribué, donc chacun a sa propre histoire. A peut demander à B sa version de l’histoire, mais C ne le sait pas à moins que quelqu'un le lui dise. Avoir un seul référentiel pour stocker l'historique «faisant autorité» signifie que D agit comme un centre d'échange d'informations. Donc, A parle à D des changements, et B et C savent parler à D pour rester au courant plutôt que de faire des trucs en parallèle entre eux. En l'occurrence, si le serveur OP est en C et que le lecteur flash est en D, il s'assure que le serveur n'est pas laissé en dehors des interactions A / B.
Iron Gremlin
6
@LightnessRacesinOrbit Il est important de noter ici que nu ne signifie pas forcément autorité, il est simplement utile dans ce contexte. Par exemple, il est également utile car, en l'absence d'arborescence de travail, l'empreinte de l'espace disque (ou de la bande passante) est réduite. Avant, c'était beaucoup plus important qu'aujourd'hui, mais ça revient tout de même.
Iron Gremlin
46

Sur un seul ordinateur, rien de spécial n'est nécessaire. Exécutez git initle répertoire souhaité et travaillez avec Git comme vous le feriez normalement.

Pour synchroniser un référentiel sur plusieurs ordinateurs, il existe plusieurs méthodes.

Méthode 1a (pas de réseau du tout): vous pouvez créer un «référentiel nu» sur la clé USB, puis y appuyer et en extraire comme vous le feriez avec tout autre référentiel distant. En d'autres termes, les opérations de référentiel via des chemins locaux ne sont pas différentes des opérations via des URL SSH ou HTTPS.

  1. Créez un référentiel 'distant':

    $ git init --bare /mnt/Stick/Repositories/Large_Project.git
    
  2. Dans l'ordinateur 1, tout y est:

    $ cd ~/Large_Project
    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git push usb master
    
  3. Dans l'ordinateur 2, bien, comme toujours.

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

(Vous pouvez également pousser / récupérer / extraire directement depuis une URL ou un chemin.)

Méthode 1b (réseau interne): Si vous avez un serveur interne avec SSH disponible et si Git est installé, vous pouvez procéder comme ci - dessus , il vous suffit de spécifier une adresse SSH à l'aide de la syntaxe [user@]host:pathou ssh://[user@]host/path.

  1. Créez un référentiel 'distant' en s'exécutant git init --bare <somepath.git>sur le serveur désigné (via SSH).

  2. Dans l'ordinateur 1, de la même manière que démontré précédemment.

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

    Ou si vous préférez:

    $ git remote add origin ssh://myserver.example.com/Gits/Large_Project.git
    
  3. Dans l'ordinateur 2, encore la même chose que la méthode 1a.


Méthode 2: vous pouvez créer des «ensembles de transfert» qui archivent une liste donnée de commises dans un seul fichier.

Malheureusement, les commandes de regroupement ne se souviennent pas automatiquement de ce qui était déjà groupé la dernière fois. Il est donc nécessaire de marquer manuellement ou de conserver les notes. Je prendrai juste les exemples du manuel de git-bundle.

  1. Sur l’ordinateur 1, créez un ensemble de toute la branche:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle master
    $ git tag -f last-bundled master
    
  2. Dans l'ordinateur 2, tirez de la liasse comme s'il s'agissait d'un référentiel:

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

Les paquets suivants ne doivent pas nécessairement être emballés master- ils peuvent uniquement emballer les commits récemment ajoutés last-bundled..master.

  1. Dans l’ordinateur 1, créez un ensemble des nouveaux commits ajoutés:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle last-bundled..master
    $ git tag -f last-bundled master
    
  2. Comme ci-dessus.

Grawity
la source
en fait, ce ne serait pas mauvais pour mes besoins, même dans git, rien n'est "primaire", car chaque référentiel a toute l'histoire, vous pouvez donc le recréer à chaque fois que quelque chose se passe mal
Tutu Kaeen
manual tagging or note-keeping is needed, une option à moins que le repo soit très volumineux est git bundle create my.bundle --all
:,
J'aime plus cette réponse, car elle est plus illustrative, même si la réponse acceptée et la même chose disent la même chose.
Rystraum
Quelle est la signification de l'option "nu"?
Courses de légèreté en orbite
1
Il crée un référentiel constitué uniquement de la base de données (ce que vous trouverez normalement dans le .git/dossier caché), sans "arbre de travail" (les fichiers modifiables). C'est la forme préférée pour les référentiels git push.
Grawity
20

git bundle create

L’une des méthodes consiste à utiliser le stockage externe pour échanger des données entre des référentiels: git bundle . De cette façon, vous ne disposez que de fichiers uniques pour chaque transfert, et non de référentiels Git intermédiaires.

Chaque "git push" se transforme en création d'un fichier, "git fetch" récupère les éléments de ce fichier.

Session de démonstration

Créer le premier dépôt et faire le premier "push"

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)

"clonage" vers le deuxième référentiel (c.-à-d. le deuxième ordinateur):

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

gitbundletest$ cd repo2/

repo2$ cat 1
1

Faire quelques changements et les "pousser" dans un autre fichier bundle:

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)

"extraire" les modifications dans le premier référentiel:

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

Contrairement au premier paquet, le second ne contient qu'un historique partiel de Git et n'est pas directement clonable:

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

Il est désavantageux d'utiliser des ensembles dont vous avez besoin pour spécifier manuellement la plage de validations que chaque ensemble doit contenir. Contrairement à git push, git bundlene garde pas trace de ce qui était dans le paquet précédent, vous devez ajuster manuellement refs/remotes/origin/masterou les paquets seraient plus gros que ce qu’il pourrait être.

Vi.
la source
N'oubliez pas de mentionner le --alldrapeau pour tout avoir. Si le dépôt est suffisamment petit, il s'agit du processus le plus simple, car vous transférez tout simplement à chaque fois! Juste ne perdez pas la clé USB - probablement le plus gros problème de sécurité!
Philip Oakley,
7

Vous devez d'abord installer Git . Ensuite, pour créer un nouveau référentiel, exécutez-le dans le dossier que vous avez copié:

git init

Vous pouvez ensuite ajouter les fichiers pour lesquels vous souhaitez contrôler la version git add(ajouter -apour tous les fichiers) et commencer à valider les modifications ( git commit).

Vous n’avez pas à appuyer sur une télécommande, vous pouvez travailler sur votre historique local ( git log).

Pour plus d'informations, consultez:


Pousser / tirer sans internet

En utilisant la git pushcommande, il est possible de pousser sur SSH (en utilisant la connexion locale, intranet):

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

ou en poussant dans le dossier:

git push /mnt/usb/my_repo

Cela suppose que vous ayez deux copies de votre référentiel.

La même chose avec tirer, par exemple

git pull /mnt/usb/my_repo

Patcher

Pour appliquer des correctifs, vous pouvez utiliser la patchcommande ou git apply.

Voir: Créer un fichier de correctif ou un fichier diff à partir du référentiel git et l'appliquer à un autre référentiel git différent .

Kenorb
la source
5

Vous pouvez aussi utiliser Git localement. Ensuite, vos commits ne sont stockés que localement et vous avez toujours le contrôle de version (et pouvez différer / fusionner, etc.), mais vous ne pouvez tout simplement pas accéder au référentiel à partir d’un autre ordinateur.

Vous pouvez démarrer un référentiel Git local en l'exécutant git initdans votre dossier local. Comme décrit ici .

dhae
la source
3
que je connais, mais je veux travailler sur un autre ordinateur et l'appliquer à des fichiers sur un serveur sans accès Internet
Tutu Kaeen
2
@TutuKaeen Je ne vois rien de mal à avoir le référentiel sur un lecteur flash et à le cloner / le synchroniser sur des disques durs de différents ordinateurs. Cependant, "serveur sans accès à Internet" semble étrange, le but d'un serveur est de fournir un service, le plus souvent lié à la mise en réseau (mais pas toujours, en effet).
AnonymousLurker
2
@dhae - Veuillez prendre quelques instants pour fournir plus de détails sur l'utilisation de Git localement. Indiquer seulement que cela peut être fait n’est pas une réponse utile.
Ramhound
2
@anonymousLurker le serveur sert les données à un réseau fermé dans une institution très importante. Cela ne sert tout simplement rien au large Internet, car les données sont très délicates et réservées aux employés.
Tutu Kaeen
1
@TutuKaeen: S'il dispose d' un accès réseau, vous pouvez toujours exécuter votre propre serveur Git via SSH. Git ne se limite pas à GitHub.
Grawity