Ajouter un fichier sur GitLab : Les méthodes essentielles
Pourquoi ajouter des fichiers à votre projet ?
Dans le monde du développement, un projet vide n'est qu'une coquille. Les fichiers sont les briques qui composent votre application. Que ce soit du code source, de la documentation ou des fichiers de configuration, chaque ajout permet de faire progresser votre travail de manière concrète.
Imaginez que votre projet GitLab est un chantier de construction. Créer le dépôt était l'étape de préparation du terrain. Ajouter des fichiers sur GitLab, c'est commencer à poser les briques pour monter les murs. Plus vous ajoutez de fichiers organisés, plus votre "maison" logicielle prend forme et devient fonctionnelle.
Sur GitLab, il existe deux méthodes principales pour enrichir votre dépôt : passer par la ligne de commande (CLI) ou utiliser directement l'interface web de GitLab. Nous allons voir comment maîtriser ces deux approches.
Ajouter un fichier via la ligne de commande (CLI)
C'est la méthode préférée des développeurs car elle est rapide et permet d'automatiser beaucoup de tâches. C'est aussi la manière la plus propre de travailler quand vous avez déjà effectué le clonage du projet sur votre ordinateur.
Créer le fichier localement
Placez-vous dans le dossier de votre projet et utilisez la commande suivante pour créer un nouveau fichier vide :
touch mon_nouveau_fichier.txtVérifier la présence du fichier
Vous pouvez vérifier que le fichier a bien été créé en listant le contenu de votre répertoire :
ls -lRésultat :
Information importante
N'oubliez pas qu'après la création du fichier, vous devez effectuer un git add, un git commit et un git push pour envoyer vos modifications afin qu'elles soient visibles par vos collègues sur GitLab.
Ajouter un fichier via l'interface Web
Parfois, vous avez juste besoin de faire une petite modification ou d'ajouter une note rapide sans vouloir ouvrir votre terminal. Pour cela, l'interface web de GitLab est idéale car elle inclut un éditeur de texte intégré permettant d'enregistrer des modifications en quelques clics.
Accéder au menu d'ajout
Depuis le tableau de bord de votre projet, cherchez le bouton avec le symbole + situé juste à côté du sélecteur de branche. Cliquez dessus et choisissez l'option New file.
"Le bouton plus permet d'effectuer des actions rapides sur le dépôt"
Rédiger le contenu
Donnez un nom à votre fichier (par exemple NewDemoFile) et écrivez votre texte dans l'éditeur. Pour valider l'ajout, vous devez descendre en bas de page et cliquer sur le bouton Commit changes.
"L'éditeur web est parfait pour des modifications textuelles simples"
Confirmation du succès
Une fois que vous avez validé, GitLab vous affiche un message de confirmation vert. Votre fichier est maintenant officiellement enregistré dans l'historique de votre projet.
Conclusion
Vous savez maintenant comment enrichir votre projet, que ce soit en mode expert avec le terminal ou de manière plus visuelle avec l'interface web. Gérer ses fichiers sur GitLab est la base du quotidien d'un développeur moderne.
Cependant, plus vous ajoutez de fichiers et de modifications, plus l'historique de votre projet peut devenir complexe. Parfois, il est nécessaire de "réorganiser" cet historique pour qu'il reste propre. C'est ce qu'on appelle l'opération de Rebase Git, que nous allons explorer dans le prochain chapitre.
Espace commentaire
Écrire un commentaire
Vous devez être connecté pour poster un message !
19 commentaires
actif
Genre, le tuto fait bien la distinction entre `touch` localement et la création web. Mais on est bien d'accord que l'approche recommandée reste le Git Flow, même pour un fichier README ?
Génial. Rappel important : `git add .` couvre tous les nouveaux fichiers sans avoir besoin de faire `git add mon_fichier.txt` manuellement. L'automatisation, c'est ça qui compte.
J'ai arrêté de faire ça. Passer par l'interface web, c'est acceptable pour une
Mais c'est un vrai anti-pattern. Si on veut un historique, on passe par le CLI. Sinon, on risque des commits non tracés ou des merge issues.
Le `commit changes` en web, ça envoie quand même un commit GitLab. C'est pas *tellement* bidon, mais ça confirme que le CLI reste le Gold Standard pour le workflow.
Pour des docs rapides ou des
actif
Le `ls -l` est basique, oui. Mais le fait de bien comprendre le résultat (`-rw-r--r--`) est crucial pour diagnostiquer les permissions quand un runner échoue sur le deployment.
Exact. L'info sur le `git add`, `git commit`, `git push` est essentielle. C'est le point où les juniors se perdent toujours.
secouriste
On est d'accord que l'éditeur web doit être réservé aux changements de métadonnées ou aux petites mises à jour de README ? Pour le code source, c'est un risque sécurité et de traçabilité.
J'avoue, c'est pratique de faire un commit de documentation vite fait via l'UI, mais je recommande toujours de faire un pré-commit hook local pour s'assurer que le formatage est nickel avant le push.
Méthode web : ça passe pour une petite correction au fly. Mais si tu manipules du JSON ou du YAML, le CLI, même pour juste un `vi` local, est bien plus sûr contre les problèmes de syntaxe.
Le concept de base est là, mais il faut vraiment insister sur la gestion des branches. Créer un fichier ne suffit pas si tu pushes sur `main` sans passer par un MR.
+1. Le fait que tu mentionnes `touch` puis `git add` puis `git commit` c'est la *bonne* séquence. C'est le workflow qu'on doit vendre aux équipes.
Petit bémol : quand tu utilises l'UI, le message de commit est souvent plus générique. Il faut y accorder autant d'attention que sur le CLI pour que le contexte soit clair.
Vu qu'on parle de fichiers, et surtout de config files (YAML, ENV, etc.), j'ai plutôt tendance à utiliser des secrets managers (Vault, AWS Secrets Manager) plutôt que de les jeter même en documentation sur GitLab. Bonne pratique, mais point de vigilance.
Le meilleur usage de l'UI, c'est pour générer des fichiers de base (boilerplate) en copiant/collant, mais toujours en les validant localement après. Ça garantit que les hooks CI/CD fonctionnent sur ta machine.
Le *clonage du projet* est vraiment le point de départ. Quand on maîtrise ça, la ligne de commande devient presque triviale. La web UI, c'est le mode
actif secouriste
Pas de stress sur la méthode, mais sur la rigueur des étapes. Peu importe si on utilise l'éditeur web ou `nano`, si le `commit message` est mauvais, le history est pourri.
Je trouve ça super clair. On est souvent tentés d'aller par le chemin facile de l'UI, mais tu rappelles bien que le CLI force une meilleure méthodologie de traçabilité. C'est la différence entre le dev junior et le dev senior.