Forum Programmation.php workflow git

Posté par pralines le 28 janvier 2018 à 11:45. Licence CC By‑SA.

Étiquettes :

jan.

2018

Bonjour,
dans le cadre d'un développement LAMP, je suis amené à utiliser le gestionnaire de version (GIT/GOGS) installé par un client sur son intranet.

Le client met à ma disposition un de ses portables aptes à se connecter à son réseau.
Ce poste peut aussi se connecter (brièvement) à mon intranet, mais jamais aux 2 intranet (client et le mien) simultanément.

Je souhaite pouvoir développer/tester/mettre à jour le dépôt lorsque je suis chez le client, mais lorsque je suis chez moi, je préfère développer sur mes machines (plus confortable).

J'ai donc le problème de synchronisation entre le poste de développement du client et les miens (qui ne peuvent se connecter chez le client).

Jusqu'à maintenant, je me débrouillais tant bien que mal pour rester synchronisé en copiant à la main les fichiers entre les machines, mais c'est complètement ridicule alors que je pourrais utiliser l'outil surpuissant qu'est GIT.

Quel serait le workflow ou l'organisation la plus efficace dans ce cadre ?
- Dépôt centralisé GIT/GOGS sur l'intranet du client
- Dépôt local GIT sur portable du client
- que faire sur mon intranet : un autre dépôt central ou bien plusieurs dépôt locaux sur chaque machine ?
- comment faire passer les modifications dans les 2 sens (machines client <---> mes machines)

Avant de venir poser la question ici, j'ai lu beaucoup de documentation sur GIT et je suis certain qu'il y a une solution meilleure que les autres, mais je n'arrive pas à trouver laquelle…
Ce forum de programmation PHP n'est peut-être pas le bon, alors si vous connaissez un bon forum GIT actif et en français, je suis preneur :-)

Merci d'avance pour vos conseils éclairés.

# GIT = decentralisé

Posté par NeoX le 28 janvier 2018 à 12:48. Évalué à 3.

chacun dispose d'une copie du projet, peut travailler dans son coin,

