Configurer le nouveau système, apprendre à l’utiliser et connaître les avantages et les inconvénients
Les systèmes de contrôle de version sont des outils logiciels qui aident les développeurs à suivre et à gérer les modifications apportées au code source. Il existe plusieurs systèmes de contrôle de version différents, chacun avec son propre ensemble de fonctionnalités et de capacités.
Certains systèmes de contrôle de version populaires incluent Git, Mercurial et Subversion. Tous ces systèmes de contrôle de version sont conçus pour aider les développeurs à collaborer sur des projets, à suivre les modifications apportées à leur code et à conserver un historique de leur travail. Dans cet article, je parlerai d’un nouvel acteur sur le terrain, développé en interne par Meta — Sapling.
Étant donné que nous avons déjà Git, Mercurial et Subversion, entre autres, il est difficile de voir exactement pourquoi nous avons besoin d’un autre système de contrôle de version. Comme le dit Meta, Sapling se concentre spécifiquement sur la convivialité et l’évolutivité, mentionnant que les flux de travail courants sont plus simples et qu’il est beaucoup plus facile de se remettre des erreurs. De plus, Meta a conçu Sapling et Sapling Server pour qu’ils soient hautement évolutifs, capables de gérer des dizaines de millions de fichiers.
Sapling SCM (gestion du code source) se compose de trois parties :
- Sapling CLI, un outil de ligne de commande que les utilisateurs utilisent pour cloner des référentiels, effectuer des validations et envoyer leurs modifications au serveur
- Sapling Server, une application backend côté serveur, qui héberge et gère les référentiels.
- Sapling Virtual Filesystem, un système de fichiers utilisé par Sapling pour accélérer le flux de travail.
À la fin de 2022, seule Sapling CLI est publiée, tandis que Sapling Server et Virtual Filesystem ne sont pas encore disponibles au public. La bonne nouvelle est que vous pouvez utiliser Sapling avec vos référentiels Git existants, et il s’intègre même parfaitement à GitHub !
Pour obtenir Sapling, vous pouvez suivre le guide d’installation officiel, disponible ici. Pour votre commodité, voici les étapes d’installation de Sapling sur votre système :
Pour macOS — installez depuis Homebrew en utilisant cette commande :
$ brew install sapling
Pour les fenêtres – télécharger la dernière version ZIP et exécutez ces commandes dans PowerShell :
PS> Expand-Archive NAME_OF_DOWNLOADED_ZIP 'C:\\Program Files'
PS> setx PATH "$env:PATH;C:\\Program Files\\Sapling" -m
Notez que pour utiliser toutes les fonctionnalités disponibles, vous devez également avoir Gite et Nœud installée.
Pour Ubuntu 22.04 — exécutez les commandes suivantes :
$ curl -L -O <
$ sudo apt install -y ./sapling_0.1.20221213-150011-h9b0acf12_amd64.Ubuntu22.04.deb
Pour Ubuntu 20.04 — exécutez ces commandes :
$ curl -L -O <
$ sudo apt install -y ./sapling_0.1.20221213-150011-h9b0acf12_amd64.Ubuntu20.04.deb
Pour les autres Linux — vous pouvez installer Sapling de Homebrew si vous l’avez :
$ brew install sapling
Si vous n’avez pas Homebrew, votre seule autre option est le construire à partir de la sourcepour le moment.
Après avoir installé Sapling sur votre système, sl
La commande devrait être disponible dans votre terminal. Pour commencer à l’utiliser, vous devez d’abord configurer votre identité. Il est utilisé pour autoriser vos commits et vous pouvez le configurer comme ceci :
$ sl config --user ui.username "YOUR NAME <YOUR EMAIL>"
# for example...
$ sl config --user ui.username "Michael Krasnov <[email protected]>"
Après avoir exécuté cela, Sapling devrait être prêt à partir. Cependant, si vous souhaitez utiliser Sapling avec GitHub, vous devez configurer l’authentification GitHub pour Sapling. La méthode recommandée consiste à installer la CLI GitHub (gh
) et en exécutant cette commande :
$ gh auth login --git-protocol https
À mon avis, c’est exagéré d’avoir 2 outils pour travailler avec les dépôts GitHub. Vous pouvez le faire fonctionner sans GitHub CLI si vous créez un jeton d’accès personnel et donnez-le à Sapling lorsqu’on lui a demandé.
Passons maintenant en revue quelques flux de travail de base pour avoir une idée de l’utilisation de Sapling dans des projets réels. J’ai créé un fork du repo Redux sur mon compte GitHub pour jouer avec. Commençons par cloner les dépôts depuis Github. Pour cloner un dépôt depuis GitHub à l’aide de Sapling, exécutez cette commande :
$ sl clone <GITHUB REPO URL>
# for example...
$ sl clone <https://github.com/r3dm1ke/redux>
Nous obtenons une sortie qui semble familière à tous ceux qui ont utilisé Git dans le passé :
remote: Enumerating objects: 20640, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 20640 (delta 1), reused 1 (delta 1), pack-reused 20633
Receiving objects: 100% (20640/20640), 23.78 MiB | 2.27 MiB/s, done.
Resolving deltas: 100% (13183/13183), done.
From https://github.com/r3dm1ke/redux
* [new ref] fbfe51458ca2addf97f426d505bf2c27503a5ff1 -> remote/master
452 files updated, 0 files merged, 0 files removed, 0 files unresolved
Maintenant vous pouvez cd
dans votre projet cloné et vérifiez que tout a fonctionné en exécutant le sl
commande:
$ sl
@ fbfe51458 Dec 15 at 10:20 65634467+Ahmed-Hakeem remote/master
│ change reducer type validation place (#4452)
~
Par défaut, le sl
La commande nous montre le dernier commit dans le référentiel, ainsi que tous vos propres commits dans votre pile (plus à ce sujet plus tard).
Pour voir l’historique complet des commits dans Sapling, exécutez le sl log
commande:
$ sl log
changeset: fbfe51458ca2addf97f426d505bf2c27503a5ff1 (@)
user: Hakeem <65634467+Ahmed-Hakeem@users.noreply.github.com>
date: Thu, 15 Dec 2022 10:20:08 -0500
summary: change reducer type validation place (#4452)changeset: a0754310222ad61bde675078963afb7fc038d5d7
user: Mark Erikson <mark@isquaredsoftware.com>
date: Mon, 05 Dec 2022 10:49:27 -0500
summary: Merge pull request #4448 from jshoung/docs/remove-dead-link
changeset: 89104853174e62de8ebbca4881ea14a04399f4e2
user: julian <julianks@gmail.com>
date: Mon, 05 Dec 2022 10:00:58 -0500
summary: Remove link to deleted tweet
changeset: 9be553a2c5ba04d9d769f31e25a6dc93deb334cf
user: Mark Erikson <mark@isquaredsoftware.com>
date: Wed, 30 Nov 2022 10:12:49 -0500
summary: Merge pull request #4447 from mariussd/patch-1
...
Voyons maintenant comment s’engager et pousser fonctionnent dans Sapling. Tout d’abord, je vais apporter mes modifications au projet :
$ echo "PS Redux is awesome" >> README.md
$ touch newfeature.js
$ echo "TODO: write new feature" >> newfeature.js
$ sl status
M README.md
? newfeature.js
sl status
commande fonctionne de la même manière que git status
. Vous pouvez voir que Sapling voit que nous avons modifié README.md
et créé newfeature.js
. Le point d’interrogation à côté de newfeature.js
signifie que nous n’avons pas add
encore:
$ sl add newfeature.js
$ sl status
M README.md
A newfeature.js
Nous pouvons aller de l’avant et valider les changements. Pour valider les modifications dans Sapling, exécutez cette commande :
$ sl commit -m "Initial work for my new feature"
$ sl
@ b6989309b 2 seconds ago mihalKrasnov
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
Vous pouvez voir notre nouveau commit dans la vue graphique. Pour vous montrer plus de fonctionnalités, allons-y et ajoutons d’autres commits :
$ echo "Developed new exiting feature!" >> CHANGELOG.md
$ sl commit -m "Updated changelog"
$ echo "const feature = () => console.log('abacaba')" >> newfeature.js
$ sl commit -m "Feature implementation"
$ sl
@ 8c9eb0035 1 second ago mihalKrasnov
│ Feature implementation
│
o e445f1379 87 seconds ago mihalKrasnov
│ Updated changelog
│
o b6989309b 3 minutes ago mihalKrasnov
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
Vous pouvez maintenant voir 3 commits dans votre pile. Notez que le commit le plus récent est marqué d’un @
. Vous pouvez vous déplacer dans votre pile à l’aide de commandes sl prev
et sl next
:
$ sl prev
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
[e445f1] Updated changelog$ sl
o 8c9eb0035 4 minutes ago mihalKrasnov
│ Feature implementation
│
@ e445f1379 5 minutes ago mihalKrasnov
│ Updated changelog # NOTICE THAT @ IS NOW HERE
│
o b6989309b 7 minutes ago mihalKrasnov
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
$ sl prev
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ sl
o 8c9eb0035 4 minutes ago mihalKrasnov
│ Feature implementation
│
o e445f1379 5 minutes ago mihalKrasnov
│ Updated changelog
│
@ b6989309b 7 minutes ago mihalKrasnov
╭─╯ Initial work for my new feature # AND NOW HERE
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
$ sl next 2
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
[8c9eb0] Feature implementation
$ sl
@ 8c9eb0035 4 minutes ago mihalKrasnov
│ Feature implementation # AND BACK UP
│
o e445f1379 5 minutes ago mihalKrasnov
│ Updated changelog
│
o b6989309b 7 minutes ago mihalKrasnov
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
Disons maintenant que je ne suis pas satisfait de l’implémentation de ma fonctionnalité et que je souhaite annuler mon dernier commit. Pour annuler votre dernier commit dans Sapling, exécutez cette commande : sl uncommit
:
$ sl uncommit
$ sl
# FIRST COMMIT GONE!
@ e445f1379 9 minutes ago mihalKrasnov
│ Updated changelog
│
o b6989309b 11 minutes ago mihalKrasnov
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
$ sl status
M newfeature.js # CHANGES ARE UNTOUCHED
Enfin, après avoir corrigé le dernier changement, nous voulons pousser nos changements et ouvrir une pull request. Puisque Sapling s’intègre à GitHub, c’est très simple : il suffit d’exécuter cette commande pour pousser et ouvrir une demande d’extraction : sl pr
$ sl pr
pushing 3 to https://github.com/r3dm1ke/redux
created new pull request: https://github.com/r3dm1ke/redux/pull/1
created new pull request: https://github.com/r3dm1ke/redux/pull/2
created new pull request: https://github.com/r3dm1ke/redux/pull/3
Vous pouvez voir que Sapling a créé 3 pull requests, une pour chaque commit. Cela semble contre-intuitif et carrément criminel, en particulier lors de l’utilisation de GitHub. En fait, cela est destiné à être utilisé avec ReviewStack, une interface utilisateur pour parcourir les demandes d’extraction GitHub faites par Meta. Vous pouvez en savoir plus à ce sujet ici.
Une autre fonctionnalité utile est la visualisation des statuts PR à partir de la ligne de commande. Une fois que vous avez ouvert vos pull requests, exécutez sl ssl
pour obtenir leurs statuts :
$ sl ssl
@ b615c1183 7 minutes ago mihalKrasnov #4458 Closed ✓
│ Implementation
│
o e445f1379 17 minutes ago mihalKrasnov #4457 Closed ✓
│ Updated changelog
│
o b6989309b 19 minutes ago mihalKrasnov #4456 Closed ✓
╭─╯ Initial work for my new feature
│
o fbfe51458 Dec 15 at 10:20 remote/master
│
~
Sapling n’est pas un programme purement CLI, mais il est également livré avec une interface graphique. L’utilisation d’une interface graphique pour le contrôle de version peut être plus conviviale et plus facile à utiliser que les interfaces de ligne de commande, et peut offrir des fonctionnalités visuelles telles que des représentations graphiques des branches et des historiques de validation. Cependant, les applications GUI peuvent être plus lentes et moins personnalisables que les CLI.
Pour ouvrir l’interface graphique de Sapling, exécutez cette commande : sl web
$ sl web
started a new serveraccess Sapling Web with this link:
http://localhost:3011/?token=
Si vous ouvrez cette URL, vous verrez l’interface utilisateur :
À l’aide de cette interface utilisateur, vous pouvez voir l’historique des commits, ouvrir les PR, les diffs, effectuer des modifications et des commits, et synchroniser les changements avec le serveur. Cependant, je ne l’ai pas trouvé particulièrement utile et je continuerais à utiliser GitKraken pour tout ce qui concerne l’interface graphique.
Sapling est un système de contrôle de version qui partage de nombreuses caractéristiques avec Git, comme être distribué, utiliser des commits avec adresse de hachage et avoir des branches appelées « signets », ainsi qu’un workflow similaire impliquant clone, pull, push, commit et rebase. Cependant, il existe également plusieurs différences notables entre les deux systèmes.
- Les succursales locales ne sont pas nécessaires : dans Git, votre référentiel est défini par la présence de branches locales, et vous devez être sur une branche locale pendant que vous travaillez. En revanche, Sapling vous permet d’utiliser des signets locaux (l’équivalent des branches Git) si vous le souhaitez, mais ils ne sont pas nécessaires. Au lieu de cela, vous pouvez simplement référencer vos commits par leurs valeurs de hachage, qui sont visibles dans l’affichage « smartlog ».
- Téléchargements partiels : wLorsque vous clonez ou tirez d’un référentiel dans Git, vous récupérez généralement toutes les nouvelles données. Dans Sapling, un clone ou un pull ne récupère que les branches principales du référentiel, les autres branches étant récupérées selon les besoins.
- Fonctionnalités d’annulation : cette fonctionnalité sera certainement appréciée par la communauté. Sapling propose des commandes dédiées « uncommit », « unamend », « unhide » et « undo » pour annuler les actions courantes, et la commande « undo -i » vous permet de prévisualiser les effets de plusieurs annulations avant de les appliquer.
- Pas de zone de transit : Git vous demande d’ajouter des modifications à une zone de staging avant de les valider, mais Sapling n’a pas de zone de staging. Si vous souhaitez valider ou modifier seulement une partie de vos modifications, vous pouvez utiliser une option interactive pour sélectionner les modifications spécifiques ou créer un commit temporaire et le modifier avant de le plier dans le véritable commit.
- Interface utilisateur intégrée: ce serait une fonctionnalité bienvenue par ceux qui n’aiment pas utiliser la CLI
Je voudrais terminer avec une liste de mes avantages et inconvénients personnels après avoir utilisé Sapling pendant un certain temps. Il convient de noter que ce ne sont là que quelques avantages et inconvénients potentiels, et les avantages et inconvénients réels de l’utilisation de Sapling dépendront de vos besoins spécifiques et de votre cas d’utilisation.
Avantages
- Sapling se sent comme une bouffée d’air frais après avoir utilisé Git pendant de nombreuses années. Les flux de travail (du moins ceux que j’utilise) semblent plus simples, Sapling se sent un peu plus rapide et les commandes sont plus intuitives
- Les commandes d’annulation sont des bouées de sauvetage, et je suis beaucoup plus confiant en utilisant les fonctionnalités avancées de VCS dans Sapling quand je sais à quel point il est facile de tout annuler
Les inconvénients
- L’absence de branchement me semble contre-intuitif. Lorsque de nombreuses personnes travaillent sur un référentiel, il est très facile de voir toutes les branches et de basculer entre elles, et de rebaser d’autres modifications sur votre branche. Peut-être que cela viendra avec l’expérience, mais pour l’instant, je préfère la branche de Git au bookmarking de Sapling
- Un PR par commit : bien que cela puisse avoir un sens lorsque vous utilisez Sapling Server ou ReviewStack, cela est inutile avec vanilla GitHub
- Sapling est encore en début de développement, il lui manque donc de nombreuses fonctionnalités dont dispose Git, par exemple, les crochets Git (à la fois côté client et côté serveur), le support de la communauté, les outils et les interfaces utilisateur.
Je ne vais pas encore passer de Git à Sapling, mais c’est très excitant et je suis content qu’il y ait de la concurrence dans le monde VCS. J’attendrai également avec impatience la sortie du serveur Sapling et du système de fichiers virtuel, et je leur présenterai également mon avis.