Pourquoi les gens disent-ils toujours que Linus déteste SVN ? C'est parce qu'il doit être connecté à Internet pour l'utiliser, donc il n'en a pas besoin. C'est comme si GIT pouvait être utilisé sans Internet. serveur distant sans Internet ?
Il est vrai que vous devrez éventuellement être connecté à Internet pour fusionner avec le code d’autres personnes.
Mais ce que cette phrase signifie, c'est que Git vous n'avez pas besoin 总是 d'être connecté à Internet pour la gestion des versions, car il dispose d'un entrepôt local. Vous pouvez effectuer localement de nombreuses tâches liées à la gestion des versions sans avoir besoin d'une connexion Internet, comme créer des branches, soumettre, restaurer du code, etc.
Pour les équipes régulières à petite échelle qui sont toujours assises dans un bureau et travaillent en utilisant un réseau local, elles ne seront peut-être pas en mesure d'apprécier pleinement les avantages de Git En d'autres termes, pour les situations générales, SVN est suffisant.
Cependant, pour les équipes « non conventionnelles » où les membres du projet peuvent être répartis n'importe où, Git peut être mieux.
Au départ, je voulais vous répondre directement dans les commentaires, mais il y a beaucoup de contenu, je vais donc l'ajouter ici.
Il ressort de vos doutes que vous ne comprenez peut-être pas très bien l'essence de 版本管理. La version dans la gestion des versions ne fait pas uniquement référence à la version finale du logiciel. Les versions 0.8, 1.0 et 2.0 ne sont que des versions destinées aux utilisateurs finaux. Le 版本管理 dans 版本 fait généralement référence aux états intermédiaires du programme au cours du processus de développement. Certaines de ces versions doivent être fusionnées dans la version publique, et certaines pourraient éventuellement être abandonnées, voire évoluer vers un autre projet par la suite. On peut dire qu'à chaque fois que vous appuyez sur Ctrl+S, vous créez une version.
Afin de mieux expliquer l'essence de la gestion des versions, permettez-moi de donner quelques exemples supplémentaires. C'est ce que nous rencontrons souvent dans la vie quotidienne.
Scénario 1
J'ai une idée sur cette fonction qui est en cours de développement, mais je ne sais pas si c'est réalisable, donc je compte l'essayer d'abord, mais je ne veux pas la changer directement dans l'espace de travail (le l'espace de travail dans SVN correspond souvent directement à la version principale), car cela contaminera le code existant. Si vous constatez plus tard que cette méthode n'est pas réalisable, vous devrez supprimer tout le code associé, mais vous ne vous souviendrez peut-être pas de ce qui doit être supprimé. à ce moment-là.
Il peut également être implémenté dans un outil de contrôle de version centralisé comme SVN (donc de nombreuses fonctions et fonctionnalités sont tout simplement plus pratiques), c'est-à-dire en utilisant des branches, mais de cette façon, je dois toujours gérer fréquemment le serveur, créer des branches , Supprimer des branches, fusionner des branches, valider le code dans des branches, etc. Mais en fait, je peux faire toutes ces choses localement (encore une fois, cela n'est peut-être pas un gros problème dans le réseau local). Je crée une succursale dans l'entrepôt local, la code et la teste si cela fonctionne, la fusionne dans le. version principale. Si cela ne fonctionne pas, je peux le fusionner dans la version principale. Peu importe si cela fonctionne.
Scénario 2
J'ai trouvé qu'un programme dans une certaine soumission était incorrect (par exemple, une certaine fonction n'était qu'à moitié modifiée et ne pouvait pas être utilisée, et même la compilation échouait. À ce moment-là, je ne pouvais que restaurer rapidement le serveur). , mais il est peut-être trop tard, quelqu'un d'autre a peut-être vérifié votre code et vous devrez envoyer un e-mail de groupe expliquant le problème (ou simplement crier dessus si tout le monde est ensemble).
Mais dans Git, comme il est d'abord soumis localement, cela donne au comportement de soumission un temps tampon, me permettant de l'annuler à temps sans affecter les autres personnes (si vous le trouvez trop tard, vous ne pouvez rien faire).
Scénario 3
Il existe également la capacité de rollback "local". Une fonction est relativement complexe et prend plusieurs jours à développer, mais je ne veux pas la soumettre au serveur avant qu'elle ne soit développée, car je ne veux pas l'affecter. d'autres personnes en raison d'erreurs de compilation ou d'exécution. Je voulais donc tout changer localement puis le soumettre, mais de cette façon, ces programmes ne sont pas garantis. Si je veux revenir en arrière, comparer avec le code précédent, etc., c'est difficile de le faire.
Certains outils fournissent également la fonction d'historique local, mais elle n'est pas facile à utiliser. L'histoire locale ne peut pas être comparée à la version. Chaque fois que vous Ctrl+S pouvez ou non créer une histoire locale. En d’autres termes, l’histoire locale ne conserve pas les archives comme vous le souhaiteriez. Il est très probable qu'un document historique dont vous avez un besoin urgent ne soit pas sauvegardé, et vous ne pouvez que soupirer en le regardant (ce problème n'est en effet pas si rare)
Résumé
Cela dit, ce ne sont que quelques exemples secondaires entre centralisé et distribué. En fait, ce problème est tout comme l'orientation objet et l'orientation processus. Il n'y a pas de bon ou de mauvais absolu. Il est peut-être préférable d'utiliser l'orientation objet pour des programmes complexes, mais l'orientation processus n'est pas sans mérite. Le choix des outils dépend de l'équipe et des décisions individuelles
Le questionneur est trop concentré sur l'avantage de git qui peut être utilisé hors ligne par une seule personne. Git est une structure distribuée, ce qui signifie que l'intégrité de ses données est destinée à être bien meilleure que celle de svn. un entrepôt svn se produit (très facilement ! Par exemple, une panne de courant), et toutes les soumissions historiques exportées avec svndump ont également des problèmes inexplicables.
De plus, l'échelle des projets auxquels le sujet peut être exposé est encore relativement petite, et ils utilisent toujours git comme svn, ils se concentrent donc sur les conflits et les problèmes de fusion. Ce que je veux dire, c'est que bien sûr, les conflits doivent être résolus, mais l'objectif fondamental de la gestion des versions n'est pas seulement de fusionner le code et de résoudre les conflits. Le plus important est peut-être de permettre à chacun de travailler sans affecter les autres et les versions
.
L'utilisation de git par notre entreprise suit l'approche git flow. Master est utilisé pour les versions principales (projets Web, il s'agit donc d'une version stable qui est constamment itérée), et develop est utilisé pour les tests. est créée à partir de la branche de développement. Une branche de fonctionnalités, après avoir terminé le travail, fusionnez-la à nouveau pour développer, créez une version et testez-la dans l'environnement de test, puis fusionnez la version dans la version principale et attendez la suivante. release Le but de dire ceci est d'améliorer, en Lorsque vous travaillez sur votre propre branche de fonctionnalités, vous n'avez pas vraiment besoin de trop vous soucier de ce qui se passe sur la branche de développement (il n'est pas nécessaire d'interagir avec le serveur central ), mais le besoin de gestion des versions existe toujours pour compléter une fonctionnalité. Cela nécessite de vous engager plusieurs fois pour la résoudre S'il s'agit d'un correctif qui doit être réparé de toute urgence, créez une branche de correctif à partir de master et fusionnez-la. revenir au master (et au développement) une fois les modifications terminées
Grâce à ces moyens, il est en grande partie résolu
Le développement d'une nouvelle fonctionnalité n'affectera pas le développement d'autres nouvelles fonctionnalités (chaque fonctionnalité est une branche indépendante)
Les mises à niveau vers la nouvelle version (en cours de développement) et les corrections de bugs vers l'ancienne version (master) n'entreront pas en conflit ou ne s'affecteront pas, et ne provoqueront pas de bugs dans l'ancienne version de master simplement parce que quelqu'un développe un nouvelle version. Vous devez attendre que la nouvelle version soit développée avant de pouvoir la lancer immédiatement
Je peux dire que bien que SVN en soit capable, sa fonction de branchement est essentiellement un autre répertoire dans l'entrepôt. La fusion ou non est en fait enregistrée via un attribut, ce qui n'est certainement pas facile à utiliser
.
Supplément :
Vous pouvez consulter http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA % E9%A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE a introduit de nombreuses bonnes pratiques git
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Il est vrai que vous devrez éventuellement être connecté à Internet pour fusionner avec le code d’autres personnes.
Mais ce que cette phrase signifie, c'est que
Gitvous n'avez pas besoin总是d'être connecté à Internet pour la gestion des versions, car il dispose d'un entrepôt local. Vous pouvez effectuer localement de nombreuses tâches liées à la gestion des versions sans avoir besoin d'une connexion Internet, comme créer des branches, soumettre, restaurer du code, etc.Pour les équipes régulières à petite échelle qui sont toujours assises dans un bureau et travaillent en utilisant un réseau local, elles ne seront peut-être pas en mesure d'apprécier pleinement les avantages de
GitEn d'autres termes, pour les situations générales,SVNest suffisant.Cependant, pour les équipes « non conventionnelles » où les membres du projet peuvent être répartis n'importe où,
Gitpeut être mieux.Au départ, je voulais vous répondre directement dans les commentaires, mais il y a beaucoup de contenu, je vais donc l'ajouter ici.
Il ressort de vos doutes que vous ne comprenez peut-être pas très bien l'essence de
版本管理. La version dans la gestion des versions ne fait pas uniquement référence à la version finale du logiciel. Les versions 0.8, 1.0 et 2.0 ne sont que des versions destinées aux utilisateurs finaux. Le版本管理dans版本fait généralement référence aux états intermédiaires du programme au cours du processus de développement. Certaines de ces versions doivent être fusionnées dans la version publique, et certaines pourraient éventuellement être abandonnées, voire évoluer vers un autre projet par la suite. On peut dire qu'à chaque fois que vous appuyez surCtrl+S, vous créez une version.Afin de mieux expliquer l'essence de la gestion des versions, permettez-moi de donner quelques exemples supplémentaires. C'est ce que nous rencontrons souvent dans la vie quotidienne.
Scénario 1
J'ai une idée sur cette fonction qui est en cours de développement, mais je ne sais pas si c'est réalisable, donc je compte l'essayer d'abord, mais je ne veux pas la changer directement dans l'espace de travail (le l'espace de travail dans SVN correspond souvent directement à la version principale), car cela contaminera le code existant. Si vous constatez plus tard que cette méthode n'est pas réalisable, vous devrez supprimer tout le code associé, mais vous ne vous souviendrez peut-être pas de ce qui doit être supprimé. à ce moment-là.
Il peut également être implémenté dans un outil de contrôle de version centralisé comme SVN (donc de nombreuses fonctions et fonctionnalités sont tout simplement plus pratiques), c'est-à-dire en utilisant des branches, mais de cette façon, je dois toujours gérer fréquemment le serveur, créer des branches , Supprimer des branches, fusionner des branches, valider le code dans des branches, etc. Mais en fait, je peux faire toutes ces choses localement (encore une fois, cela n'est peut-être pas un gros problème dans le réseau local). Je crée une succursale dans l'entrepôt local, la code et la teste si cela fonctionne, la fusionne dans le. version principale. Si cela ne fonctionne pas, je peux le fusionner dans la version principale. Peu importe si cela fonctionne.
Scénario 2
J'ai trouvé qu'un programme dans une certaine soumission était incorrect (par exemple, une certaine fonction n'était qu'à moitié modifiée et ne pouvait pas être utilisée, et même la compilation échouait. À ce moment-là, je ne pouvais que restaurer rapidement le serveur). , mais il est peut-être trop tard, quelqu'un d'autre a peut-être vérifié votre code et vous devrez envoyer un e-mail de groupe expliquant le problème (ou simplement crier dessus si tout le monde est ensemble).
Mais dans Git, comme il est d'abord soumis localement, cela donne au comportement de soumission un temps tampon, me permettant de l'annuler à temps sans affecter les autres personnes (si vous le trouvez trop tard, vous ne pouvez rien faire).
Scénario 3
Il existe également la capacité de rollback "local". Une fonction est relativement complexe et prend plusieurs jours à développer, mais je ne veux pas la soumettre au serveur avant qu'elle ne soit développée, car je ne veux pas l'affecter. d'autres personnes en raison d'erreurs de compilation ou d'exécution. Je voulais donc tout changer localement puis le soumettre, mais de cette façon, ces programmes ne sont pas garantis. Si je veux revenir en arrière, comparer avec le code précédent, etc., c'est difficile de le faire.
Certains outils fournissent également la fonction d'historique local, mais elle n'est pas facile à utiliser. L'histoire locale ne peut pas être comparée à la version. Chaque fois que vous
Ctrl+Spouvez ou non créer une histoire locale. En d’autres termes, l’histoire locale ne conserve pas les archives comme vous le souhaiteriez. Il est très probable qu'un document historique dont vous avez un besoin urgent ne soit pas sauvegardé, et vous ne pouvez que soupirer en le regardant (ce problème n'est en effet pas si rare)Résumé
Cela dit, ce ne sont que quelques exemples secondaires entre centralisé et distribué. En fait, ce problème est tout comme l'orientation objet et l'orientation processus. Il n'y a pas de bon ou de mauvais absolu. Il est peut-être préférable d'utiliser l'orientation objet pour des programmes complexes, mais l'orientation processus n'est pas sans mérite. Le choix des outils dépend de l'équipe et des décisions individuelles
Le questionneur est trop concentré sur l'avantage de git qui peut être utilisé hors ligne par une seule personne. Git est une structure distribuée, ce qui signifie que l'intégrité de ses données est destinée à être bien meilleure que celle de svn. un entrepôt svn se produit (très facilement ! Par exemple, une panne de courant), et toutes les soumissions historiques exportées avec svndump ont également des problèmes inexplicables.
De plus, l'échelle des projets auxquels le sujet peut être exposé est encore relativement petite, et ils utilisent toujours git comme svn, ils se concentrent donc sur les conflits et les problèmes de fusion. Ce que je veux dire, c'est que bien sûr, les conflits doivent être résolus, mais l'objectif fondamental de la gestion des versions n'est pas seulement de fusionner le code et de résoudre les conflits. Le plus important est peut-être de permettre à chacun de travailler sans affecter les autres et les versions
.L'utilisation de git par notre entreprise suit l'approche git flow. Master est utilisé pour les versions principales (projets Web, il s'agit donc d'une version stable qui est constamment itérée), et develop est utilisé pour les tests. est créée à partir de la branche de développement. Une branche de fonctionnalités, après avoir terminé le travail, fusionnez-la à nouveau pour développer, créez une version et testez-la dans l'environnement de test, puis fusionnez la version dans la version principale et attendez la suivante. release
Le but de dire ceci est d'améliorer, en Lorsque vous travaillez sur votre propre branche de fonctionnalités, vous n'avez pas vraiment besoin de trop vous soucier de ce qui se passe sur la branche de développement (il n'est pas nécessaire d'interagir avec le serveur central ), mais le besoin de gestion des versions existe toujours pour compléter une fonctionnalité. Cela nécessite de vous engager plusieurs fois pour la résoudre
S'il s'agit d'un correctif qui doit être réparé de toute urgence, créez une branche de correctif à partir de master et fusionnez-la. revenir au master (et au développement) une fois les modifications terminées
Grâce à ces moyens, il est en grande partie résolu
Le développement d'une nouvelle fonctionnalité n'affectera pas le développement d'autres nouvelles fonctionnalités (chaque fonctionnalité est une branche indépendante)
Les mises à niveau vers la nouvelle version (en cours de développement) et les corrections de bugs vers l'ancienne version (master) n'entreront pas en conflit ou ne s'affecteront pas, et ne provoqueront pas de bugs dans l'ancienne version de master simplement parce que quelqu'un développe un nouvelle version. Vous devez attendre que la nouvelle version soit développée avant de pouvoir la lancer immédiatement
Je peux dire que bien que SVN en soit capable, sa fonction de branchement est essentiellement un autre répertoire dans l'entrepôt. La fusion ou non est en fait enregistrée via un attribut, ce qui n'est certainement pas facile à utiliser
.Supplément :
Vous pouvez consulter http://git-scm.com/book/zh/v1/%E5%88%86%E5%B8%83%E5%BC%8F-Git-%E4%B8%BA % E9%A1%B9%E7%9B%AE%E4%BD%9C%E8%B4%A1%E7%8C%AE a introduit de nombreuses bonnes pratiques git
C'est la différence entre centralisé et distribué.