Je suis un utilisateur Subversion de longue date qui va essayer Git. J'en ai lu à ce sujet et je comprends la nature distribuée - je peux voir beaucoup d'avantages.

Cependant, j'aime l'idée d'un serveur central qui peut jouer le rôle de sauvegardes, de système d'enregistrement, etc., tout en utilisant Git pour ma branche locale et mon partage. Je ne fais pas de projet open source, donc je ne peux pas utiliser Github (sans payer), donc ma question est vraiment: quelle est la meilleure façon d'exécuter un serveur git local?

Je me rends compte que cela peut être contraire au modèle d'utilisation standard de Git, mais cela sera utile pour mon projet. Cependant, toutes les préoccupations que j'ai pu ignorer sont toujours les bienvenues.

Merci!

Vous pouvez simplement configurer un serveur ssh et y exécuter un référentiel central. Tous les développeurs acceptent alors simplement (par principe) de pousser vers le serveur quand ils ont fini de faire des commits. C'est le modèle d'utilisation sur mon lieu de travail. Très semblable à CVS et SVN.

1. Trouvez un endroit où mettre le référentiel ( /var/gitrootpar exemple).
2. Créez un nouveau référentiel ( mkdir project.git && cd project.git && git init --bare --shared=group).
3. Ensuite, sur votre client, clonez le référentiel distant ( git clone ssh://yourserver.com/var/gitroot/project.git && cd project)
4. ajouter des fichiers ( git add README)
5. commit ( git commit -m "Initial import"),
6. pousser ( git push origin master)

Cela devrait mettre les choses en place pour vous.

Gitorious est une interface web open source à git que vous pouvez exécuter sur votre propre serveur, un peu comme github:

http://getgitorious.com/

Mise à jour:

http://gitlab.org/ est également une autre alternative maintenant.

Mise à jour 2:

Gitorious a rejoint GitLab

Essayez GitLab

Le meilleur outil GUI git que j'ai jamais utilisé. Il est très similaire à GitHub.

Il est open source (licence MIT) et est le logiciel de gestion git le plus installé avec plus de 25 000 installations. Il a des sorties mensuelles et une communauté active avec plus de 375 contributeurs. Vous pouvez disposer d'un nombre illimité de référentiels privés, internes et publics sur votre propre serveur. Il s'agit d'une application Ruby on Rails qui fonctionne sur la plupart des plates-formes Unix.

Si cela ne vous dérange pas de vous salir avec la ligne de commande, gitolite est un régal absolu lorsque vous travaillez dans un environnement d'entreprise où vous devez définir des droits d'accès différents sur différents référentiels. C'est en quelque sorte une version plus récente de la gitose mentionnée par @Chris.

Voici le résumé du site Web de l'auteur:

Gitolite vous permet d'utiliser un seul utilisateur sur un serveur pour héberger de nombreux référentiels git et fournir un accès à de nombreux développeurs, sans avoir à leur donner de véritables ID utilisateur ou un accès shell au serveur. La magie essentielle de cette opération est l'accès à la clé de pub de ssh et le fichier authorized_keys, et l'inspiration était un programme plus ancien appelé gitosis.

Gitolite peut restreindre qui peut lire (cloner / récupérer) ou écrire dans (pousser) un référentiel. Cela peut également restreindre qui peut pousser vers quelle branche ou quelle balise, ce qui est très important dans un environnement d'entreprise. Gitolite peut être installé sans nécessiter d'autorisations root, et sans logiciel supplémentaire que git lui-même et perl.

Il a un ensemble de fonctionnalités assez complet, mais une chose que j'aime beaucoup, c'est que toute la modification de la configuration au jour le jour se fait via un référentiel git spécial. Autrement dit, l'ajout d'un utilisateur est juste

• Ajouter un utilisateur au fichier de configuration
• Ajouter la clé ssh de l'utilisateur
• Engagez le changement
• Poussez-le à la gitolite
• Voila, la configuration est en direct!

Et lorsque vous avez besoin de regarder le code via un navigateur, gitolite prend en charge la "synchronisation" de la configuration avec gitweb. Ou si vous aimez cgit , qui est une très bonne interface web pour git écrit en C, mieux, alors vous devriez regarder ce tutoriel .

Vous pourriez envisager Gitblit , un serveur Gitbliste , un visualiseur et un gestionnaire de référentiels Java open source, intégrés et purs pour les petits groupes de travail.

Navigateur Bare Bones

git instaweb --httpd=webrick

du livre Git SCM

le combiner avec quelque chose comme l'approche décrite ici pour le développement distribué (crédit à datagrok pour le concept bien décrit)

Lancez un serveur git unique à partir de n'importe quel référentiel local.

J'ai déjà tweeté cela, mais je pensais que cela pourrait utiliser une certaine extension:

Activer le flux de travail git décentralisé: git config alias.serve "démon --verbose --export-all --base-path = .git --reuseaddr --strict -paths .git /"

Supposons que vous utilisez un flux de travail git qui implique de travailler avec un référentiel «officiel» de base dans lequel vous extrayez et transférez vos modifications depuis et vers. Je suis sûr que de nombreuses entreprises le font, tout comme de nombreux utilisateurs de services d'hébergement git comme Github.

Disons que ce serveur, ou Github, tombe en panne un peu.

Pas de soucis, après tout, l'une des raisons pour lesquelles vous utilisez git est que vous avez une copie de l'historique complet du projet dans votre clone local.

Vous pouvez continuer à coder et à valider pendant que vous attendez que l'équipe des opérations redonne vie au serveur. Note à soi: acheter des beignets pour l'équipe des opérations.

Mais que se passe-t-il si, pendant ce temps d'arrêt, vous souhaitez collaborer avec une autre personne, qui peut ne pas être un expert git, sur le même référentiel?

Ou, au lieu d'un temps d'arrêt, que se passe-t-il si vous et votre collaborateur êtes sur le terrain, et pour une raison quelconque, vous ne pouvez pas obtenir votre VPN pour vous permettre de vous connecter à votre référentiel officiel?

Ou, que se passe-t-il si vous et votre collaborateur augmentez un tas de changements expérimentaux, et même si vous y avez accès, vous ne voulez pas pousser votre désordre inachevé dans le référentiel central officiel? (Pas même en tant que branches de fonctionnalité.) Peut-être êtes-vous en train de nettoyer une rebase ou une fusion désastreuse et les branches sont partout.

Eh bien, git, comme vous le savez probablement, est un système de contrôle de version "distribué" .

Même si vous pouvez utiliser un référentiel git "officiel" central dans votre flux de travail, vous avez toujours la possibilité d'utiliser git de pair à pair, où vous et votre collaborateur construisez et partagez simplement des commits les uns avec les autres, et le central serveur n'a même jamais à savoir.

Alors, comment pouvez-vous obtenir vos succursales et vous y engager, ou vice versa?

• Vous pouvez utiliser les fonctionnalités de git pour envoyer des correctifs par courrier électronique. Mais c'est un peu inélégant et nécessite quelques connaissances sur la fin de l'application des correctifs par courrier électronique.
• Vous pouvez créer un compte sur votre propre machine pour que votre collaborateur s'y connecte. Mais peut-être que vous n'avez pas d'accès root local, ou peut-être que vous ne leur faites pas confiance avec l'accès SSH à votre box.
• Vous pouvez cloner votre dépôt sur une clé USB et le passer d'avant en arrière. Mais c'est plutôt fastidieux, surtout si vous êtes sur le même réseau local et que vous avez besoin d'une clé USB.

Vous pouvez probablement penser à d'autres méthodes également. Mais il existe un moyen très simple: si vous pouvez vous voir sur le réseau, vous pouvez lancer un serveur git unique qu'ils peuvent utiliser comme télécommande pour cloner, récupérer et extraire vos modifications, et le tuer lorsque vous êtes fait avec.

L'outil qui permet cela est git daemon, qui a beaucoup d'options et de fonctionnalités, mais dans le but d'activer cette solution unique "servir simplement le dépôt dans lequel je suis", la façon de l'utiliser est de créer un alias. J'aime l'appeler git serve. Courir:

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

L'utilisation d'un alias est en fait cruciale, car les alias git sont exécutés dans le répertoire de base de votre arborescence de travail. Ainsi, le chemin '.git' pointera toujours au bon endroit, peu importe où vous vous trouvez dans l'arborescence de répertoires de votre référentiel.

Utilisez votre nouveau git servecomme ceci:

1. Courez git serve. "Prêt à gronder", rapportera-t-il. Git est méchant.
2. Découvrez votre adresse IP. Disons que c'est 192.168.1.123.
3. Dites "hé Jane, je ne suis pas prêt / capable de pousser ces commits jusqu'à l'origine, mais vous pouvez récupérer mes commits dans votre clone en exécutant git fetch git://192.168.1.123/"
4. Appuyez sur ctrl + c lorsque vous ne souhaitez plus diffuser ce dépôt.

Vous pouvez également indiquer à Jane git clone git://192.168.1.123/ local-repo-namesi elle n'a pas encore de clone du référentiel. Ou, utilisez git pull git://192.168.1.123/ branchnamepour effectuer une extraction et une fusion à la fois, utile si vous travaillez ensemble sur une branche de fonctionnalité.

Notez cependant que vous ne devriez pas faire cela sur des réseaux hostiles si vous gardez des secrets dans votre référentiel, car il n'y a pas d'authentification. Il ne fait pas la publicité de son existence, mais toute personne disposant d'un analyseur de port peut le trouver, s'y connecter et cloner votre référentiel.

Mais ce n'est pas super dangereux car il est en lecture seule par défaut. Lis legit daemon attentivement la page de manuel si vous pensez que vous souhaitez activer l'accès en écriture. Dans le cas où vous souhaitez obtenir les validations de votre collaborateur, il est beaucoup plus sûr de le laisser en lecture seule et de demander à votre collaborateur d'exécuter également cette commande, afin que vous puissiez les extraire.

Tangentiellement lié: au sujet des serveurs uniques, si vous souhaitez partager temporairement un tas de fichiers statiques via HTTP: python -m SimpleHTTPServer

Si vous avez besoin d'un serveur GIT bon et facile, vous devez essayer GitBlit. Aussi j'utilise gitolite mais seulement serveur, avec GitBlit vous obtenez tout en un, serveur, admin, repos. gestionnaire ... URL: http://gitblit.com/

https://rhodecode.com est une application web open source pour Git & Mercurial qui peut être installée très facilement sous n'importe quel système d'exploitation (un programme d'installation est inclus).

RhodeCode (la nouvelle version est appelée RhodeCode Enterprise) ajoute des fonctionnalités Git manquantes comme la révision de code et il est généralement très rapide et fiable.

Vous pouvez également installer Indefero , c'est un clone GPL de GoogleCode, car il prend en charge Subversion et Git, vous pouvez avoir une transition en douceur. Je suis l'auteur de Indefero.

Vous pouvez même installer GitHub sur votre serveur local (mais pas gratuitement):

https://enterprise.github.com/

Ce n'est peut- être pas la configuration de serveur git la plus courante , mais après avoir joué avec différentes dispositions, outils, miroirs et schémas d'autorisation, je dirais qu'une alternative assez solide pour les référentiels d'entreprise est Gerrit , ce qui peut sembler surprenant car il est plus connu sous le nom de outil de révision de code. Nous avons commencé à l'utiliser comme revue de code et il est lentement devenu notre référentiel principal, déconseillant g3 / gitolite

• Il est simple à déployer (vous déposez essentiellement le .war dans un tomcat)
• possède une interface utilisateur Web pour gérer les référentiels, les groupes et les autorisations (ou une interface ssh)
• a une implémentation java ssh et git intégrée, vous n'avez donc rien d'autre à configurer
• Prise en charge LDAP pour les utilisateurs et les groupes (généralement indispensable pour les entreprises)
• un système d'autorisation très flexible (avec des groupes de projets, l'héritage des autorisations, la restriction de lecture / écriture / branchement / écritures non révisées / etc)
• capacités de révision de code (si vous êtes dans ce truc)
• mise en miroir du référentiel (pour pousser certains référentiels vers github ou un autre référentiel public)

