"Aujourd'hui, je vais vous parler des deux programmes de contrôle de version les plus populaires : SVN et Git."
"SVN fonctionne à peu près comme je l'ai décrit dans la dernière leçon. Git est un peu plus compliqué, et je prévois d'en discuter plus en détail."
"Pouvez-vous me donner des liens vers la documentation pour SVN et Git ?"
"Bien sûr, juste une seconde."
http://svnbook.red-bean.com/en/1.7/svn-book.html
https://githowto.com (c'est tout simplement un chef-d'œuvre)
"Alors, Git ."
"C'est un peu plus compliqué que SVN. Avec Git, chaque utilisateur a son propre référentiel local en plus du référentiel du serveur. "
« Alors, où vous engagez-vous ? »
"Les utilisateurs s'engagent toujours dans leur référentiel local."
"Mais qu'en est-il du référentiel du serveur?"
"Pour synchroniser les référentiels locaux et serveur, il existe des commandes Pull et Push spéciales .
"Il y a une raison à cela. Parfois, un programmeur doit faire beaucoup de travail de sa part, ce qui peut impliquer plusieurs centaines de commits avant de pouvoir l'ajouter au référentiel partagé."
"Pour ce faire dans SVN, vous devez démarrer une branche distincte, puis la fusionner avec le tronc."
"Avec Git, vous vous engagez simplement toujours dans le référentiel local, puis envoyez toutes les modifications par lots au référentiel central sur le serveur lorsque vous avez terminé."
"Cette méthode peut sembler un peu excessive lorsque vous n'écrivez qu'un petit code. Mais lorsque vos tâches sont si importantes qu'elles s'étendent sur plusieurs semaines, vous comprenez que vous ne pouvez pas écrire tout ce temps sans vous engager."
"Pourquoi ne pouvez-vous pas simplement travailler pendant deux semaines, puis valider vos modifications sur le serveur une seule fois ?"
"Eh bien, un programme de contrôle de version offre beaucoup de commodités."
"Imaginez que vous vous engagez tous les jours et que le 10e jour, vous découvrez que les modifications que vous avez apportées au cours des deux derniers jours ne fonctionneront pas comme prévu. Et vous voulez revenir au code que vous aviez le 8e jour et aborder la tâche différemment."
"Vous annulez simplement les modifications apportées au référentiel local au cours des deux derniers jours et revenez à l'état souhaité. C'est ce qu'on appelle une opération de restauration ."
« Tu es en train de me dire que tu peux faire ça ?
"Oui. De plus, comme l'historique des validations est stocké, vous pouvez savoir quand et pourquoi quelque chose a été validé, et par qui, les fonctionnalités/bogues pertinents, et quels dix fichiers ont été modifiés simultanément dans le cadre de ce travail."
"Supposons que la correction de bogue de quelqu'un casse le code de quelqu'un d'autre. Vous pouvez simplement revenir en arrière ( rollback ) le code et procéder comme si le changement ne s'était jamais produit."
"OK, c'est cool. Je suis convaincu. Pourriez-vous me montrer quelques exemples illustrant comment tout cela fonctionne ?"
"Bien sûr."
"Voici comment cloner le référentiel central sur votre ordinateur local :"
"Ainsi, l'opération Checkout n'est plus nécessaire."
"Oui. Et voici des exemples d' opérations Push :"
"Et les opérations Pull :
"Ah. Cela a plus ou moins de sens."
"Au fait, il existe un service sympa appelé GitHub."
"Tout programmeur peut s'y inscrire et créer ses propres référentiels Git. Je vous suggère de vous familiariser avec cela."
"Voici quelques liens utiles :"
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
https://articles.assembla.com/using-git/getting-started/set-up-git-on-windows-with-tortoisegit
"Notez qu'il y a pas mal de clients Git."
"Tout d'abord, il y a GitBash , qui vous permet d'entrer des commandes de texte."
"Ensuite, il y a TortoiseGit , qui est un bon programme intégré à l'Explorateur Windows. Il vous permet de travailler avec des fichiers dans un référentiel Git directement dans l'Explorateur."
"IntelliJ IDEA prend en charge Git et vous permet d'exécuter toutes sortes de commandes complexes en quelques clics directement depuis l'environnement."
« Alors, lequel dois-je apprendre ? »
"Je vous recommande de les connaître tous."
"Vous passerez votre entretien et arriverez au travail. Vous obtiendrez un lien vers Git, un identifiant et un mot de passe - et c'est tout. Ensuite, vous serez seul."
"Qu'est-ce que tu veux dire, "tout seul"?"
"Je veux dire que vous allez configurer Git par vous-même, extraire une copie du référentiel par vous-même,…"
"Et ensuite, vous devrez construire et essayer d'exécuter le projet."
"Les instructions de construction seront également très probablement dans le référentiel Git, avec la documentation du projet."
« Votre chef d'équipe viendra vous voir dans la soirée et vous dira : « Eh bien, qu'avez-vous compris jusqu'à présent ? » "
"Et vous direz : 'J'essaie d'installer Git ici, mais je n'ai pas encore réussi. "Vous n'allez pas me virer, n'est-ce pas ?" "
"Ou, alors qu'il est encore midi, vous pouvez vous adresser au chef d'équipe et lui dire : "J'ai installé Git, extrait le projet et parcouru la documentation, mais il y a des centaines de fichiers et je n'ai pas encore tout trié. Où sont les instructions de construction actuelles ?'» "
« Pouvez-vous sentir la différence ?
"Oui. Dans le second cas, je suis un programmeur super rock-star, mais dans le premier, je suis un robo-doofus qui ne sait même pas comment sortir un projet de Git. En d'autres termes, j'ai merdé avant même que je commence à programmer. Je suppose qu'après cela, ils ne m'ont même pas laissé écrire de code.
"Vous voyez, vous avez répondu à vos propres questions. Alors étudiez et réfléchissez. Personne ne le fera pour vous."
« Tu ne vas pas m'aider ?
"J'ai déjà aidé. Nous enseignons Java ici, au cas où vous l'auriez oublié. Pour tout le reste, vous êtes seul. Ou est-ce que votre tête est juste pour boire?"
"D'accord, j'ai compris. Merci, Bilaabo!"