Git: Sans serveur

Ce que vous devez faire en premier, c'est de réfléchir au type de flux de travail que vous avez déjà et de configurer git pour qu'il fonctionne avec. Une fois que vous avez quelque chose en cours d'exécution, vous pouvez affiner. Il n'est pas nécessaire de configurer un ordinateur séparé en tant que serveur. Si vous êtes habitué à avoir un référentiel central, tout ce que vous devez faire est de créer un référentiel nu auquel tout le monde pousse. Pourquoi pas sur le réseau local?

Centrale repo:

mkdir foo.git
cd foo.git
git init --bare

Votre dépôt:

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, tout le monde peut pousser et tirer directement de la branche principale. Cela devrait être assez pour vous obtenir a commencé.

Vous n'avez pas nécessairement besoin de mettre une copie sur un serveur physique quelque part, mais cela peut aider à avoir un référentiel "béni" quelque part-rendre un membre de votre équipe (éventuellement en rotation) responsable de la collecte et de la gestion des modifications des personnes lorsqu'elles sont prêtes à être traitées comme finales. Ils peuvent conserver une branche dans leur référentiel habituel ou maintenir un référentiel séparé 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 auquel 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, pour différentes définitions de "prêt"). De cette façon, vous avez une définition canonique de ce que le code est, et un endroit pour définir ce que sont vos versions.

Vous devez configurer un serveur central comme une construction sociale, pas technique, afin que tout le monde sache où trouver la dernière version officielle, sans aucune 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 une place pour code une fois qu'une fonction est complété par d'autres développeurs peuvent tirer de sans avoir à accéder à votre machine locale.

Par exemple, actuellement je travaille sur une équipe de développement de 3 hommes. Nous travaillons tous sur des ordinateurs portables. Nous pourrions avoir un flux de travail où nous tirons juste des machines de l'autre. Mais si je travaille sur une fonctionnalité et engage mes chances après que tout le monde a quitté le bureau et je veux qu'ils jettent un oeil avec ce système, ils ne peuvent rien faire à moins que mon ordinateur portable est allumé et disponible sur le réseau. Si les gars se présentent plus tôt que moi (ce qu'ils font toujours), ils doivent attendre que mon ordinateur portable soit de retour en ligne.

Si je pousse à quelque chose comme BitBucket ou GitHub ou juste un serveur toujours sur le bureau, l'un des autres développeurs peut simplement tirer les changements que j'ai faits quand ils sont en ligne.

C'est pour moi le raison principale d'avoir un serveur central, et ce n'est vraiment pas une faute avec Git mais plutôt une conséquence de travailler avec des ordinateurs portables.

Jetez un oeil au Git pour les débutants: le guide pratique définitif

Section " comment configurer un référentiel d'équipe partagé?"

Git fonctionne assez bien avec ce type de configuration, bien que vous souhaitiez éviter de pousser les modifications vers 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 poussez du code et fusionnez les modifications d'autres personnes.

Je pense que la principale raison pour laquelle un repo central est beaucoup utilisé est qu'il peut être pris comme base canonique pour tous vos code, alors qu'il peut être un peu plus difficile de raisonner sur ce que vous devriez fusionner lorsque vous avez 3 branches ou plus de développement en cours.