Travailler avec Git sur plusieurs machines

Cela peut sembler un peu étrange, mais je me demande une bonne façon de travailler dans Git à partir de plusieurs machines en réseau d'une manière ou d'une autre. Il me semble que j'ai deux options, et je peux voir des avantages des deux côtés:

• Utilisez git lui-même pour le partage, chaque machine a son propre référentiel et vous devez aller les chercher.
  • Vous pouvez travailler sur l'une ou l'autre machine même si l'autre est hors ligne. En soi, c'est assez gros je pense.
• Utilisez un référentiel partagé sur le réseau entre les machines.
  • Pas besoin de faire git pulls à chaque fois que vous changez de machine, car votre code est toujours à jour.
  • Ne vous inquiétez pas si vous avez oublié de pousser le code de votre autre machine non hébergée, qui est maintenant hors de portée, car vous travailliez sur un partage de fichiers sur cette machine.

Mon intuition dit que tout le monde va généralement avec la première option. Mais l'inconvénient que je vois est que vous ne pourrez peut-être pas toujours accéder au code à partir de vos autres machines, et je ne veux certainement pas pousser toutes mes branches WIP vers github à la fin de chaque journée. Je ne veux pas non plus avoir à laisser mes ordinateurs allumés tout le temps pour pouvoir les récupérer directement. Enfin, un point mineur est que toutes les commandes git pour garder plusieurs branches à jour peuvent devenir fastidieuses.

Y a-t-il une troisième poignée sur cette situation? Peut-être que certains outils tiers sont disponibles pour faciliter ce processus? Si vous traitez régulièrement cette situation, que proposez-vous?

Je m'occupe quotidiennement de vos deux solutions proposées. Il y a deux concepts clés pour bien les gérer.

1. Utilisez des branches de sujet. Je pense que l'histoire de la production doit être vierge. En conséquence, je passe beaucoup de temps à rendre productionl'historique de ma branche logique, reproductible et débogable. Cependant, lorsque vous utilisez plusieurs machines, vous devez occasionnellement valider un travail en cours. Utilisez une branche thématique. Vous pouvez pullet pushcette branche des deux machines avec peu d'effort, et quand il est prêt à fusionner masterou à production rebaser pour créer un historique plus maintenable.
2. L'utilisation d'un référentiel partagé sur un réseau est acceptable, sauf si vous le partagez également avec d'autres utilisateurs. Nous utilisons un référentiel partagé pour les scripts, nommé de manière créative le scriptsréférentiel. Au début, cela semblait être une bonne idée car le repo ne change pas souvent, mais avec le temps, c'est devenu tout à fait un cauchemar. Il est facile d'écraser le travail de l'autre, et vous finissez par passer autant de temps à contrôler le trafic aérien qui déploie le référentiel que vous y travaillez.

La meilleure solution consiste à conserver un référentiel local sur chaque machine et à partager des branches de sujets entre elles via une télécommande. Engagez les travaux en cours dans ces succursales aussi souvent que vous le souhaitez. Tant que vous êtes prêt à les rebaseintégrer dans une histoire plus intelligible, c'est assez efficace dans la pratique.

Si vous vous trouvez à travailler sur plus d'une branche de sujet tout au long de la journée mais que vous ne voulez pas les pousser individuellement vers la télécommande, git push <remote>poussera par défaut toutes les branches correspondantes vers <remote>. Cette valeur par défaut changera dans une version ultérieure de git , mais peut être remplacée en définissant push.defaultdans un fichier de configuration ou en spécifiant la correspondance refspec:

git push <remote> :

Si toutes les machines ne fonctionnent pas tout le temps, il n'y a pas de solution miracle: avant d'arrêter la machine, vous devez pousser les modifications ailleurs. Je pousse vers un serveur privé, mais cela pourrait tout aussi bien être une boîte de dépôt ou une clé USB que vous emportez partout.

Oui, pousser plusieurs branches à un endroit central peut devenir fastidieux, mais cela ne devrait pas être trop difficile à écrire. J'utilise un push.shscript pour cela, que j'exécute chaque fois que j'ai fini de travailler sur une machine.

J'en suis venu dans une direction légèrement différente (et j'utilise mercurial, mais philosophiquement c'est la même chose). Ce n'est pas mon idée, je l'utilise et cela fonctionne pour mes affaires personnelles.

J'ai créé un clone de mes référentiels dans un dossier SkyDrive (il peut également s'agir de dropbox ou d'un autre outil de synchronisation magique de votre choix), j'ai ensuite configuré les instances sur mes deux machines pour pousser automatiquement vers le référentiel SkyDrive lors de la validation.

Lorsque je change de boîte, il suffit de faire un pull et une mise à jour - en théorie, vous travaillerez toujours de manière linéaire, même si c'est dans plusieurs référentiels.

La clé ici est que le dépôt SkyDrive existe principalement pour fournir un moyen de garantir que j'ai accès à plus ou moins la dernière version du code sur mes deux machines - même si cela fonctionnerait aussi pour plus - et pour fournir un sauvegarde supplémentaire. Tout ce qui est "fait" est poussé vers Kiln (si j'utilisais git et que je comprends correctement la façon dont le jeu est joué, ce serait le moment où je ferais un rebase).

Ce que je ne voudrais vraiment pas faire, c'est exécuter un dossier partagé ... si vous utilisez un DVCS, vous pouvez tout aussi bien en profiter.

La première de vos deux alternatives est la réponse. C'est sous-entendu par le "D" dans "DVCS". Chaque utilisateur a sa propre instance locale du référentiel, et les référentiels parlent entre eux de manière gérable.

Vous pouvez faire votre deuxième alternative, mais le problème est qu'il n'y a qu'un seul répertoire de travail du référentiel. Ainsi, l'arbre de travail peut être dans un seul état à la fois - il n'y a pas de Joe travaillant sur une branche et Jane travaillant sur une autre. Ainsi, les développeurs peuvent remplacer les modifications les uns des autres, mutiler le travail de chacun. C'est comme ne pas avoir du tout de contrôle de version!

Il existe un terrain d'entente appelé, ayant un référentiel nu sur un lecteur réseau et permettant aux utilisateurs individuels de s'enregistrer et de s'en déconnecter. Cela sépare votre travail WIP (que oui, vous conservez localement) du travail que vous publiez jusqu'au référentiel. Ce n'est pas "sauvegarder" - c'est "publier". Le travail que vous voulez que vos pairs voient et utilisent.