quand tu es chez toi, tu bosses tu TA copie, tu commites dans TA copie.
et quand tu vas chez ton client, tu push des modifications sur SA copie, s'il n'a fait aucune modification depuis ton depart, ca passera sans souci, sinon il faudra gerer les fusions (merge) et les problemes que cela peut engendrer (2 modifications sur le meme fichier, choisir laquelle est prioritaire, etc)
- [^] # Re: GIT = decentralisé
  
  Posté par pralines le 28 janvier 2018 à 15:07. Évalué à 2.
  
  merci pour ta réponse
  
  après toutes mes lectures, si il y a une chose que j'ai bien compris c'est que chacun a sa copie, mais qu'on pouvait aussi adopter un workflow centralisé si on le désirait (un dépôt central "bare metal" étant censé être hébergé sur un serveur n'a pas de working dir et sans doute pas d'index/staging, je ne me rappelle plus),
  
  de ce que j'ai compris des concept de GIT, je pense qu'on peut changer de workflow en cours de route, quitte à reconfigurer les remote (et url associées)
  
  en résumé, corrige moi si je déraille, j'ai 2 cas :
  
  1 : je fais des modification sur le poste portable du client :
  mon poste portable connecté à l'intranet client va me servir à mettre à jour le dépôt sur le serveur GOGS du client,
  
  de retour sur mon intranet, ce même poste portable va pouvoir mettre à jour le dépôt de ma machine de travail pourvu que son accès remote soit démarré (ssh ou git ou http)
  
  2 : je fais des modifications sur ma machine de travail :
  je peux (depuis le poste portable du client) mettre à jour son dépôt local pour ensuite aller chez le client mettre à jour le dépôt de son serveur GOGS
  
  si je n'ai pas dit de bêtise, je n'ai plus qu'à me lancer ? :-)
  
  Envoyé depuis mon Archlinux
  - [^] # Re: GIT = decentralisé
    
    Posté par NeoX le 29 janvier 2018 à 12:27. Évalué à 2.
    
    j'ai pas pratiqué jusqu'à tester ce niveau là,
    
    nous c'etait plutot un depot local dans l'entreprise (la notre)
    des copies locales sur nos postes pour lesquels on travaille dans une branche (dev/moi, preprod/moi, prod/moi)
    et une fois notre branche operationnelle on envoyer des pull-request au gestionnaire du depot master, qui reprenait le travail fait dans chaque branche via les commits
  - [^] # Re: GIT = decentralisé
    
    Posté par Marotte ⛧ le 29 janvier 2018 à 17:59. Évalué à 5.
    
    un dépôt central "bare metal"
    
    "bare metal" ? Il me semble qu’on parle de "bare repository" pour les dépôts qui ne sont pas des copies de travail mais pour moi "bare metal" c’est pour parler d’un serveur physique, par opposition à un serveur virtuel. Aurais-je loupé un truc ?
    - [^] # Re: GIT = decentralisé
      
      Posté par pralines le 29 janvier 2018 à 18:28. Évalué à 2.
      
      non, tu n'as rien loupé,
      
      des fils se sont touchés dans ma mémoire………………………….
      
      Envoyé depuis mon Archlinux
  - [^] # Re: GIT = decentralisé
    
    Posté par Obsidian le 31 janvier 2018 à 01:10. Évalué à 2.
    
    Salut,
    
    D'après ce que je lis, tes machines ne peuvent se connecter qu'au portable, et ce portable sert également de « poste de travail » officiel chez ton client. Donc, si tu n'avais tes propres machines à côté, c'est avec cet appareil que tu serais censé travailler.
    
    Donc, il faudra cloner le dépôt principal sur ton portable (de la même façon que tu récupérerais le kernel pour travailler dessus en clonant le dépôt, ou à tout le moins les branches qui t'intéressent). Quelle taille fait-il, au fait ?
    
    Ensuite, le plus simple consiste tout simplement à cloner à son tour le dépôt de ton portable depuis ta machine personnelle. De cette façon, tu n'as pas besoin de t'embêter à aller ajouter manuellement des sites remote sur un dépôt ou un autre, et les références amont (upstream) de tes branches seront tout de suite dans l'ordre (ta machine se réfère au portable, et le portable se réfère au site du client).
    
    La seule chose qu'il faudra faire veiller à faire pour synchroniser ta machine et le portable est de faire autant les push et que les pull depuis ta machine. Le portable n'aura donc pas a priori connaissance de l'existence du dépôt sur ta machine, mais en recevra quand même les objets. Une fois un push effectué, tout ton travail se retrouvera sur ton portable comme si tu avais directement travaillé dessus et tu n'auras même pas à maintenir de branches distinctes spécifiques à ton portable ou à ta machine.
    
    Évidemment, il faudra quand même configurer une seule fois les droits dans le dépôt de ton portable pour laisser ta machine s'y connecter. Et bien sûr, cela implique aussi de démarrer un serveur sur ton portable lorsque tu veux synchroniser, à moins d'avoir une vue directe sur le système de fichiers.
    - [^] # Re: GIT = decentralisé
      
      Posté par pralines le 31 janvier 2018 à 10:43. Évalué à 2.
      
      salut et merci pour les suggestions,
      
      il faut que j'essaye tout ça
      
      je pense que je vais être bloqué par le parefeu (symantec) installé dans le portable w7,
      je ne peux le désactiver que pendant 2 minutes (pour le désactiver à nouveau un reboot est nécessaire),
      
      de plus, je n'ai pas les droits pour installer un serveur sur cette machine (seulement le client git et tortoise-git)
      
      peut-être que je pourrai m'en sortir en bootant un linux sur disque usb dans lequel j'aurai installé tout ce qu'il faut (avec accès au système de fichiers ntfs de la machine)
      
      ça va me faire apprendre des choses :-)
      
      Envoyé depuis mon Archlinux
      - [^] # Re: GIT = decentralisé
        
        Posté par NeoX le 31 janvier 2018 à 11:08. Évalué à 3.
        
        tu fais un clone locale avec une clef USB
        
        cd D:\la_clef_usb git clone C:\le_disque_du_portable_client
        
        puis tu travailles sur le depot de la clef USB sur ton portable,
        ou tu clones de la clef USB -> ton portable
        
        [^] # Re: GIT = decentralisé
        
        Posté par pralines le 31 janvier 2018 à 11:15. Évalué à 1. Dernière modification le 31 janvier 2018 à 11:16.
        
        il semble que je vais avoir plusieurs possibilités, merci à tous, merci GIT (merci Linus)
        
        reste à expérimenter et trouver la plus simple à mettre en œuvre (pour limiter les erreurs/oublis de synchronisation de toutes les machines)
        
        Envoyé depuis mon Archlinux
        
        [^] # Re: GIT = decentralisé
        
        Posté par NeoX le 31 janvier 2018 à 11:46. Évalué à 2.
        
        simple ;)
        
        serveur client <=> portable client <=>clef usb <=> ton portable <=> ton serveur
        
        [^] # Re: GIT = decentralisé
        
        Posté par Obsidian le 31 janvier 2018 à 13:22. Évalué à 2.
        
        À mon que j'aie compris quelque chose de travers, il me semble que son portable, c'est justement celui du client…
        
        [^] # Re: GIT = decentralisé
        
        Posté par Obsidian le 31 janvier 2018 à 13:27. Évalué à 2.
        
        Quoi que tu choisisses, essaie de mettre ce qui se trouve sur le portable (ou sur la clé USB, le cas échéant) sur une partition chiffrée si possible. Si tu pers la clé de chiffrement — ou la clé USB elle-même — ce n'est pas grave puisque tu en auras toujours une copie sur le serveur de ton client et éventuellement sur ta machine. Par contre, un portable et une clé amovible qui se trimballent tous les jours ou presque entre les deux lieux de travail, ça s'oublie facilement sur une table, ça se vole très rapidement aussi et sinon, ça finit par tomber en panne. :)
        
        Étant donné ta situation et la manière dont ton portable est configuré, je me rabattrais effectivement sur le dépôt Git sur une clé USB. Ça permet de rester sur le modèle habituel à deux dépôts (local + remote) et c'est ce qui serait le plus facile à utiliser, à la fois sur le portable et ta machine. En plus, il est plus facile de chiffrer une clé USB et de la monter sous le Windows du portable que de se battre avec les protections déjà en place pour le faire sur le disque dur.
        
        Par contre, pense à faire une copie du dépôt sur ta machine à intervalles réguliers. Mais pour ça, tu n'as pas besoin de cloner le dépôt. Un rsync sur le répertoire sera plus efficace, je pense.
