svn est un système de gestion de versions centralisé et le successeur du CVS plus traditionnel. Il s'agit d'une structure C/S typique : il existe un entrepôt central qui stocke différentes versions du code du projet. Les développeurs n'ont qu'une seule version à la fois dans cet entrepôt localement. S'ils souhaitent d'autres versions, ou des versions synchronisées, ils doivent communiquer avec ce serveur central pour les obtenir. Imaginez un scénario extrême, si le disque dur du serveur central est détruit, vous ne pouvez pas reconstruire toutes les versions du projet à partir de votre propre disque dur. Même si vous êtes le seul développeur de ce projet, toutes les versions sont créées sur votre disque dur.
Et git est un système de gestion de versions distribué, ce qui signifie qu'il n'y a pas de serveur central. Vous allez créer un référentiel (Repository) pour le code d'un projet, qui pourra vous aider à gérer le code de ce projet même si vous ne le développez que seul. Cet entrepôt peut être considéré comme le serveur central de SVN, qui contient toutes les versions du code. Bien entendu, vous n’avez pas besoin d’être en ligne pour interagir vous-même avec ce référentiel.
Alors pour le développement d’équipe, tout le monde n’a-t-il pas un entrepôt ? Oui. Chaque développeur dispose d'un référentiel personnel pour ce projet, et le statut de ces référentiels est égal. Ces entrepôts peuvent être synchronisés via des opérations telles que le clonage, le pull, le push, etc. qui ne sont pas disponibles dans SVN. Cela rend git beaucoup plus flexible que svn. Bien entendu, ce modèle distribué posera beaucoup de problèmes si les membres de l’équipe choisissent leurs propres méthodes de gestion des versions. Par conséquent, l’équipe doit choisir une stratégie de gestion de versions unifiée.
En pratique, un entrepôt neutre est généralement établi, non sur la machine d'un membre, et le laisse agir comme arbitre de l'équipe. Le référentiel git de chaque membre accepte de se synchroniser avec ce référentiel central. Des sites Web tels que github.com et bitbucket.com fournissent des services d'hébergement pour le référentiel central. Bien entendu, ces sites Web fournissent actuellement davantage de services, tels que l'exploitation de pages Web, les relations publiques, etc.
Le système de gestion de versions distribué n'est pas seulement git, mais aussi Hg et ainsi de suite. Mais git est le plus mature et a le plus de support. En particulier, github.com a élargi ses scénarios d'utilisation grâce à la socialisation et à d'autres idées.
En pratique, SVN n'a aucun avantage par rapport à git. En termes d’installation et d’utilisation personnelle, les deux sont tout aussi pratiques. En termes d'équipes de projet, git est plus facile à gérer. L'implémentation de git est extrêmement fiable et efficace, ce qui encourage grandement le développement multi-branches. Les stratégies avancées de travail d'équipe telles que git-flow dans la pratique de git rendent git encore plus précieux.
Bien sûr, git a plus d'opérations que svn en théorie, et il y a beaucoup plus de concepts à apprendre. Mais les comprendre en vaut vraiment la peine.
Enfin, je recommande le logiciel SourceTree. Il est bien plus beau que la gestion de versions dans les IDE généraux, et est très intuitif et facile à prendre en main pour les novices.
Veuillez faire attention à votre orthographe lorsque vous poserez des questions à l'avenir, et veuillez ne pas accepter la question sans résoudre le problème pour donner aux autres le soupçon d'acquérir de l'expérience.
Ce genre de question est trop ouvert et difficile à répondre de manière ciblée. Même si vous y répondez, vous ne pourrez peut-être pas obtenir beaucoup d'aide.
Je pense que git est plus social, c'est-à-dire que vous voulez faire connaître votre idée aux autres. Bien sûr, je fais référence à https://github.com/.
Git est très pratique à utiliser, sauf que la vitesse d'accès de github n'est pas très optimiste, mais dans l'ensemble elle est bonne.
Je n'ai pas beaucoup utilisé svn, mais j'ai entendu dire qu'il existe un concept (logiciel) appelé git-svn. Je pense que maîtriser git me suffit.
SVN est un système de contrôle de version centralisé. Un projet n'a qu'une seule bibliothèque de versions correspondante, et tous les membres du projet le soumettent au serveur via le réseau. Il a des fonctions telles que la copie légère et la sauvegarde des copies originales, mais il existe des problèmes tels que des points de défaillance uniques et des retards de réseau inhérents aux systèmes centralisés.
Git est un système de contrôle de version distribué développé pour Linus. Il présente une conception unique, des performances élevées et des habitudes d'utilisation très différentes des autres systèmes de contrôle.
Matériel de référence : "Git Authoritative Guide" Jiang Xin
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
svn est un système de gestion de versions centralisé et le successeur du CVS plus traditionnel. Il s'agit d'une structure C/S typique : il existe un entrepôt central qui stocke différentes versions du code du projet. Les développeurs n'ont qu'une seule version à la fois dans cet entrepôt localement. S'ils souhaitent d'autres versions, ou des versions synchronisées, ils doivent communiquer avec ce serveur central pour les obtenir. Imaginez un scénario extrême, si le disque dur du serveur central est détruit, vous ne pouvez pas reconstruire toutes les versions du projet à partir de votre propre disque dur. Même si vous êtes le seul développeur de ce projet, toutes les versions sont créées sur votre disque dur.
Et git est un système de gestion de versions distribué, ce qui signifie qu'il n'y a pas de serveur central. Vous allez créer un référentiel (Repository) pour le code d'un projet, qui pourra vous aider à gérer le code de ce projet même si vous ne le développez que seul. Cet entrepôt peut être considéré comme le serveur central de SVN, qui contient toutes les versions du code. Bien entendu, vous n’avez pas besoin d’être en ligne pour interagir vous-même avec ce référentiel.
Alors pour le développement d’équipe, tout le monde n’a-t-il pas un entrepôt ? Oui. Chaque développeur dispose d'un référentiel personnel pour ce projet, et le statut de ces référentiels est égal. Ces entrepôts peuvent être synchronisés via des opérations telles que le clonage, le pull, le push, etc. qui ne sont pas disponibles dans SVN. Cela rend git beaucoup plus flexible que svn. Bien entendu, ce modèle distribué posera beaucoup de problèmes si les membres de l’équipe choisissent leurs propres méthodes de gestion des versions. Par conséquent, l’équipe doit choisir une stratégie de gestion de versions unifiée.
En pratique, un entrepôt neutre est généralement établi, non sur la machine d'un membre, et le laisse agir comme arbitre de l'équipe. Le référentiel git de chaque membre accepte de se synchroniser avec ce référentiel central. Des sites Web tels que github.com et bitbucket.com fournissent des services d'hébergement pour le référentiel central. Bien entendu, ces sites Web fournissent actuellement davantage de services, tels que l'exploitation de pages Web, les relations publiques, etc.
Le système de gestion de versions distribué n'est pas seulement git, mais aussi Hg et ainsi de suite. Mais git est le plus mature et a le plus de support. En particulier, github.com a élargi ses scénarios d'utilisation grâce à la socialisation et à d'autres idées.
En pratique, SVN n'a aucun avantage par rapport à git. En termes d’installation et d’utilisation personnelle, les deux sont tout aussi pratiques. En termes d'équipes de projet, git est plus facile à gérer. L'implémentation de git est extrêmement fiable et efficace, ce qui encourage grandement le développement multi-branches. Les stratégies avancées de travail d'équipe telles que git-flow dans la pratique de git rendent git encore plus précieux.
Bien sûr, git a plus d'opérations que svn en théorie, et il y a beaucoup plus de concepts à apprendre. Mais les comprendre en vaut vraiment la peine.
Enfin, je recommande le logiciel SourceTree. Il est bien plus beau que la gestion de versions dans les IDE généraux, et est très intuitif et facile à prendre en main pour les novices.
Si vous n'avez pas besoin de plusieurs sites nécessitant un développement et une fusion à distance, svn suffit. Et c'est relativement simple.
La plupart d'entre eux utilisent git maintenant
Veuillez faire attention à votre orthographe lorsque vous poserez des questions à l'avenir, et veuillez ne pas accepter la question sans résoudre le problème pour donner aux autres le soupçon d'acquérir de l'expérience.
Ce genre de question est trop ouvert et difficile à répondre de manière ciblée. Même si vous y répondez, vous ne pourrez peut-être pas obtenir beaucoup d'aide.
Je pense que git est plus social, c'est-à-dire que vous voulez faire connaître votre idée aux autres. Bien sûr, je fais référence à https://github.com/.
Git est très pratique à utiliser, sauf que la vitesse d'accès de github n'est pas très optimiste, mais dans l'ensemble elle est bonne.
Je n'ai pas beaucoup utilisé svn, mais j'ai entendu dire qu'il existe un concept (logiciel) appelé git-svn. Je pense que maîtriser git me suffit.
Les autres personnes de haut niveau ont répondu.
Beaucoup de gens auraient dû avoir du mal avec ça, cliquez ici pour le vérifier.
SVN est un système de contrôle de version centralisé. Un projet n'a qu'une seule bibliothèque de versions correspondante, et tous les membres du projet le soumettent au serveur via le réseau. Il a des fonctions telles que la copie légère et la sauvegarde des copies originales, mais il existe des problèmes tels que des points de défaillance uniques et des retards de réseau inhérents aux systèmes centralisés.
Git est un système de contrôle de version distribué développé pour Linus. Il présente une conception unique, des performances élevées et des habitudes d'utilisation très différentes des autres systèmes de contrôle.
Matériel de référence : "Git Authoritative Guide" Jiang Xin
En fait, j'ai aussi cette question. J'ai maintenant un Win7 et un Linux, mais comment puis-je les laisser soumettre un partage de code ensemble