Git Workflow: sans serveur
git est censé être un système décentralisé, mais tous les tutoriels et les workflows de meilleures pratiques que j'ai trouvés sur google suggèrent d'utiliser un serveur (généralement github, ou bien configurez le vôtre)
J'utilise git pour de petits projets personnels (2-3 personnes), où puis-je trouver un workflow de bonnes pratiques pour synchroniser les changements directement entre les machines des membres de l'équipe. Sinon, quels sont les arguments convaincants pour expliquer pourquoi je devrais éviter cela et plutôt mettre en place un serveur "central"?
Merci,
Ben
Cela dépend de ce que vous entendez par "serveur". Git fonctionnera parfaitement sans serveur central, bien que de nombreuses équipes trouvent pratique d'avoir un référentiel central.
Si par "serveur", vous voulez dire "installer le logiciel serveur", git fonctionnera également (référentiel central ou non) sans logiciel spécial, via ssh ou sur le système de fichiers.
Voir ce document pour les workflows possibles
Workflow avec référentiel commun
Le flux de travail que beaucoup utilisent est que tous les développeurs "poussent" (envoient) leurs modifications vers un référentiel commun et obtiennent toutes les modifications de ce référentiel. Quelque chose comme ça:
- Le développeur A pousse au centre
- Le développeur B pousse au centre
- Développeur C tire (obtenir les modifications de A et B)
- Le développeur A tire (obtenir les modifications de B)
- ...
Dans ce cas, le référentiel central peut être sur l'un des ordinateurs des développeurs, sur github ou tout autre endroit
Flux de travail avec e-mail
Vous pouvez également utiliser git sans aucun serveur, simplement en utilisant le courrier électronique. Dans ce cas, le flux serait comme ceci:
- Le développeur A envoie les modifications par e-mail à l'équipe
- D'autres développeurs appliquent les modifications des e-mails
Cela peut même être fait de manière semi-automatisée
Flux de travail sans serveur central
Vous pouvez configurer git pour utiliser plusieurs référentiels "distants". La mise en garde est que vous ne devez jamais pousser vers un référentiel qui est extrait (c'est-à-dire, une copie développeur sur laquelle quelqu'un travaille). Donc, dans ce cas, le flux serait comme ceci:
- Le développeur A apporte des modifications
- Le développeur B apporte des modifications
- Le développeur C tire les modifications de A
- Le développeur C tire les modifications de B
- Le développeur B tire les modifications de A
- ...
- Personne ne doit jamais pousser
À mon humble avis, ce type de flux de travail conduira rapidement à la confusion et à la panne.
Ce que vous devez faire en premier, c'est réfléchir au type de workflow que vous avez déjà et configurer git pour fonctionner avec cela. Une fois que vous avez quelque chose de opérationnel, vous pouvez le régler avec précision. Il n'est pas nécessaire de configurer un ordinateur distinct en tant que serveur. Si vous avez l'habitude d'avoir un référentiel central, tout ce que vous avez à faire est de créer un référentiel nu vers lequel tout le monde pousse. Pourquoi pas sur le réseau local?
Repo central:
mkdir foo.git
cd foo.git
git init --bare
Votre repo:
mkdir foo
cd foo
git init
// add files
git add .
git commit -m "Initial commit"
git remote add Origin //path/to/central/repo/foo.git
git Push Origin master
Autres repos:
git clone //path/to/central/repo/foo.git
Maintenant, n'importe qui peut pousser et tirer directement de la branche principale. Cela devrait suffire pour vous aider à démarrer.
Vous n'avez pas nécessairement besoin de mettre une copie sur un serveur physique quelque part, mais il peut être utile d'avoir un référentiel `` béni '' quelque part - confiez à une de vos équipes (éventuellement en rotation) la responsabilité de collecter et de gérer les modifications des personnes lorsqu'elles sont prêts à être traités comme définitifs. Ils peuvent soit conserver une branche dans leur référentiel habituel, soit maintenir un référentiel distinct sur leur système local pour stocker les sources principales.
Comme exemple concret, considérons Linux et Linus Torvalds - il n'y a pas de référentiel central vers lequel tout le monde pousse, mais Linus maintient un référentiel qui contient tout le code qu'il considère comme "prêt" (et plusieurs autres personnes aussi, pour différentes définitions de " prêt'). De cette façon, vous avez une définition canonique du code et un endroit pour définir vos versions.
Vous devez configurer un serveur central en tant que construction sociale, et non technique, afin que tout le monde sache où trouver la dernière version officielle, sans possibilité de confusion.
Comme cela a été mentionné, Git fonctionne très bien sans serveur centralisé. Mais une bonne raison d'avoir un serveur central est d'avoir un endroit "toujours allumé" pour pousser le code une fois qu'une fonctionnalité est terminée que les autres développeurs peuvent extraire sans avoir à accéder à votre machine locale.
Par exemple, je travaille actuellement sur une équipe de développement de 3 personnes. Nous travaillons tous sur des ordinateurs portables. Nous pourrions avoir un flux de travail où nous tirons simplement des machines les uns des autres. Mais si je travaille sur une fonctionnalité et engage mes chances après que tout le monde a quitté le bureau et que je veux qu'ils jettent un œil avec ce système, ils ne peuvent rien faire à moins que mon ordinateur portable soit allumé et disponible sur le réseau. Si les gars arrivent plus tôt que moi (ce qu'ils font toujours), ils doivent attendre que mon ordinateur portable soit de nouveau en ligne.
Si je pousse vers quelque chose comme BitBucket ou GitHub ou tout simplement un serveur toujours au bureau, n'importe quel autre développeur peut simplement tirer les modifications que j'ai apportées lors de sa prochaine connexion en ligne.
C'est pour moi la principale raison d'avoir un serveur central, et ce n'est vraiment pas un problème avec Git mais plutôt une conséquence du travail avec les ordinateurs portables.
Git fonctionne assez bien avec ce type de configuration, bien que vous souhaitiez éviter de pousser les modifications dans la branche extraite de quelqu'un d'autre ( https://git.wiki.kernel.org/index.php/GitFaq#Why_won. 27t_I_see_changes_in_the_remote_repo_after_.22git_Push.22.3F ). Vous pouvez avoir une branche d'intégration vers laquelle vous envoyez du code et fusionner les modifications d'autres personnes.
Je pense que la principale raison pour laquelle un dépôt central est beaucoup utilisé est qu'il peut être pris comme base canonique pour tout votre code, alors qu'il peut être un peu plus difficile de raisonner sur ce que vous devriez fusionner lorsque vous en avez 3 ou plus. branches de développement en cours.
Jetez un œil au Git pour les débutants: le guide pratique définitif
section "Comment configurer un référentiel d'équipe partagé?"