Qu'est-ce que Git et pourquoi vous devriez utiliser le contrôle de version si vous êtes développeur

Publicité

En tant que développeurs Web, la plupart du temps, nous avons tendance à travailler sur des sites de développement locaux, puis à tout télécharger lorsque nous avons terminé. C'est bien quand c'est juste toi et que les changements sont petits, mais quand tu as affaire à plus d'un personne travaillant sur quelque chose, ou sur un grand projet avec beaucoup de composants compliqués, ce n'est tout simplement pas réalisable. C'est à ce moment-là que nous passons à quelque chose appelé le contrôle de version.

Aujourd'hui, je vais parler d'un logiciel de contrôle de version open source appelé Git. Cela permet à plusieurs personnes de travailler en toute sécurité sur le même projet sans interférer les unes avec les autres, mais c'est bien plus que cela aussi.

Pourquoi utiliser un logiciel de contrôle de version?

Tout d'abord, le nom doit le révéler. Le logiciel de contrôle de version vous permet d'avoir des «versions» d'un projet, qui montrent les modifications qui ont été apportées au code au fil du temps, et vous permet de revenir en arrière si nécessaire et d'annuler ces modifications. Cette capacité à elle seule - de pouvoir comparer deux versions ou inverser les modifications, la rend assez précieuse lorsque vous travaillez sur des projets plus importants.

Vous l'avez probablement déjà fait vous-même à un moment donné, en sauvegardant des copies d'un projet à différents points afin d'avoir une sauvegarde. Dans un système de contrôle de version, seules les modifications seraient enregistrées - un fichier de correctif qui pourrait être appliqué à une version, afin de la rendre identique à la version suivante. Avec un développeur, cela suffit.

Mais que faire si plusieurs développeurs travaillent sur un projet? C’est là que l’idée d’un serveur de contrôle de version centralisé entre en jeu. Celles-ci sont la norme depuis longtemps, toutes les versions étant stockées sur un serveur central, et les développeurs individuels récupèrent et téléchargent les modifications sur ce serveur. Si vous avez déjà consulté l'historique des modifications d'une page Wikipédia, vous aurez une bonne idée de la façon dont cela fonctionne dans un scénario réel:

Les avantages d'un système comme celui-ci sont que plusieurs développeurs peuvent apporter des modifications, et chaque changement peut ensuite être attribué à un développeur spécifique. En revanche, le fait que tout soit stocké sur une base de données distante signifie qu'aucune modification ne peut être apportée lorsque ce serveur tombe en panne; et si la base de données centrale est perdue, chaque client n'a que la version actuelle de ce sur quoi il travaillait.

Cela nous amène à Git, et d'autres soi-disant systèmes de contrôle de version distribués. Dans ces systèmes, les clients ne se contentent pas de consulter la version actuelle des fichiers et de travailler à partir de ceux-ci: ils reflètent tout l'historique des versions. Chaque développeur a toujours une copie complète de tout. Un serveur central est toujours utilisé, mais si le pire se produit, tout peut toujours être restauré à partir de n'importe lequel des clients disposant des dernières versions.

Git fonctionne spécifiquement en prenant des «instantanés» de fichiers; si les fichiers restent inchangés dans une version particulière, il se lie simplement aux fichiers précédents - cela maintient tout rapide et léger.

Il peut également vous intéresser d'apprendre que Git est utilisé pour gérer et développer le noyau noyau Linux - le bloc de construction de base sur lequel toutes les distributions Linux sont construites.

Qu'est-ce que Github?

Bien que vous puissiez exécuter votre propre serveur Git localement, Github est à la fois un serveur distant, une communauté de développeurs et une interface Web graphique pour gérer votre projet Git. Il est gratuit à utiliser pour un maximum de 5 référentiels publics - c'est-à-dire, quand n'importe qui peut afficher ou bifurquer votre code - avec des plans à faible coût pour des projets privés. Je vous suggère fortement de vous inscrire pour un compte gratuit afin que vous puissiez commencer à jouer avec vos propres projets ou à chercher quelqu'un d'autre.

Forking & Branching

Ce sont des concepts fondamentaux de l'expérience Git, alors prenons un moment pour expliquer la différence.

Vous avez probablement entendu le "fork" du travail lorsque vous traitez avec des distributions Linux. Si vous connaissez l’application Media Center Plex, vous savez qu’elle était à l’origine un fork de l’open source similaire Xbox Media Center Aeon Nox 3.5: Thème magnifique et personnalisable pour XBMCConfigurez votre centre multimédia exactement comme vous le souhaitez. Aeon Nox 3.5 est la version la plus récente de ce qui est peut-être le meilleur thème pour XBMC, et c'est une combinaison rare: belle ... Lire la suite . Cela signifie simplement qu'à un moment donné dans le passé, certains développeurs ont pris le code de XBMC et ont décidé de suivre leur propre chemin; qui est devenu Plex.

Ceci est bien sûr totalement autorisé lorsque le projet est open source - vous pouvez prendre le code, faire ce que vous voulez avec. Avec Git, si vous pensez que vos modifications sont suffisamment bonnes pour être reprises dans le projet «maître», vous peut faire une «pull request» à l'auteur, lui demandant de ramener vos modifications dans leur original projet. Cela vous permet d'avoir des centaines de milliers de développeurs travaillant sur un projet à tout moment, dont aucun ne doit être nécessairement approuvés pour l'accès au code - ils copient simplement le code, apportent des modifications et demandent à être restaurés dans le Maître. Bien sûr, c'est au propriétaire du projet d'origine de décider s'il accepte ou non vos modifications.

Le branchement est quelque chose qui se fait en interne sur un projet par les développeurs autorisés. Il vous permet de séparer facilement des problèmes ou des fonctionnalités spécifiques et de les travailler sans casser les fichiers maîtres. Une fois que vous êtes convaincu que votre branche a résolu le problème, vous la fusionnez à nouveau dans le masque. À tout moment, il peut y avoir autant de branches que vous le souhaitez; ils n'interfèrent pas entre eux. Vous pouvez également fusionner les modifications entre les branches sans toucher au maître.

Voici un excellent diagramme d'un exemple de flux de travail par Vincent Driessen:

La prochaine fois, nous verrons comment configurer un exemple Git fonctionnel et effectuer des modifications de code dans les branches. Le contrôle de version est un sujet énorme. Je n'ai donné ici que la vue d'ensemble la plus brève, mais en tant que développeur qui est habitué à apporter des modifications et à les annuler si elles ne fonctionnent pas, le concept dans son ensemble m'a époustouflé - j'espère qu'il le fera aussi.

Êtes-vous un développeur expérimenté avec une expérience dans Git? Vous débutez et vous pensez que vous aimeriez vous lancer? Sonnez dans les commentaires!