Il était une fois, dans le royaume du développement, un développeur nommé John. En plein milieu d'un projet complexe, qui impliquait des fichiers de configuration .env et .yaml pour se connecter à une API tournant dans un conteneur Docker, John a commis l'impensable : il a ouvert un dépôt contenant une clé API Mailgun en clair dans un fichier .env utilisé pour la configuration du docker compose.

À peine avait-il réalisé son erreur qu'un désastre s'annonçait. Non seulement sa clé d'API avait été compromise, mais son compte Mailgun avait également été coupé, le plongeant dans un tourbillon de préoccupations. Une procédure rigoureuse devait être suivie pour le réactiver, impliquant la réinitialisation des mots de passe et des clés d'API. Une perte de temps énorme qui plongea notre petit John dans une énorme tristesse.

Face à l'urgence de partager son code Python avec un autre développeur pour résoudre un problème pressant, John a décidé d'agir. Bien que la meilleure solution aurait été de monter un vault sécurisé, le temps pressait. Il a donc opté pour un mécanisme de nettoyage et de restauration connu sous le nom de "smudge and clean".

[filter "secrets"]
    clean = ../scripts/filter-secrets.sh clean
    smudge = ../scripts/filter-secrets.sh smudge

…

Most software developers use Git on a daily basis. But how many truly understand Git? Do you feel like you know what's going on under the hood as you use Git to perform various tasks?

For example, what happens when you use git commit? What is stored between commits? Is it just a diff between the current and previous commit? If so, how is the diff encoded? Or is an entire snapshot of the repository stored each time?

Most people who use Git don't know the answers to the questions posed above. But does it really matter? Do you really have to know all of those things?

I'd argue that it does matter. As professionals, we should strive to understand the tools we use, especially if we use them all the time, like Git.

Dans ce cours, nous allons commencer par expliquer ce qu’est Git. Pour cela, nous allons définir ce qu’est un système de gestion de version et comprendre en quoi Git est différent des autres systèmes de gestion de version et pourquoi il est si populaire.

Nous allons ensuite découvrir les fonctionnalités principales de Git et apprendre à les utiliser. Nous apprendrons notamment à créer un nouveau dépôt Git avec la commande git init ou à cloner un dépôt existant avec git clone, à observer l’état d’un projet avec git status, à ajouter des fichiers à l’index avec git add, à valider des modifications avec git commit, etc.

Nous étudierons également le système de branches de Git qui est l’un des composants qui rendent ce système de version très puissant et flexible.

Finalement, nous découvrirons GitHub et apprendrons à gérer nos différents dépôts et à travailler sur des dépôts hébergés.

Une spécification ajoutant une signification lisible pour l'humain et pour la machine dans les messages des commits

KDE Invent (Gitlab)

Ici nous allons voir comment avoir plusieurs profils Git (email, clé GPG, etc) en fonction du ou des répertoires le tout automatiquement.

TL;DR :
Modifier le fichier .gitconfig

[include]
    path = ~/.config/git/git-personal.conf
[includeIf "gitdir:~/dev/work/"]
    path = ~/.config/git/git-work.conf

• Ansible
• ASCII Code
• Docker
• Docker Compose
• Git
• Kubernetes
• Linux
• Markdown
• Minikube
• Mongodb
• Npm
• Proxmox
• Tensorflow
• Terminal Escape Code
• Tmux

Browse 1158 short code snippets for all your development needs on 30 seconds of code.

Gogs is a painless self-hosted Git service.

Dans les deux premiers billets de cette série, nous avons vu comment créer notre bucket de base, configurer notre nom de domaine, et manipuler rapidement Hugo. Dans ce dernier billet de la série, nous allons donc passer à l'étape manquante : le déploiement. Automatiser le déploiement sur Scaleway

Une spécification ajoutant une signification lisible pour l'homme et pour la machine dans les messages des commits

How to Write Better Git Commit Messages – A Step-By-Step Guide

GitHub repo: pvdlgconventional-changelog-metahub conventional-changelog preset

The best way to store your dotfiles: A bare Git repository

Use readme.so's markdown editor and templates to easily create a ReadMe for your projects

Create repository

cd path_to_central_reposity_folder_on_usb_stick
git init --bare --shared=all

Clone repository

cd path_to_where_i_want_my_files_on_computer
git clone path_to_central_reposity_on_usb

Commit changes

git add -A
git commit -m "Made some changes!"

Push changes to USB stick

git push origin master

Get changes

git pull origin master

Find useful forks of GitHub projects

Dans une application, il est souvent nécessaire d’utiliser des secrets. Ces secrets peuvent servir à se connecter à une base de données, à accéder à une API distante, chiffrer/signer des données, etc.

2 questions se posent :

• Comment/Où stocker ces secrets ?
• Comment mettre à jour facilement un secret utilisé par plusieurs applications ?

Le moyen le plus facile de mettre à disposition ces mots de passe est de les enregistrer dans les fichiers de configuration de l’application nommés par environnement (appsettings.dev.json, appsettings.prod.json, etc.) et de pousser ensuite tous ces fichiers dans le repository git.

Cette méthode est facile à mettre en place mais présente de gros inconvénients.