Si vous avez déjà travaillé avec des collègues sur un document, vous connaissez cette douleur :quelqu'un prend la première passe (document.doc ), puis l'envoie par e-mail à tout le monde. La personne suivante fait de même, ainsi que la troisième, chacune portant une révision (document_rev3.doc ) au nom du fichier. La responsable aime ce qu'elle voit et le marque comme complet (document_final.doc )... jusqu'à ce que des changements de dernière minute arrivent (document_final_Aaron's changes_reviewed_by_Bob_now_really_final.doc ).
Imaginez maintenant des changements comme celui-ci dans des dizaines de fichiers de code source. Les programmeurs ont créé des systèmes de contrôle de version (VCS) pour résoudre ce problème. Ils sont de nature un peu technique, mais peuvent également être utiles pour les utilisateurs expérimentés. Regardons les bases du contrôle de version en utilisant le meilleur système aujourd'hui, Git .
L'objectif principal des VCS est de capturer des versions (également appelées révisions ) d'un fichier dans le temps. Cela signifie ne pas compter sur des méthodes grossières comme celle décrite ci-dessus. Dans ces systèmes, lorsque vous accédez à "document.doc", vous travaillez par défaut sur la version la plus récente. Mais vous pouvez également revenir dans l'historique du fichier et récupérer les versions antérieures. Les systèmes conçus spécifiquement pour gérer les versions de fichiers ont commencé dans le développement de logiciels, mais ont également fait leur chemin dans des applications plus « grand public ».
Les applications de contrôle de version sont à l'origine apparues comme un moyen d'empêcher les programmeurs de casser le code des autres. Les premiers systèmes permettaient simplement aux utilisateurs de verrouiller les fichiers d'autres modifications, tandis que les systèmes de deuxième génération (tels que Subversion) ajoutaient la vérification de l'intégralité du projet à partir d'un référentiel central.
Alors que ces systèmes de deuxième génération sont encore largement utilisés, l'industrie migre vers des systèmes de troisième génération. La principale caractéristique de ces systèmes est qu'ils sont distribués , ce qui signifie qu'il n'y a pas de référentiel central. Au lieu de cela, chaque utilisateur a sa propre copie complète du référentiel (y compris toutes les révisions antérieures). Mais toutes les modifications (même les révisions complètes) sont "locales" jusqu'à ce qu'il les "pousse" vers un autre référentiel. Cet utilisateur peut ensuite extraire un clone afin d'apporter des modifications et de répéter le processus.
La possibilité de capturer plusieurs versions de la même chose est également une fonctionnalité courante pour les utilisateurs moyens. Avec un accès à un stockage moins cher, à la fois sur la machine locale et via des services cloud faciles à utiliser, les utilisateurs ont désormais la possibilité de suivre l'historique de leurs fichiers. Les programmes à usage général le font de plusieurs façons.
Systèmes d'exploitation peut capturer un historique de fichiers ou de dossiers. Cela peut se produire automatiquement chaque fois qu'un fichier est enregistré ou selon un calendrier régulier. Certaines applications de bureau vous permettent également de capturer des versions ou des instantanés de fichiers. Par exemple, LibreOffice fournit la fonctionnalité "Enregistrer la version" (comme illustré dans l'image du haut ci-dessous) qui vous permet d'enregistrer plusieurs versions du document dans un seul fichier. Enfin, les applications Web/cloud telles que Google Drive, ownCloud, etc. conserveront également les anciennes itérations d'un fichier ou d'un document (comme indiqué pour Google Docs dans l'image du bas ci-dessous), soit dans les coulisses, soit à votre demande expresse.
Étant donné que toutes ces options au niveau du système d'exploitation ou de l'application existent déjà, pourquoi s'embêter avec ces outils de programmation ringards ? Les méthodes ci-dessus présentent quelques inconvénients, notamment :
Si l'un ou l'ensemble de ces problèmes vous donne envie de quelque chose de plus, consultez la section suivante où nous les résolvons avec Git .
Dans les sections suivantes, nous passerons en revue chacune de ces étapes pour un projet très important :cet article. Nous le ferons en utilisant la version en ligne de commande de Git. Connaître les commandes du terminal facilitera la recherche de leurs équivalents graphiques et vous garantira de pouvoir les utiliser sur toutes les plates-formes.
Si git n'est pas installé sur votre machine (les Mac le font, comme certaines distributions Linux), vous pouvez soit récupérer le programme d'installation Windows à partir de la page de téléchargement du projet, soit l'installer sur Linux avec une commande (spécifique à votre distribution) telle que :
sudo apt install git La prochaine chose que nous devons faire est de mettre en place un dépôt git , qui est juste un dossier contenant votre projet. Pour tirer parti de la gestion des versions de Git, vous devez initialiser le dossier en tant que référentiel. Vous pouvez le faire en ligne de commande avec la commande suivante :
git init 
Vous ne verrez peut-être rien une fois que cela sera terminé, mais activez l'option "Afficher les fichiers cachés" dans votre gestionnaire de fichiers, et vous verrez qu'il y a un nouveau .git dossier (comme indiqué dans l'image ci-dessus). C'est là que git conserve toutes ses informations afin qu'elles ne vous gênent pas.
L'étape suivante consiste à créer du contenu (fichiers) dans votre projet. Il peut s'agir de n'importe quel type de fichier, car la plupart des projets de programmation sont constitués de code (texte) et d'actifs tels que des graphiques (binaires). Une fois créé, procédez comme suit sur la ligne de commande tout en restant dans le répertoire de votre projet :
statut git 
La première étape d'un commit consiste à « mettre en scène » les éléments nouveaux ou mis à jour. Vous voyez comment la sortie ci-dessus vous permet de savoir qu'il y a des modifications "sans mise en scène" ? Vous pouvez tout mettre en scène dans votre répertoire (de manière récursive, c'est-à-dire pour inclure les sous-dossiers et leurs fichiers) avec cette commande :
git -a . Le drapeau "-a" est pour "ajouter" et le point fait référence au répertoire courant. Il s'agit essentiellement de dire "ajouter tous les fichiers à mon commit". Maintenant, pour faire le commit, tapez ce qui suit :
git commit -m "WHOOP, mon premier commit !" 
Maintenant, lorsque vous vérifiez à nouveau l'état, il ne devrait y avoir aucun changement en attente. Pour voir le commit lui-même, consultez le journal git, en utilisant le mode graphique , avec la liste réduite à une ligne , et décoré pour plus de lisibilité :
git log --all --decorate --oneline --graph 
Cela vous montrera une belle chronologie de votre engagement, avec le plus récent en haut.
Pendant que vous travaillez, vous voudrez peut-être partir dans une direction particulière, sans savoir si cela va marcher. Pour cela, vous devrez créer une branche avec la commande suivante :
expérience de branche git1
git checkout experiment1 
La deuxième commande vous fait basculer vers la branche "experiment1". Vous pouvez revenir en arrière en le remplaçant par "maître". Lorsque vous commencez à travailler sur votre texte, notez la différence entre le même fichier de chaque branche. Tout d'abord, la branche "experiment1" avec votre nouveau texte :
Comparez ceci à l'original :
Maintenant, après avoir travaillé pendant un certain temps (se terminant par un nouveau commit), le mieux que vous puissiez trouver est "Lorem ipsum dolor sit amet...?" Qu'est-ce que c'est? C'est un non-sens et devrait être immédiatement supprimé de votre projet. Vous pouvez supprimer votre branche avec la commande suivante ("-D" pour forcer la suppression) :
git branch -D experiment1 
Maintenant, démarrez une autre branche et ajoutez quelque chose d'intelligent, ainsi que quelques images :
expérience de branche git2
git checkout experiment2 git add . git commit -m "Plus de texte, images ajoutées" 
Enfin, une fois que vous êtes satisfait des modifications apportées à votre branche actuelle, la commande suivante les fusionnera avec la branche "master". À condition que vous n'ayez pas fait beaucoup de va-et-vient entre les deux, cela entraînera l'application de toutes vos nouvelles modifications et la création d'une nouvelle révision. Ce qui suit sur la ligne de commande les combinera pour vous :
git merge experiment2 
Vous aurez maintenant une révision qui combine la dernière version de "master" avec la dernière version de "experiment2". À ce stade, vous pouvez vous débarrasser de l'expérience (elle a réussi après tout) avec ce qui suit :
git branch -d experiment2 Notez que vous ne perdrez que les modifications incrémentielles que vous avez apportées dans cette branche si vous le faites.
Enfin, Git est un outil distribué système, ce qui signifie que vous pouvez avoir plusieurs copies de votre référentiel et les synchroniser. Par exemple, créez un nouveau référentiel sur un serveur auquel vous pouvez accéder en SSH avec cette commande :
git init --bare Le drapeau "--bare" le définit comme une sorte de référentiel en lecture seule, en ce sens que vous ne pouvez pas modifier les fichiers directement. Ensuite, vous pouvez définir cela comme une copie distante de votre référentiel local avec ce qui suit (la première commande garantit que de nouvelles branches locales sont créées à distance) :
git config push.default correspondant
git remote add central ssh://[username]@[URL]/path/to/repository git push --set-upstream central master 
Avec la configuration ci-dessus, vous pouvez suivre un processus simple pour conserver tout le travail que vous effectuez sur un projet non seulement versionné, mais également sauvegardé.
Les avantages des systèmes de contrôle de version vous intéressent ? Ou les applications de sauvegarde non développées suffisent-elles à vos besoins ? Faites-nous part de vos réflexions dans les commentaires ci-dessous !