# Plusieurs options

Posté par Michaël (site web personnel) le 31 janvier 2018 à 11:48. Évalué à 5.
Tu as plusieurs approches possibles. Tout d'abord notons CLIENT et PERSO tes dépôts (copies de travail) git, ce qui nous servira à décrire les workflows. Pour évaluer les différentes solutions il faut que tu regardes ce qui est techniquement et commercialement faisable.

La raison qui fait que c'est possible techniquement est que git est décentralisé et un dépôt donné n'a aucun rôle techniques spécifique par rapport à un autre – le clone produit par git clone est en principe total – et git fournit plein d'outils pour échanger les données entre les divers clones d'un même dépôt.

1. INSTALLER UN HOP SUR TON INTRANET

Comme tu mentionnes que tu peux accéder pour quelques minutes à ton propre depuis chez ton client, ce serait facile de créer un serveur sur ton propre intranet qui tourne toujours et héberge un dépôt HOP, accessible via SSH-GIT, HTTPS-GIT, ou bien par NFS par exemple. Ainsi ton workflow ressemblerait à:
- Arrivée site client
- Hack
- Pousse de CLIENT vers HOP avant de rentrer à la maison
- À la maison, tire de HOP sur PERSO
- Hack
- Avant de partir chez le client pousse de PERSO sur HOP
- Arrivée sur le site client, tire de HOP sur CLIENT
- Hack
- Pousse de CLIENT vers HOP avant de rentrer à la maison
- …
2. INSTALLER UN HOP AILLEURS SUR INTERNET

Tu peux aussi considérer un hébergement de dépôt git payant, cela coûte une poignée d'euros par mois. Tu y créerais un dépôt HOP, que tu utiliserais comme précédemment. Variante avec une box complète, prix analogue.

3. UTILISER UN HOP SUR UNE CLEF USB

Si tes postes de travail peuvent accéder aux mêmes systèmes de fichiers (par exemple ce sont deux Linux) tu peux utiliser un support amovible pour stocker ton dépôt HOP (par exemple un bare repo). Il faudrait certainement crypter ce support pour se prémunir contre sa perte.

4. UTILISER GIT-BUNDLE PAR E-MAIL