De plus, il est utilisé par de grands projets (par exemple Android, Chrome), donc il évolue et est maintenant assez solide. Donnez simplement à vos utilisateurs l'autorisation PUSH si vous souhaitez autoriser le contournement de la partie de révision du code.

Pour un hébergement à distance Comme d'autres l'ont dit, bitbucket.org propose des référentiels privés gratuits, je l'ai utilisé sans problème.

Pour le réseau local ou LAN, j'ajouterai celui-ci scm-manager.org (Un seul fichier exécutable, est vraiment simple à installer, il est fait sur Java pour pouvoir fonctionner sur Linux ou Windows). Juste au cas où vous l'installez, ce sont des mots de passe par défaut.

Username: scmadmin
Password: scmadmin

Entre-temps, le site d'hébergement Mercurial Bitbucket a également commencé à proposer des référentiels Git.

Donc, si vous n'avez pas besoin d'un serveur local , juste d'un endroit central où vous pouvez héberger gratuitement des référentiels Git privés, IMO Bitbucket est le meilleur choix.

Vous bénéficiez gratuitement de référentiels Git et Mercurial privés et publics illimités.
La seule limitation est que dans le plan gratuit, pas plus de cinq utilisateurs peuvent accéder à vos référentiels privés (pour plus, vous devez payer).
Voir https://bitbucket.org/plans pour plus d'informations!

