Comment les développeurs d'applications professionnelles utilisent-ils les systèmes de contrôle de version, comme GIT et Subversion?

Je suis un développeur débutant et je me demande depuis le début comment les professionnels utilisent des outils comme GIT et Subversion (je n'ai pas une très bonne compréhension de ces outils) pour répondre aux besoins de leur projet. S'ils l'utilisent, comment pourrais-je mettre en place quelque chose comme ça?

Mes candidatures ne sont pas si grandes et je ne travaille pas encore en équipe, seraient-elles d'une grande aide pour moi?

Il y a des questions sur ce site sur la façon d'utiliser les outils, mais j'ai besoin d'une assistance pour les débutants.

Le contrôle des sources est omniprésent - on pourrait même dire que vous ne pouvez pas vous appeler un développeur professionnel si vous ne l'utilisez pas. Même lorsqu'il se développe seul, le contrôle de code source offre tout de même quelques avantages. En fin de compte, il fournit à la fois un historique et un vaste chemin d'annulation. Cela vous permet également d'expérimenter beaucoup plus, sachant que si vous n'aimez pas la nouvelle version, vous pouvez toujours revenir à ce que vous aviez auparavant.

Cela dit, les flux de travail, même au sein d'un système de contrôle de source comme Subversion ou Git, varient énormément d'une équipe à l'autre. Le meilleur endroit pour commencer est probablement de choisir un système de contrôle de source et de vous familiariser avec ses flux de travail standard (en gardant en tête que vous devrez changer de flux de travail tout au long de votre vie professionnelle).

Pour commencer, je recommanderais Git. Je suis un fan de Git, mais plus précisément, choisir Git gets vous permet de commencer par travailler sans serveur et de configurer un serveur uniquement lorsque cela vous convient. Subversion, en revanche, nécessite un serveur et sa configuration, bien que pas extrêmement difficile, est intimidante lorsque vous n'êtes pas familier avec ce genre de chose.

Voici un bon aperçu des quelques bonnes règles générales pour le contrôle des sources en général: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Lorsque vous travaillez seul, vous n'avez pas besoin de beaucoup de flux de travail. Engagez-vous tôt, engagez-vous souvent. Si vous commencez à déployer des versions, étiquetez vos versions. Créez des branches pour les expériences ou les longs travaux divergents (Git rend cela moins cher et plus simple que Subversion).

Les systèmes de contrôle des sources (SVN, Git, etc.) à un niveau très simpliste vous permettent de conserver l'historique des modifications des fichiers. Cela vous permet de voir comment votre code a changé au fil du temps et d'annuler les modifications que vous ne souhaitez peut-être pas (par exemple, la modification ne fonctionne pas comme prévu, vous pouvez rétablir le code dans un état précédemment connu). C'est quelque chose que même développer vous-même deviendra inestimable pour vous une fois que vous commencerez à l'utiliser.

Dès que vous travaillez avec d'autres personnes dans une équipe, les avantages augmentent encore plus car plusieurs personnes peuvent modifier le même fichier et si les modifications ne sont pas en conflit (par exemple 2 personnes modifient différentes sections du fichier) les modifications seront fusionnées automatiquement. En cas de conflit, vous pourrez voir vos modifications à côté de vos collègues et discuter avec eux de la manière de fusionner les modifications.

Vous pouvez également créer des instantanés de la base de code (généralement appelée balise) lors de la publication d'une version du code afin de pouvoir facilement déboguer les problèmes même si la source principale a évolué avec de nouvelles fonctionnalités qui n'ont peut-être pas encore été publiées.

Voici quelques ressources utiles:

Obtenir et exécuter Subversion et Tortoise SVN avec Visual Studio et .NET

Contrôle de version avec Subversion

Tutoriels pour débutants

Il existe d'excellents tutoriels (vidéo et texte) qui peuvent vous aider à démarrer à partir d'un niveau très basique. Git semble avoir une excellente approche pour introduire le sujet d'une manière douce pour les débutants qui vous explique pourquoi en premier et utilise la répétition, la définition et les graphiques pour vous aider à vous souvenir des noms et des fonctions des raccourcis clavier.

SVN

SVN se voulait mieux CVS. CVS (concurrent Version System) a travaillé sur des choses un fichier à la fois, SVN a généralement travaillé sur des choses un répertoire ou une arborescence de répertoires à la fois. SVN (et CVS ou d'autres systèmes) peut être important si vous l'utilisez au travail, mais mon avis est que nous améliorons considérablement notre compréhension de ce qu'il faut pour faire le contrôle de source toutes les quelques années, donc tout comme vous préféreriez un modèle tardif ordinateur, vous devriez préférer un outil de contrôle de source de modèle tardif. Changer de système représente un investissement énorme et l'historique du code peut être perdu, bien que pour de nombreux systèmes, il existe des convertisseurs qui vous permettent de migrer votre code ainsi que l'historique et d'autres artefacts créés par le système en cours de retrait.

Le contrôle de source professionnel répond aux besoins professionnels

Votre question "Comment les professionnels utilisent-ils des outils comme GIT et Subversion pour répondre aux besoins de leur projet?" est étroitement lié à la question "Comment les équipes travaillent-elles ensemble sans se gêner tout en travaillant le plus rapidement possible?"

Le code change fréquemment avec certains développeurs qui créent du code que d'autres développeurs utiliseront, et avec une variété d'intervenants ayant besoin de différents niveaux de stabilité par rapport à l'innovation. Les systèmes de contrôle des sources aident en stockant le code à l'usage de l'équipe, en gardant chaque changement en contexte avec des versions qui changent avec le temps et souvent aussi avec des branches qui sont des copies contrôlées du code qui servent à isoler des groupes de changements des autres groupes de changements.

Rassembler les choses, fusionner le travail de nombreux membres de l'équipe est une corvée qui, dans SVN et les anciens systèmes, était centralisée et difficile. Pour les équipes utilisant Git, la fusion devient plus simple et plus accessible à l'influence de toute l'équipe au lieu de quelques experts. Dans SVN, la branche peut être une affaire personnelle, mais la fusion a souvent des impacts douloureux sur l'équipe et le retour du code dans la ligne principale peut être douloureux du point de vue de l'obtention de l'autorisation, en évitant la casse et le niveau d'effort requis pour la tâche .

À partir d'un référentiel de contrôle de source établi, les professionnels peuvent répondre à d'autres besoins tels que le diagnostic des problèmes à leur cause première. S'il y avait des versions du code qui fonctionnaient auparavant et des problèmes récemment détectés qui se produisent dans la version actuelle, il est possible d'avancer et de reculer dans l'historique pour localiser le problème. Dans SVN, cette capacité est immature, mais dans Git, la recherche de la dernière version fonctionnant / première défaillante est prise en charge par une commande appelée git bisect. Le problème sera causé par l'un des changements de source entre les deux versions, ce qui est potentiellement un diagnostic beaucoup plus facile qu'une recherche de la base de code entière.

Désolé de divaguer, j'espère que cela vous aidera à utiliser le contrôle de code source.

Mon équipe utilise un système de contrôle de version d'équipe développé localement. (Malheureusement, Git ne semble pas encore fonctionner sur les fichiers source "natifs" d'IBM i). Mais personnellement, une fois que j'ai extrait la source de ce système, j'utilise Git pendant mon développement, jusqu'à ce que le projet soit terminé et que je le revienne dans le équipe VCS.

Comme on dit en votant ... engagez-vous tôt, engagez-vous souvent. Alors que je travaille sur de nouvelles fonctionnalités, je m'engage. Je m'engage entre les compilations et à chaque tentative de correction des erreurs du compilateur, chaque fois que j'apporte des modifications pendant les tests et le débogage. Cela permet de tester plus facilement plusieurs variantes sur un thème et de le retirer facilement si nécessaire, en particulier lorsqu'une modification est coordonnée sur plusieurs fichiers.

Git a amélioré ma façon d'aborder le développement.