La sous-commande git bundle permet de sauvegarder une partie d'un dépôt git dans une archive fichier, dite “bundle”, qui peut ensuite être importé dans un autre dépôt. Le “bundle” peut être acheminé via une clef USB ou en P.j. sur un email.
```
% man git-bundle
…
       Some workflows require that one or more branches of development on one
       machine be replicated on another machine, but the two machines cannot
       be directly connected, and therefore the interactive Git protocols
       (git, ssh, http) cannot be used. This command provides support for git
       fetch and git pull to operate by packaging objects and references in an
       archive at the originating machine, then importing those into another
       repository using git fetch and git pull after moving the archive by
       some means (e.g., by sneakernet). As no direct connection between the
       repositories exists, the user must specify a basis for the bundle that
       is held by the destination repository: the bundle assumes that all
       objects in the basis are already in the destination repository.
```
Cela correspond assez exactement à ton besoin. Je l'ai utilisé pendant longtemps en mode “sneakernet,” c'est un peu relou mais si tu dois jongler entre les intranets cela reste sûrement plus simple que les push/pull à travers le réseau.

En gros c'est le même workflow qu'avec le HOP mais au lieu de cela à la fin de ta session de travail, tu fais und bundle avec tous tes derniers commits et l'apporte ou l'email à ton autre station pour pouvoir l'importer.

5. GIT-IMAP

Jette un œil à la man-page git-imap-send – je n'ai jamais utilisé cette fonction mais cela semble pouvoir répondre à ton besoin.

6. MON AVIS

Admettant que ton client soit d'accord avec ces manips, je pense que les solutions les plus simples sont, par ordre croissante de complexité à l'usage.
1. Installer un HOP ailleurs sur Internet, si tu as un accès illimité chez ton client.
2. Utiliser un HOP sur une clef USB, si tu as droit au support amovible.
3. Utiliser git-bundle via email
4. Installer un HOP sur ton intranet.
- [^] # Re: Plusieurs options
  
  Posté par pralines le 31 janvier 2018 à 13:14. Évalué à 3. Dernière modification le 31 janvier 2018 à 13:16.
  
  merci mille fois de me faire découvrir git bundle et git imap-send…
  
  imap-send sera probablement bloqué par le proxy http authentifiant du client, mais je note tout de même la solution
  
  en revanche, je n'ai pas encore rencontré le terme HOP, j'ai cherché un moment (jusque sur ton site internet), sans succès,
  peux tu préciser ce que tu entends par là (abréviation ? de quoi ?) :-) :-) :-)
  
  Envoyé depuis mon Archlinux
  - [^] # Re: Plusieurs options
    
    Posté par Michaël (site web personnel) le 31 janvier 2018 à 13:42. Évalué à 2.
    
    En anglais to hop signifie sautiller, par exemple à cloche-pied. Dans le slang de l'informatique on donne au substantif dérivé a hop le sens de petit bond, mais de façon abusive on peut aussi désigner ainsi la destination intermédiaire.
    - [^] # Re: Plusieurs options
      
      Posté par pralines le 31 janvier 2018 à 14:40. Évalué à 2.
      
      aaah okay okay okay (copyright Papin)
      
      je pensais qu'il s'agissait d'une nouvelle brique/serveur (genre gitlab, gogs, etc…) donc je n'avais pas encore entendu parler :-)
      
      Envoyé depuis mon Archlinux
      - [^] # Re: Plusieurs options
        
        Posté par Michaël (site web personnel) le 31 janvier 2018 à 16:14. Évalué à 2.
        
        aaah okay okay okay (copyright Papin)
        
        Ça fait djeun's. ;)
        
        [^] # Re: Plusieurs options
        
        Posté par Obsidian le 31 janvier 2018 à 20:15. Évalué à 2.
        
        Ça fait djeun's. ;)
        
        C'était il y a presque 25 ans et coup, plus tellement… ;-(
        
        [^] # Re: Plusieurs options
        
        Posté par pralines le 31 janvier 2018 à 21:03. Évalué à 2.
        
        m'a cassé le moral, je répondrai bien, mais c'est l'heure d'aller faire dodo…..
        
        Envoyé depuis mon Archlinux
        
        [^] # Re: Plusieurs options
        
        Posté par Michaël (site web personnel) le 01 février 2018 à 07:11. Évalué à 3.
        
        Ça doit faire 25 ans aussi que personne ne dit “djeun's” et je te taquinais aimablement ;)