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.