Si vous voulez des pull pulls, il y a les projets open source de RhodeCode et GitLab et le Stash payant

Si vous voulez juste que votre référentiel soit dans un endroit central, c'est assez facile avec le contrôle de version distribué comme Git:
vous pouvez simplement placer votre référentiel central dans un dossier partagé sur une machine centrale et tout le monde peut le cloner à partir de là.

Si vous voulez un "vrai" site Web sur votre serveur local, je connais le site d'hébergement Git http://repo.or.cz .
Il semble avoir moins de fonctionnalités que GitHub, mais contrairement à GitHub, vous pouvez obtenir le code source et l'héberger sur votre propre serveur local.

Avertissement: je n'ai lu que repo.or.cz, je ne l'ai jamais essayé moi-même!

pour les configurations simples, vous pouvez fournir un accès ssh à un serveur central et configurer le répertoire de travail de chaque utilisateur pour pousser / tirer de cette «origine». Ce serait la configuration la plus simple et la plus courante pour les petites équipes.

Vous pourriez également examiner la gitose qui vous donne un serveur http et la possibilité de le gérer à distance. De cette façon, vous n'avez pas à accorder l'accès ssh et tout ce que cela implique à chaque committer.

Pour ajouter à ce que Chris a dit, vous pouvez utiliser gitosis (http://eagain.net/gitweb/?p=gitosis.git) pour contrôler qui peut réellement accéder au référentiel.

Selon votre utilisation, vous pouvez également utiliser des hooks (dans le dossier .git / hooks) afin que votre code soit automatiquement extrait dans le système de fichiers du serveur lorsque vous effectuez une poussée depuis votre machine locale. Voici un script populaire pour le faire: http://utsl.gen.nz/git/post-update . Cela ne sera cependant pas nécessaire dans tous les cas.

http://repo.or.cz , même si assez bon a tendance à avoir des problèmes avec certains utilisateurs.

Si vous êtes l'un d'eux, je vous recommande d'essayer http://unfuddle.com car vous venez d'un milieu subversion.

Découvrez " The 30 Second Tour ": http://unfuddle.com/about/tour/plans

http://code.google.com/p/luna-tool/ est une application scala qui implémente la plupart des parties nécessaires de moi de github